Choosing a Primary Cloud Region for APAC Workloads

A US workshop account often lands in us-east-1 or eastus because the lab image and quota already exist there. Production users and regulated data in Singapore, Jakarta, Tokyo, Sydney or Hong Kong then inherit that default. Confirm the current regional service list for the provider you run before you treat a city name as available.

Provider-by-provider primitives are on AWS vs Azure vs Google Cloud vs Alibaba Cloud for APAC. Alibaba-specific control-plane design is Alibaba Cloud architecture for APAC workloads.

Assumptions

• You can name user countries and where regulated data must stay.
• You will open the current regional-services page for every SKU in the design, including the recovery region.
• The framework is architectural. Legal interpretation of residency, cybersecurity and ICP statutes needs qualified counsel.
• Mainland China is a separate operating model, not a checkbox on an international region.

Decision inputs

Collect these before you pick a region code.

Input	What to write down
User locations	Countries and, if known, cities or networks that generate traffic
Data residency	Which records must stay in a country or economy, and who owns the legal interpretation
Required services	Control plane, data stores, Kubernetes, GPU, CDN, logging
Instance and accelerator availability	Families and accelerators the workload actually needs
Connectivity	Offices, colocation, partners, Direct Connect / ExpressRoute / Interconnect / CEN
Egress and inter-region transfer	Expected GB between regions and to the internet. See egress cost planning
Operational team location	Where on-call and platform engineers sit, and when they work
Disaster recovery objectives	RTO, RPO, and whether region B must run the same SKUs. See cross-region disaster recovery
Mainland China requirements	Whether users, content or entities are in mainland China
Existing commitments	Reservations, committed use, enterprise agreements, already-deployed landing zones

A workshop default is not an input. It is a convenience that still has to survive this list.

How to verify each provider

Services and SKUs differ by region. The four lists below are not interchangeable. Documentation last verified 30 August 2026.

AWS

1. Confirm the region exists on AWS Regions and Availability Zones.
2. Confirm every required service and the instance families you need on AWS Regional Services.
3. Treat AWS China (Beijing and Ningxia, operated with local partners) as a separate partition. Accounts, identity and endpoints differ from the standard AWS commercial partition. Start from Getting started with AWS services in China.

A service that exists in ap-southeast-1 may be absent or a different generation in ap-southeast-3. Read the row for that region.

Microsoft Azure

1. Confirm the geography and region on Azure geographies.
2. Confirm each product on Azure products available by region.
3. Azure in mainland China is operated by 21Vianet. Subscriptions, portals and contracts are not the international Azure estate. See Azure operated by 21Vianet.

Availability sets, availability zones and paired regions are Azure-specific. Do not assume an AWS AZ mapping.

Google Cloud

1. Confirm region and zone names on Google Cloud locations.
2. Confirm products on the locations page product-by-region section (products by region).
3. Google Cloud’s mainland China offering is limited relative to AWS, Azure and Alibaba Cloud. Verify the current locations page rather than assuming a China region exists for your SKU.

A global VPC does not make every product available in every region. Check the product row.

Alibaba Cloud

1. Confirm region and zone IDs on Alibaba Cloud regions and zones.
2. Confirm each product for that region on Alibaba’s current region and product pages. International regions and mainland China regions are different domains.
3. Public websites in mainland China typically need ICP filing. That is a legal and registrar process, not a VPC setting.

Resource Directory, RAM and CEN names are not Organizations, IAM and Transit Gateway. Use the Alibaba guide when this is the production control plane.

Measuring latency

Do not copy a trans-Pacific millisecond range from a blog or from memory. A useful latency number has:

• A named source or a test you ran
• Stated origin and destination (city or network, not “APAC”)
• A measurement date
• A stated protocol (TCP handshake, TLS, HTTPS application request)
• More than one sample
• An explicit note that paths change with peering, time of day and CDN

How to measure from the locations that matter:

1. Pick the client networks that represent users (office, home ISP in the user country, or a probe host you control there).
2. Measure to the candidate region’s public endpoint or to a test instance you place there. Use the same protocol the application uses.
3. Repeat at more than one time of day. Record p50 and p95, not a single ping.
4. Provider tools can help once traffic is on that cloud (AWS Internet Monitor or Network Manager, Azure Network Watcher connection monitor, Google Cloud Performance Dashboard / Connectivity Tests). They do not replace a probe from the real user network.
5. Re-measure after you change Direct Connect, ExpressRoute, Interconnect, CEN or a CDN.

If you cannot measure from the user country, say so in the ADR and treat region choice as provisional.

Data residency

Picking an APAC region is only one control. Data can still leave that region through:

• Cross-region backups and snapshots
• Centralized logs and SIEM
• Support and break-glass access from another country
• Read replicas and object replication
• SaaS integrations and marketplace products
• CI systems that pull artifacts from another region

Write those paths down. Legal interpretation of residency, sovereignty and sector rules needs qualified counsel. No statute is concluded for a given dataset here.

Mainland China

Mainland China is not “an APAC region with extra paperwork.” Implementations differ:

• AWS: China regions run in a separate partition with local operators. Identity, billing and endpoints do not join a standard commercial organization.
• Azure: Operated by 21Vianet. A distinct Azure environment with its own contracts and portals.
• Google Cloud: Confirm current China availability on the locations page. Do not assume parity with asia-east1 or asia-southeast1.
• Alibaba Cloud: Mainland regions plus ICP and cybersecurity rules for public internet services. International Alibaba regions are a different operating domain.

Accounts, contracts, connectivity (cross-border circuits) and support often split. Dual-run (international plus mainland) is two landing zones. Current legal and provider review is required for ICP, cybersecurity and cross-border transfer.

Disaster recovery

Primary-region choice and DR-region choice are separate decisions that have to be compatible.

1. Primary: the region that serves users and holds the system of record, after the input table above.
2. DR region: a second region on the same provider unless residency or an acquisition already forces a second cloud. Same-provider multi-region is operationally simpler: one IAM model, one hub primitive, one billing export, documented replication products.
3. Service availability: every SKU the failover needs must exist in region B. Re-open the regional-services page for that region.
4. Replication: async database and object replication set the floor for RPO. If the product cannot replicate to region B, the RPO is a restore from backup, not a failover.
5. RTO and RPO: write them per service. Unstated objectives produce an untested runbook. See region failover.
6. Inter-region cost: replication and failover traffic is a meter. Include it in egress cost planning.
7. Testing: a DR region that has never failed over is a diagram. Drill it.
8. Failure domains: AZs inside one region are not a second region. Two providers are not a DR plan unless the data plane and the incident owner are already tested.

Do not add a second cloud for availability by default. Add it when residency, an acquisition or a SKU that only exists elsewhere already requires it.

Decision matrix

No provider or city is universally best. Use the row that matches the constraint.

Requirement	Evidence needed	Example decision	Risk if ignored
Users in one APAC country	Traffic share by country; probe from that network	Primary in the provider region that serves that country and has the SKUs	Users pay intercontinental egress and unmeasured latency
Regulated data must stay in-country	Written residency rule; list of stores and replicas	Primary and backups in regions that satisfy the rule; counsel reviews the list	Logs or replicas silently leave the country
GPU or a specific database SKU	Current regional-services row for that SKU	Choose the APAC region that lists it, or change the SKU	Launch fails or the design is rewritten after procurement
Existing landing zone and commitments	Account tree, reservations, ExpressRoute / Direct Connect	Stay on that provider; pick an APAC region it already connects to	A second control plane with no operating model
Public users in mainland China	Entity, ICP status, provider China offering	Separate China landing zone on the provider you can contract	International region is unreachable or non-compliant for those users
Documented RTO under one hour	Replication product + last drill date	Same-provider region pair with tested failover	Paper DR; quota and images missing in region B

Hypothetical examples

These are scenarios for the matrix. They are not customer projects.

Consumer application serving Singapore and Indonesia. Users are in both countries. No mainland China requirement. Measure from both networks to ap-southeast-1 / Southeast Asia / asia-southeast1 / ap-southeast-1 (Alibaba) and to a Jakarta-capable region if the provider lists the SKUs you need. Put the system of record in one primary. Replicate to the other only if RPO requires it and you accept inter-region cost. Confirm NAT and object-store paths stay in-region where possible.

Regulated workload operating in Australia. Residency is written as Australia. Open each provider’s Australia region row (for example ap-southeast-2, Australia East, australia-southeast1, and the Alibaba Australia region if you run Alibaba). Keep backups, logs and support exports on the same list. A US or Singapore replica is a residency exception that counsel must accept.

Regional platform serving Japan. Users and operators are in Japan. Confirm Tokyo / Japan East / asia-northeast1 / Alibaba Japan SKUs, including any GPU. DR is often Osaka / Japan West / a second JP region on the same provider if those SKUs exist. Measure from Japanese office and mobile networks, not from a US laptop on VPN.

Workload that must serve mainland China. Treat this as a second landing zone. Confirm AWS China, Azure 21Vianet, current Google Cloud China availability, or Alibaba mainland regions. International APAC regions do not become China-capable by adding a CDN. ICP and cross-border transfer need current legal review.

Limitations

The framework does not name a universally correct region or provider. Regional SKU lists change; the tables and examples are not a substitute for the current official regional-services page. Latency must be measured from the networks that matter. Legal interpretation of residency, cybersecurity and ICP rules needs qualified counsel. The worked examples are hypothetical scenarios for the matrix, not customer projects.

What to record

Write the primary region, the DR region, the regional-services URLs you checked, the date you checked them, and the latency tests you ran (origin, destination, protocol, date). If a SKU is missing in the DR region, that is a design change, not a footnote.