Key takeaways
- GreenNode offers counterparts for the core building blocks most workloads rely on: virtual machines, managed Kubernetes, S3-compatible object storage, block and file storage, managed relational databases, load balancers, DNS, CDN, IAM, key management and monitoring.
- Two services give you the highest portability: vStorage exposes an S3-compatible API, and VKS runs standard Kubernetes. Workloads built on these move with the fewest code changes.
- “Equivalent” does not mean “identical”. Management APIs, IAM models and high-availability options differ, so plan to update infrastructure-as-code, access policies and some database designs.
- Some higher-level managed services, such as serverless functions or proprietary NoSQL databases, do not have a like-for-like counterpart in GreenNode’s public catalog. Plan alternatives for these early.
When a cloud architect starts planning a move from AWS or Microsoft Azure to a local cloud in Vietnam, the first question is usually practical: what is the equivalent of EC2, S3, RDS and EKS here? The second question matters even more: where are the differences that will affect my migration?
This guide answers both. It maps the most commonly used AWS and Azure services to their GreenNode counterparts, and explains the differences you should account for when you move workloads. It is written for cloud architects and IT directors who are validating a local cloud as part of a hybrid or sovereign cloud strategy.
How to read the equivalence tables
Each table lists an AWS service, its closest Azure service and the GreenNode service that fills the same role. The last column highlights what to check when you migrate. A service is listed as an equivalent when it fills the same architectural role, not because it shares every feature. Always validate the specific features your workload uses.
Compute and containers
| AWS | Azure | GreenNode | What to check when migrating |
|---|---|---|---|
| Amazon EC2 | Azure Virtual Machines | vServer CPU instances | Instance families are named differently. Map by vCPU, memory, CPU platform and network bandwidth rather than by name. Instances can be resized on demand. |
| EC2 GPU instances (for example P5) | ND-series VMs | GPU instances, H100 Bare Metal | Confirm GPU model, count per node and interconnect for multi-node training. H100 flavors support Multi-Instance GPU (MIG). |
| EC2 placement groups | Proximity placement groups | vServer placement groups | Review placement strategy for latency-sensitive or HA workloads. |
| Amazon EKS | Azure Kubernetes Service (AKS) | VKS (GreenNode Kubernetes Service) | Manifests and Helm charts are portable. Replace cloud-specific annotations for load balancers, storage classes and workload identity. Choose public or private cluster mode, and single-AZ or multi-AZ control plane. |
| Amazon ECR | Azure Container Registry | vCR (Container Registry) | Re-push images and update image references in manifests and CI pipelines. Access is controlled through GreenNode IAM and repository users. |
| AWS Lambda | Azure Functions | No like-for-like service in the public catalog | Run event-driven code as containers on VKS, for example with a Kubernetes-native serverless framework, or keep these functions on your hyperscaler in a hybrid design. |
Storage
| AWS | Azure | GreenNode | What to check when migrating |
|---|---|---|---|
| Amazon S3 | Azure Blob Storage | vStorage (Object Storage) | S3-compatible API, so AWS CLI, S3 SDKs, rclone and s3cmd work by pointing to the vStorage regional endpoint. Azure Blob uses a different API, so Azure workloads need an S3 client or code change. Validate any advanced S3 features you rely on. |
| S3 Glacier storage classes | Blob archive tier | vStorage archive tier | Compare retrieval behavior and lifecycle rules with your current archive policy. |
| Amazon EBS | Azure Managed Disks | Block Storage | Map volume types by IOPS and throughput needs, not by name. |
| Amazon EFS | Azure Files | File Storage | Confirm protocol and client compatibility for your applications. |
| EBS Snapshots | Managed Disk snapshots | Snapshots | Rebuild snapshot schedules; snapshots do not transfer between providers. |
| AWS DataSync (to S3) | Azure Storage Mover / AzCopy | DataSync (GreenNode) | GreenNode’s DataSync moves data between object storage services, including from international clouds to vStorage. rclone is another documented option. |
Databases and data services
| AWS | Azure | GreenNode | What to check when migrating |
|---|---|---|---|
| Amazon RDS for PostgreSQL | Azure Database for PostgreSQL | vDB PostgreSQL | Choose Standalone for dev/test or Cluster for production. The Cluster model uses one writer and up to nine readers with automatic failover. |
| Amazon RDS for MySQL / MariaDB | Azure Database for MySQL | vDB MySQL, vDB MariaDB | Read replicas are supported. Review the high-availability design, because failover behavior differs from RDS Multi-AZ (see below). |
| Amazon Aurora | Azure Database flexible server (HA) | vDB PostgreSQL Cluster or vDB MySQL | Aurora-specific features such as its storage layer and global database do not carry over. Plan around standard engine features. |
| Amazon ElastiCache | Azure Cache for Redis | vDB Redis | Check engine version and cluster mode compatibility with your clients. |
| Amazon MSK | Azure Event Hubs (Kafka endpoint) | vDB Kafka | Kafka clients are portable. Recreate topics, ACLs and retention settings, and plan the consumer cutover. |
| Amazon OpenSearch Service | Elastic on Azure (partner) | vDB OpenSearch | Reindex or restore from snapshots; check plugin and version compatibility. |
| Amazon DynamoDB | Azure Cosmos DB | No like-for-like service in the public catalog | Proprietary NoSQL APIs need redesign. Options include keeping these tables on the hyperscaler or moving to an open-source database on VKS or vServer. |
Networking and content delivery
| AWS | Azure | GreenNode | What to check when migrating |
|---|---|---|---|
| Amazon VPC, subnets, route tables | Azure Virtual Network | VPC | Plan CIDR ranges that do not overlap with your hyperscaler networks if you run hybrid. |
| Security groups, network ACLs | Network security groups | Security groups, network ACLs | Translate rules carefully; rule syntax and defaults may differ. |
| Elastic IP | Public IP address | Floating IP | Update DNS records and allow-lists that reference old public IPs. |
| VPC peering | VNet peering | VPC peering, Cross Connect | Map your existing peering topology before migration. |
| AWS PrivateLink / VPC endpoints | Azure Private Link | Private Endpoint | Private endpoints connect a VPC to GreenNode services such as vStorage, vCR and vMonitor without the public internet. |
| Elastic Load Balancing (ALB / NLB) | Application Gateway / Azure Load Balancer | vLB (Application and Network Load Balancer) | Layer 7 and layer 4 options, internet-facing or internal. Recreate listeners, pools and certificates. On VKS, load balancers are managed through Kubernetes manifests. |
| AWS Global Accelerator / Route 53 traffic policies | Azure Traffic Manager / Front Door | Global Load Balancer (GLB) | Confirm health-check and routing behavior across regions. |
| Amazon Route 53 | Azure DNS | vDNS | Supports public and private hosted zones and common record types. Terraform integration for vDNS is not yet supported, so plan to manage records via portal or API. |
| Amazon CloudFront | Azure Front Door / Azure CDN | vCDN | vCDN can use S3-compatible object storage as an origin. |
| AWS WAF | Azure Web Application Firewall | vWAF | Rebuild rule sets and test against real traffic before cutover. |
| AWS Site-to-Site VPN | Azure VPN Gateway | VPN Site-to-Site | The quickest way to connect GreenNode with your hyperscaler or on-premises network during and after migration. |
| AWS Direct Connect | Azure ExpressRoute | Discuss with GreenNode | Dedicated private connectivity to a hyperscaler depends on carriers and locations. Ask GreenNode which paths are available for your regions. |
Security, identity and operations
| AWS | Azure | GreenNode | What to check when migrating |
|---|---|---|---|
| AWS IAM | Microsoft Entra ID + Azure RBAC | GreenNode IAM | Policies do not translate automatically. Redesign roles around least privilege and map them to service accounts for automation. |
| AWS KMS | Azure Key Vault (keys) | Key Management System (KMS) | Supports GreenNode-managed keys and customer-managed keys that you create or import. |
| Amazon CloudWatch | Azure Monitor | vMonitor Platform | Collects metrics and logs from GreenNode, other clouds or on-premises. Rebuild dashboards and alarms. |
| AWS Backup | Azure Backup | Backup (Backup Center) | Recreate backup policies and retention; vDB PostgreSQL Cluster integrates with Backup Center. |
| AWS Elastic Disaster Recovery | Azure Site Recovery | DR Center | Define RPO and RTO per workload and run failover drills after migration. |
| Terraform AWS / AzureRM providers | Terraform AzureRM provider | Terraform vngcloud provider | Resource definitions must be rewritten for the GreenNode provider. Check coverage for each service you use. |
AI and machine learning
| AWS | Azure | GreenNode | What to check when migrating |
|---|---|---|---|
| Amazon SageMaker | Azure Machine Learning | AI Platform | Training scripts in standard frameworks are portable. Pipelines, experiment tracking and deployment configuration need to be rebuilt. |
| Amazon Bedrock | Azure AI Foundry models | Model as a Service (MaaS) | Model catalogs differ. Check which models are available and evaluate quality on your own tasks before switching. |
| Amazon Bedrock AgentCore | Azure AI Foundry Agent Service | AgentBase | Review framework support, tool integrations and governance controls for your agents. |
Five differences that matter most when you migrate
1. Management APIs and infrastructure as code
Only some data-plane APIs are compatible, mainly the S3 API on vStorage and the Kubernetes API on VKS. Everything else, including how you create VMs, networks and databases, uses GreenNode’s own APIs. GreenNode provides a Terraform provider (vngcloud/vngcloud), but your existing AWS or Azure Terraform modules must be rewritten, and some services, such as vDNS, do not yet support Terraform.
2. Database high availability
This is the difference most likely to affect production design. On vDB, the PostgreSQL Cluster deployment type provides automatic failover with one writer and multiple readers. For MySQL and MariaDB, vDB supports read replicas, but GreenNode’s documentation notes that failover is not automatic when the master fails in a master/read-replica setup: you promote a replica and update the application’s connection string. If you rely on RDS Multi-AZ or Azure zone-redundant HA for MySQL today, design your failover runbook accordingly, or consider PostgreSQL Cluster for critical workloads.
3. Regions and availability zones
GreenNode currently operates regions in Ho Chi Minh City (three availability zones), Hanoi (two availability zones) and Bangkok (one availability zone). Multi-AZ designs are possible in Ho Chi Minh City and Hanoi. For cross-country redundancy, combine a Vietnam region with Bangkok, keeping in mind that Bangkok is a single-AZ region.
4. Identity and access
IAM policies, Entra ID roles and managed identities do not map one-to-one. Plan a dedicated workstream to redesign roles, service accounts and access keys, including vStorage S3 keys and vCR repository users. If you run hybrid, federate access from your central identity provider where possible so people have one login.
5. Services without a direct counterpart
Proprietary managed services, such as serverless functions, proprietary NoSQL databases, managed queues beyond Kafka and some analytics services, do not have like-for-like equivalents. For each one, decide early whether to re-platform onto open-source software on VKS or vServer, or to keep it on your hyperscaler as part of a hybrid architecture.
A practical migration sequence
- Inventory and classify. List every service your workload uses and mark it as direct equivalent, equivalent with changes, or no counterpart.
- Set up the foundation. Create VPCs, subnets, security groups, IAM roles and the Terraform project, and connect to your existing cloud with VPN Site-to-Site.
- Move data. Sync object storage with DataSync or rclone, and migrate databases with native dump/restore or replication tools. When importing into vDB, back up only your application databases rather than system databases.
- Move applications. Redeploy containers to VKS and VMs to vServer, updating load balancer, storage class and registry references.
- Rebuild operations. Recreate monitoring, alerting, backup policies and DR plans, then run a failover drill.
- Cut over and validate. Switch DNS, monitor closely and keep a rollback path until performance and stability are confirmed.
Frequently asked questions
What is the equivalent of AWS EC2, S3, RDS and EKS on a local cloud in Vietnam?
On GreenNode, EC2 maps to vServer CPU and GPU instances, S3 maps to vStorage object storage with an S3-compatible API, RDS maps to vDB (PostgreSQL, MySQL and MariaDB) and EKS maps to VKS, GreenNode’s managed Kubernetes service.
Can I use AWS CLI and S3 SDKs with GreenNode?
Yes, for object storage. vStorage is S3-compatible, so AWS CLI, S3 SDKs and tools such as rclone, s3cmd and Cyberduck work by pointing them to the vStorage regional endpoint with vStorage S3 keys.
Will my Kubernetes workloads run on VKS without changes?
Most manifests and Helm charts run as they are, because VKS runs standard Kubernetes. You will typically need to update cloud-specific settings such as load balancer annotations, storage classes, image registry paths and workload identity configuration.
Does GreenNode support Terraform?
Yes. GreenNode publishes the vngcloud Terraform provider, which covers services including vServer and VKS. Coverage varies by service, so check the provider documentation for each resource you use.
Do I have to migrate everything at once?
No. Many companies keep global services on AWS or Azure and move only workloads that need local latency, data residency or local GPU capacity to GreenNode. This hybrid approach also lets you keep services that have no GreenNode equivalent on your hyperscaler.
Next step
An equivalence table is the starting point; a migration plan depends on the specific features your workloads use. If you want help mapping your current architecture to GreenNode, talk to our solution architects.
