Why it matters
Moving a production estate to another region later means re-creating networks, migrating data, changing DNS and IPs, and repeating security reviews. Spend a day choosing carefully.
Criteria
| Criterion | Questions |
|---|---|
| Data residency / regulation | Must data stay in a country or geography? Which services keep data in-region (some have global components)? |
| Latency | Where are users, on-prem data centres and partners? Measure round-trip times. |
| Availability zones | Does the region have zones? Do the services you need support zone redundancy there? |
| Service and SKU availability | Are all required services, VM sizes (incl. GPU), and features available? |
| Capacity and quota | Can you get the vCPU/GPU quota you need? Are there known constraints for certain sizes? |
| Pricing | Prices differ by region; compare your main meters. |
| DR region | Paired region or chosen secondary: same geography for residency? Services available there too? |
| Connectivity | ExpressRoute peering locations nearby; provider availability. |
| Sustainability / operations | Some organisations weigh region energy reporting; time zone of support teams. |
Check service availability
- Azure "Products available by region" page for services.
- VM sizes in a region and zone restrictions:
az vm list-skus --location centralindia --size Standard_D --all --output table \
--query "[?restrictions[0]==null].{name:name, zones:locationInfo[0].zones}"
- Quota for key families:
az vm list-usage --location centralindia -o table | grep -i -E "Total Regional|DSv5|NCADS"
Measure latency
From user locations and on-prem sites, test to candidate regions (temporary VMs or published latency test endpoints), at different times of day. Use p95, not a single ping. For chatty apps, the latency between the app's tiers matters more than user latency: keep tiers in the same region.
Primary and secondary pairs
| Approach | Notes |
|---|---|
| Use the paired region | Platform updates sequenced across pairs; some services' geo-redundancy uses the pair automatically (e.g. GRS) |
| Choose a non-paired secondary | Gives flexibility (capacity, services), but check which services' replication is tied to pairs |
| Region without a pair | Some newer regions have no pair; design DR explicitly with zones and a chosen secondary |
Record the decision
One page per region decision: candidates, scores per criterion, chosen primary/secondary, constraints accepted (e.g. "GPU size X not available in secondary; DR for AI workloads is degraded"), and review date.
Review triggers
- New service requirement not available in the region.
- Regulatory change.
- Persistent capacity constraints.
- New region opening closer to users.
Tip
Validate capacity early for anything scarce (GPUs, large memory sizes). Request quota and, for critical needs, consider capacity reservations before you announce a go-live date.
Checklist
- Residency requirements confirmed per data class
- Latency measured from users and on-prem
- Zones and zone-redundant services confirmed
- Services, SKUs and quota verified
- Pricing compared
- DR region chosen with the same checks
- Decision recorded with constraints and review date