AWS Landing Zone for Vietnamese enterprises 2026: design that survives audit
With AWS Local Zones now live in Hanoi and HCMC, here is the account structure, SCP guardrails and region strategy that work for Vietnamese enterprises under Decree 13 and Decree 53.

By 2026 AWS Local Zones in Hanoi and Ho Chi Minh City are in production, and the Asia Pacific (Bangkok) region has stabilised for Vietnamese customers. This article explains how to design a Landing Zone that takes advantage of the new footprint while staying compliant with Decree 13 and Decree 53.
1. Why the Landing Zone is the first step — not the last
Many Vietnamese enterprises still land on AWS by "opening an account and running EC2". Six months later it's chaos: prod and test mixed, over-broad IAM, BU-level billing impossible, logs scattered. A Landing Zone (via AWS Control Tower + Organizations) locks in the rails early: environment-based OUs, SCP guardrails, centralised logging in its own account, a network baseline.
2. Recommended account structure for Vietnamese enterprises in 2026
- Management account — Organizations only, no workloads.
- Log Archive — centralised CloudTrail, Config, VPC Flow Logs; Object Lock on.
- Audit / Security Tooling — GuardDuty, Security Hub, Detective administrator.
- Shared Services — Transit Gateway, Route53 resolver, AD Connector.
- Workload OUs — Prod, Non-Prod, Sandbox, one account per BU.
- Data Perimeter OU — dedicated accounts for personal data, SCPs blocking non-APAC regions.
3. Region strategy: what goes where
Pattern working well for Vietnamese customers in 2026: primary compute in ap-southeast-7 (Bangkok) — closest, ~25–35ms to HCMC. Hanoi/HCMC Local Zones for latency-sensitive workloads (game servers, RTC voice, edge inference). DR in ap-southeast-1 (Singapore). Personal-data storage (Decree 13) must stay onshore — Local Zone + onshore S3, or combined with VNG/Viettel IDC via Direct Connect.
4. Four minimum SCP guardrails
- Deny every region outside APAC unless whitelisted.
- Forbid disabling CloudTrail, GuardDuty, Config in any workload account.
- Require Owner, CostCenter, Environment tags on every billable resource.
- Block non-MFA IAM users from write APIs.
5. Network baseline: Transit Gateway, not a VPC peering mess
All VPCs connect via Transit Gateway in Shared Services. Two Direct Connect links to an onshore IDC for onshore data. Private endpoints for S3, KMS and Secrets Manager so traffic never leaves the AWS network. This pattern scales from 5 to 200 accounts without redesign.
6. Common mistakes to avoid
- Hand-rolling the Landing Zone instead of Control Tower + IaC (Terraform/CDK).
- Letting dev teams create their own accounts → loss of cost control.
- Skipping data classification before assigning regions to workloads.
- No exit plan — locked into AWS-only services from the very first workload.
Evaluating a similar solution?
Our team can advise on architecture, rollout roadmap and TCO — first session free, no commitment.


