No single cloud model is right for every workload. Hyperscalers typically stand out for their global scale, extensive managed service portfolios, and ability to support deployments across multiple countries. Local cloud providers may be a better fit when businesses need to keep data in Vietnam, establish clear legal jurisdiction, optimize connectivity for domestic users, or work directly with a local technical team.
The more useful question, therefore, is not “Which is better: hyperscalers or local cloud?” but rather: Where should each workload run to meet business, technical, security, and data governance requirements? For critical workloads or those processing regulated data, this decision should be based on verifiable evidence—not simply a provider’s brand or the location of its data centers.
Key differences between hyperscalers and local cloud providers
A hyperscaler is a global cloud provider that operates an extensive network of regions and Availability Zones, offering a broad range of services spanning compute, storage, databases, analytics, AI, and serverless computing. AWS states that each of its Regions consists of at least three physically separate Availability Zones. Azure and Google Cloud also organize their infrastructure into geographies, regions, and zones to address availability, performance, and deployment location requirements.
For the purposes of this article, local cloud refers to a platform operated by a legal entity in Vietnam, with infrastructure deployed in the country and services for businesses operating in Vietnam. However, the “local” label does not automatically guarantee compliance, security, or high availability. Businesses still need to verify the locations of primary data, backups, and disaster recovery (DR) systems, as well as certification scope, operational access rights, service commitments, and each party’s responsibilities.
The core distinction lies in the geographic reach and level of control each workload requires. Hyperscalers are optimized for global scale and broad service ecosystems, while local cloud providers may simplify legal arrangements, operations, and support for workloads in Vietnam. In many cases, the two models are complementary rather than mutually exclusive, forming part of a hybrid or multi-cloud architecture.
Comparing hyperscalers and local cloud providers across deployment criteria
| Criterion | Hyperscalers | Local cloud providers | Questions businesses should verify |
|---|---|---|---|
| Scale and geographic coverage | Extensive global networks of regions, zones, and points of presence, supporting systems that serve multiple markets. | A focus on a single country or region, making them relevant for workloads whose users and data are primarily in Vietnam. | Does the workload serve Vietnam, Southeast Asia, or multiple regions worldwide? |
| Data location | Region selection and location controls are available for many services, but their scope varies by service, backup configuration, metadata, and enabled features. | May support in-country data storage and processing if all relevant architectural components are deployed in Vietnam. | Where are primary data, replicas, backups, logs, telemetry, and DR systems actually located? |
| Legal jurisdiction | Contracts, service-providing entities, infrastructure, and support operations may span multiple jurisdictions. | May make it easier to identify the operating entity and governing law when both the legal entity and infrastructure are based in Vietnam. | Which legal entities sign the contract, operate the systems, and have access to the data? |
| Service ecosystem | Broad managed service portfolios, frequent feature releases, and extensive partner ecosystems. | Service portfolios tend to focus on compute, storage, Kubernetes, networking, databases, security, and services tailored to the local market. | Does the workload depend heavily on a hyperscaler’s proprietary services or APIs? |
| Workload portability | Proprietary managed services can accelerate development but may increase the effort required to migrate. | Infrastructure built on VMs, Kubernetes, S3-compatible storage, or widely adopted technologies may support portability, but testing is still necessary. | Can the current architecture be packaged, backed up, and restored in another environment? |
| Latency in Vietnam | Depends on the region, service, and network path. AWS launched a Local Zone in Hanoi in June 2026, but a Local Zone is not equivalent to a full AWS Region. | In-country infrastructure may shorten network paths to users and systems in Vietnam, but actual performance must still be measured at the application level. | What are the workload’s target P95/P99 latency, jitter, and packet loss levels? |
| Private connectivity | Dedicated connectivity services and global carrier ecosystems are available. | May support leased lines, Interconnect, or site-to-site VPN connections to data centers, branch offices, and other clouds. GreenNode currently lists private connectivity to AWS through Multicloud Connection. | Must traffic avoid the public Internet? What bandwidth, path redundancy, and implementation lead times are required? |
| Operational support | Standardized processes, extensive documentation, and multiple support tiers, with coordination potentially handled by regional or global teams. | May offer direct support in Vietnamese, alignment with local business hours, and on-site coordination when needed. | Are response-time SLAs, escalation paths, and the scope of managed services clearly defined in the contract? |
| Security and certifications | Typically maintain a broad portfolio of certifications globally. Their scope must be checked against the specific services and regions in use. | May meet international standards and domestic requirements, but capabilities vary by provider. | Does the certification or report cover the relevant services, data centers, and assessment period? |
| Cost | Public pricing and flexible consumption models, with additional costs to consider for data transfer, support, managed services, and operations. | May simplify quotations, local billing, and domestic support, but should not automatically be assumed to cost less. | What is the three-year total cost of ownership (TCO), including compute, storage, networking, licenses, support, migration, and staffing? |
| Availability and disaster recovery | Multiple options for multi-AZ, multi-region, and DR deployments, though customers must still design and configure them correctly. | May support multi-AZ deployments or in-country DR if the provider offers sufficiently independent zones and appropriate services. | What commitments cover recovery time objectives (RTO), recovery point objectives (RPO), fault-domain separation, failover mechanisms, and recovery testing frequency? |
This comparison shows that data center location is only one factor. Cloud decisions also depend on application architecture, backup and DR locations, operational access models, certification scope, contractual responsibilities, and the ability to demonstrate that controls work in practice.
Six key criteria for selecting a cloud platform
Verifiable data location
Selecting a region does not always fully answer the question of where data resides. Google Cloud, for example, allows organizations to restrict resource locations for supported services and configure backup storage locations. Azure states that most services allow region selection, but storage and processing arrangements also depend on the selected geography and the specific service.
Businesses should request a data flow diagram that clearly identifies the locations of:
- Primary data and replicas
- Backups, snapshots, and DR environments
- Logs, metadata, and telemetry
- Encryption keys and key management systems
- Data accessed by support teams during troubleshooting
A commitment to use “data centers in Vietnam” is meaningful only when the data, services, and exceptions it covers are clearly documented in the contract or technical documentation.
Legal jurisdiction beyond physical location
Data residency describes where data is stored or processed. Jurisdiction concerns the legal entities, contracts, and legal frameworks governing service delivery. The two are related, but they are not interchangeable.
In Vietnam, the Law on Personal Data Protection No. 91/2025/QH15 and Decree No. 356/2025/ND-CP both took effect on January 1, 2026. Decree 356 replaces Decree No. 13/2023/ND-CP and provides detailed rules for implementing the Law. This does not mean that all personal data must be hosted on a local cloud, nor does choosing a local cloud automatically fulfill compliance obligations. Businesses still need to determine their data processing roles, processing purposes, data transfer flows, impact assessment documentation, and the obligations applicable to their specific circumstances.
Scope of certifications and audit reports
A certification name alone is not enough to establish whether a workload meets its control requirements. ISO/IEC 27001 certifies an information security management system within a defined scope, while a SOC 2 report provides an independent assessment of control design or operating effectiveness against specified criteria and, where applicable, over a defined reporting period. PCI DSS focuses on payment account data and does not replace personal data protection obligations.
When assessing a provider, businesses should request:
- Certificates and statements of scope
- A SOC 2 Type II report or equivalent assurance documentation, where required
- A PCI DSS Attestation of Compliance for environments involving payment data
- Details of the data centers, services, and assessment periods covered
- Procedures for incident management, breach notification, and evidence retention
Clear allocation of security responsibilities
Moving a workload to the cloud does not transfer all security responsibilities to the provider. AWS describes the provider as responsible for security “of the cloud,” while customers remain responsible for the data, applications, and configurations within their control. Microsoft likewise states that customers always retain responsibility for their data, identities, accounts, and access management.
Before selecting a platform, IT and Security teams should establish a RACI matrix for the following areas:
- Identity and access management (IAM), privileged accounts, and multi-factor authentication (MFA)
- Encryption, key management, and secrets lifecycle management
- Network configuration, firewalls, and segmentation
- Operating system and middleware patching
- Backups, restoration, and DR testing
- Logging, monitoring, and incident response
- Application vulnerability management
This matrix is particularly important when comparing a managed service on a hyperscaler with an IaaS or self-managed service on a local cloud, as the division of responsibilities can differ significantly.
Workload-level latency and performance
Geographic distance often affects latency, but proximity is no substitute for testing. Actual performance also depends on routing, peering, bandwidth, application architecture, caching, database round trips, and the locations of dependencies.
Businesses should run a proof of concept using representative data and measure at least:
- P50, P95, and P99 response times
- Jitter and packet loss
- Database and object storage access times
- Peak-hour performance
- Synchronization or backup times between environments
- The impact of switching to a backup network path
The AWS Local Zone in Hanoi may bring certain latency-sensitive workloads closer to users, but businesses still need to check service availability and dependencies on its parent Region. Similarly, local cloud infrastructure delivers an advantage only when the application’s entire end-to-end path—not just its VMs—is designed appropriately.
Workload portability and migration requirements
Portability involves more than copying a virtual machine. A complete migration plan must address images, data, databases, persistent volumes, secrets, IAM, DNS, network policies, load balancers, observability, and cutover procedures.
For Kubernetes, GreenNode provides guidance on migrating clusters from EKS, GKE, other clouds, or on-premises environments to VKS using Velero. The process uses vStorage S3 as a backup repository and requires teams to prepare corresponding resources in the target environment, migrate resources outside the cluster, and map StorageClasses before restoration. The documentation also makes clear that migration is not a single lift-and-shift operation: databases, container images, and storage must be handled as separate workstreams.
For object storage, GreenNode’s DataSync supports data transfers from Amazon S3, Google Cloud Storage, S3-compatible platforms, and on-premises systems to vStorage. Its documentation currently lists transfer infrastructure capacity of up to 1 Gbps. This should be treated as the service’s stated capacity, not a guarantee of migration completion times for every project. Actual throughput also depends on the data source, object count, file sizes, bandwidth, and API limits.
Matching cloud models to workload requirements
| Workload characteristics | Deployment approach to evaluate first | Rationale |
|---|---|---|
| Global applications requiring a broad range of specialized managed services | Hyperscaler | Provides access to global region coverage, extensive service ecosystems, and global operations tools. |
| Data that must be stored and processed in Vietnam, with clearly verifiable locations | Local cloud or an architecture with a local data layer | Helps keep data within a defined domestic footprint and makes the in-country architecture easier to verify. |
| Latency-sensitive applications primarily serving users in Vietnam | Local cloud or suitable edge/local infrastructure | May shorten network paths; benchmarking is necessary before making a decision. |
| Systems with deep dependencies on proprietary databases, serverless services, or analytics platforms | Remain on the hyperscaler initially, then gradually decouple components that can be moved | Reduces re-architecture risks and operational disruption. |
| Highly standardized Kubernetes, VM, or object storage workloads | Evaluate migration to a local cloud | Widely adopted technologies and compatible interfaces may support a phased migration. |
| Disaster recovery for existing systems | Multi-cloud or hybrid cloud | Separates fault domains and adds recovery options, but requires testing of data consistency and failover. |
| Sensitive data in Vietnam supporting applications that still require global services | Hybrid or multi-cloud architecture | Keeps the relevant data layer in Vietnam while providing controlled connectivity to other services. |
This table is a starting point for architectural assessment, not a set of rules to apply automatically. For personal data or systems subject to industry-specific regulations, Legal/DPO and Security teams should confirm the requirements before the technical team selects a deployment model.
Combining hyperscalers and local cloud in a multi-cloud architecture
For businesses already operating reliably on AWS, Azure, or Google Cloud, moving the entire system to another platform can introduce unnecessary risk and cost. A more practical approach is to classify workloads, then prioritize components with clear reasons to move, whether related to data requirements, latency, control, or cost.
The target architecture may include the following:
- Retain global services, analytics, and applications with deep managed service dependencies on the hyperscaler.
- Deploy databases, storage, Kubernetes, or applications serving the Vietnamese market on a local cloud where appropriate.
- Connect the two environments through leased lines, Interconnect, or site-to-site VPNs based on security and bandwidth requirements.
- Standardize IAM, logging, monitoring, and incident response across all environments.
- Design backup, DR, and cutover procedures around approved RTO and RPO targets.
GreenNode describes Multicloud Connection as a private leased-line connection between GreenNode and another cloud provider, allowing data to travel without passing over the public Internet. The documentation currently lists AWS as a supported cloud. However, it also contains an inconsistency: the “Benefits” section mentions Alibaba Cloud. Businesses should therefore confirm supported clouds, connection locations, bandwidth, redundancy, and SLAs directly before incorporating the service into their architecture.
For on-premises systems, Hybrid Interconnect or a site-to-site VPN can provide connectivity between a private data center and the cloud. The goal is not to consolidate every component in one place, but to establish unified operations with controlled routing, security policies, and observability.
A framework for evaluating and selecting a cloud platform
Step 1: Classify workloads and data
Identify workload owners, business criticality, data types, users, dependencies, RTO/RPO targets, and legal obligations. Start with business requirements and the risks of workload disruption or unauthorized data access—not with a list of cloud services.
Step 2: Define mandatory requirements
Some criteria may be non-negotiable, such as keeping data in Vietnam, ensuring connections do not traverse the public Internet, requiring certifications to cover the relevant services, or setting specific support response times. Providers that fail to meet these mandatory requirements should not proceed to the pricing evaluation stage.
Step 3: Apply weighted evaluation criteria
Businesses can build a weighted evaluation matrix for each workload:
| Evaluation category | Illustrative weighting |
|---|---|
| Data residency and jurisdiction | 25% |
| Security, compliance, and auditability | 20% |
| Reliability, backup, and DR | 20% |
| Performance and connectivity | 15% |
| Portability and migration feasibility | 10% |
| TCO and commercial terms | 10% |
These weightings are illustrative. Global workloads may place greater emphasis on geographic coverage and service ecosystems, while financial systems or workloads handling sensitive data may assign more weight to jurisdiction, auditability, and DR.
Step 4: Run a proof of concept
A PoC should test the most important assumptions, rather than merely confirm that an application can run. Its scope should include performance benchmarks, network paths, backup restoration, access permissions, audit logs, failover, integration with existing tools, and support procedures during incidents.
Step 5: Migrate in phases
Start with workloads that have well-understood dependencies, reliable rollback options, and a manageable business impact. After each phase, update runbooks, performance baselines, actual costs, identified issues, and the criteria for extending migration to the next set of workloads.
GreenNode’s role in hybrid and multi-cloud architectures
GreenNode operates cloud infrastructure in Hanoi and Ho Chi Minh City. Its Cloud Server page lists five Availability Zones in Vietnam, while the platform’s broader regional network comprises six Availability Zones across Vietnam and Thailand. Businesses should therefore select the appropriate region and verify the location of each component if their goal is to keep a particular workload entirely within Vietnam.
For security and audit requirements, GreenNode states that its infrastructure is aligned with ISO/IEC 27001, 27017, 27018, and PCI DSS. Its Sovereign AI Cloud page also lists SOC 2 Type II, Uptime Institute Tier III, and TVRA among the certifications or reports available for verification. During due diligence, businesses should still request current documentation and confirm that its scope covers the services they intend to use.
For migration and multi-cloud deployments, the available technical documentation supports three notable approaches:
- Migrating Kubernetes clusters from EKS, GKE, other clouds, or on-premises environments to VKS using Velero and vStorage S3.
- Migrating object storage from Amazon S3, Google Cloud Storage, S3-compatible platforms, or on-premises systems to vStorage using DataSync.
- Connecting GreenNode to AWS over a private leased line through Multicloud Connection, or connecting enterprise systems through Interconnect/VPN.
These capabilities support a selective workload placement strategy: businesses do not need to abandon hyperscalers, but can instead add a local cloud layer for workloads that require clearer control within Vietnam.
Choosing a cloud platform based on workload requirements
Hyperscalers remain a strong choice for global scale, broad service ecosystems, and applications that need to launch quickly across multiple markets. Local cloud providers deserve priority consideration when workloads require clearly defined data locations in Vietnam, proximity to domestic users and systems, local support, or more readily verifiable legal arrangements.
For most businesses already using AWS, Azure, or Google Cloud, an effective architecture does not necessarily require a complete replacement. A lower-risk approach is to retain suitable workloads on the hyperscaler, selectively move critical workloads to a local cloud, and connect the environments through a tested hybrid or multi-cloud architecture.
GreenNode can work with businesses to assess workloads, design a target architecture, and develop a phased migration plan. The first step should be an assessment focused on data flows, dependencies, RTO/RPO targets, connectivity, and compliance criteria—before selecting technologies or committing to a large-scale migration.
