Choosing Azure Regions: What Architects Actually Need to Know
A practical guide to regions, geographies, paired regions and availability zones, and how each one changes your design.
Introduction
Region selection is one of the first decisions in an Azure design, and one of the most expensive to reverse. Moving a stateful workload between regions means data migration, new IP addressing, rebuilt private connectivity, revalidated compliance evidence, and usually a maintenance window the business did not budget for.
Despite that, region choice is often made informally: "the one closest to the office" or "the one we used for the proof of concept." This post assumes you already know what a VM, a VNet and a storage account are. It focuses on the structural concepts (region, geography, region pair, availability zone), the criteria that should drive selection, and how those criteria differ depending on whether you are designing for high availability (HA) or disaster recovery (DR).
Core Concepts
Regions
An Azure region is a set of datacenters deployed within a latency-defined perimeter and connected through a dedicated regional low-latency network. When you create a resource, you pick a region (for example, West Europe or Central US), and that choice determines where the resource's compute and, for most services, its data physically live.
Two practical points:
- A region is not a single building. It is a collection of datacenters. Whether you can control placement within the region depends on whether the region supports availability zones and whether the service lets you choose one.
- Regions are independent deployment targets. Resources, quotas, SKU availability and pricing are all evaluated per region. A subscription's vCPU quota in one region says nothing about another.
Some services are global or non-regional (Microsoft Entra ID, Azure DNS, Azure Front Door and Traffic Manager are common examples). They do not live in a region you choose in the same way, but they often have their own data-location and metadata considerations. Check each service's documentation.
Geographies
A geography is a discrete market, typically containing two or more regions, defined to preserve data residency and compliance boundaries. Geographies are how Microsoft expresses the idea "your data stays within this jurisdiction or market" at the platform level. Examples include the United States, Europe, Asia Pacific and individual countries or country groupings in markets where in-country regions exist.
Geographies matter because many compliance and contractual commitments are expressed at that level, and because most paired-region replication stays inside one.
Separately from geographies, Microsoft operates sovereign and isolated clouds (such as Azure Government and Azure operated by 21Vianet in China). These are distinct environments with their own endpoints, identity boundaries and service catalogues, not just more regions in the public cloud. If your regulatory position requires one of them, that decision comes before any region comparison.
Paired regions
Historically, most Azure regions have been part of a region pair: two regions in the same geography, generally separated by a significant distance (the stated aim has been several hundred miles where possible) so that a single large-scale event is unlikely to affect both.
What the pairing actually gives you:
- Geo-replication targets for some services. Geo-redundant storage options (GRS, RA-GRS, GZRS, RA-GZRS) replicate asynchronously to the paired region. You do not choose a different secondary for these tiers.
- Sequenced platform updates. Where applicable, planned platform updates are rolled out to one region of a pair at a time, which reduces the chance that both are in a maintenance window simultaneously.
- Recovery prioritization. In a broad outage affecting multiple regions, Microsoft prioritizes restoring at least one region in each pair.
- Data residency alignment. Pairs are generally inside one geography, so replication stays within the same compliance boundary. A small number of pairs are exceptions (Brazil South is the commonly cited one, paired with a region outside its geography), so check the pair table instead of assuming.
What the pairing does not give you:
- Automatic workload failover. Pairing does not fail your application over. Your VMs, App Services, AKS clusters and databases fail over only if you built and tested that capability.
- Guaranteed capacity. The paired region is not holding spare capacity for you. If you need compute available in a DR event, reserve it (see capacity reservations below).
- A requirement to use the pair. For services where you choose the secondary (Azure SQL failover groups, Cosmos DB regions, Azure Site Recovery targets, many custom designs), you can pick any suitable region, subject to residency and service availability.
Availability zones
Availability zones are physically separate locations within a region. Each zone consists of one or more datacenters with independent power, cooling and networking. In regions that support zones, there are at least three, so that a service can tolerate the loss of one zone and still maintain a majority.
Key details architects sometimes miss:
- Zone numbering is per subscription. Logical zone 1 in your subscription may map to a different physical zone than logical zone 1 in someone else's. This matters when coordinating with another team or partner who needs "the same zone." Check the zone mapping feature if physical co-location matters.
- Not every region has zones, and not every service supports them. Zone support is a property of both the region and the service SKU.
- Zonal vs. zone-redundant are different models.
- Zonal resources are pinned to a specific zone you choose (for example, a VM in zone 2). You build the redundancy yourself by deploying across zones and putting a load balancer in front.
- Zone-redundant resources are spread across zones by the platform (for example, ZRS storage, zone-redundant Azure SQL Database, Standard Load Balancer with a zone-redundant frontend, Application Gateway v2 configured across zones). The platform handles replication and failover within the region.
- Inter-zone latency is low but not zero. Zones are designed to be close enough for synchronous replication workloads, but latency-sensitive chatty applications can still notice cross-zone hops. Measure it for your workload.
Zones protect against datacenter-level failures within a region. They do not protect against a region-wide event, a control-plane problem affecting the region, or logical failures such as bad deployments and data corruption.
How the Concepts Map to HA vs. DR
The cleanest way to keep these concepts straight is to assign each to a failure domain.
| Failure scenario | Primary mechanism | Typical replication | Typical recovery behavior |
|---|---|---|---|
| Host or rack failure | Availability sets, fault domains, platform healing | N/A | Automatic |
| Datacenter-level failure | Availability zones | Synchronous (zone-redundant services) | Often automatic, near-zero RPO |
| Region-wide failure | Secondary region (paired or chosen) | Usually asynchronous | Failover is a decision and a process; RPO above zero is normal |
| Logical corruption or human error | Backups, point-in-time restore, immutability | Independent of the above | Restore, not failover |
This is the core distinction:
- HA designs keep the application running through component and datacenter failures with minimal or no human intervention. In Azure that means zones inside a region. The data tier can use synchronous replication, so RPO is effectively zero for zone failure and RTO is short.
- Identify which jurisdictions your data may reside in, and which it may be replicated to. Backups, DR replicas, log data and telemetry all count.
- Understand that residency is not the same as sovereignty. Where data is stored is different from who can be compelled to provide access or who operates the service. Some regulated sectors need additional controls (customer-managed keys, confidential computing, sovereign cloud offerings) beyond choosing a local region.
- Check the data-handling documentation for each service you use. Some services store metadata, support data or operational telemetry outside the region you selected, and some global services have their own location rules.
- Enforce the decision. Use Azure Policy with the "Allowed locations" style policies at management group or subscription scope so a developer cannot deploy into a non-approved region by accident.
- Build a service inventory for the workload and verify each item against the official "Products available by region" page and the per-service documentation before committing to a region.
- Check the specific SKU and feature, not just the service. "Service X is available" does not mean "the tier with zone redundancy is available."
- Check quota and capacity in the region, not only availability. A SKU can be listed and still be restricted for your subscription until you request access or quota.
- Verify the same things for the DR region. The secondary needs the same services, or you need a documented degraded-mode plan.
- Use Microsoft's published inter-region and geography-to-region latency statistics as a starting point, then measure from your actual user locations and networks. Corporate WAN and ISP paths often differ from the published figures.
- Consider where your dependencies live. If your application tier talks to an on-premises database or a third-party API, proximity to that matters more than proximity to end users.
- Remember that ExpressRoute peering locations are not regions. A peering location near you connects to Azure through the Microsoft backbone to your chosen region, and the path is not always what the map suggests. Review the connectivity provider and peering location mapping.
- For multi-region active-active designs, use a global entry point (Azure Front Door or Traffic Manager, depending on protocol and requirements) to route users to the nearest healthy region.
- GRS-family storage replicates to the pair. If your storage secondary must be in a particular country, verify the pair is there before choosing the primary.
- Failover of geo-redundant storage is not instantaneous. Replication is asynchronous, so you should plan for potential data loss equal to the replication lag at the time of failover. Understand the difference between customer-managed failover and Microsoft-initiated failover, and what happens to the account configuration afterward. Check the current documentation for specifics.
- Sequenced updates reduce correlated maintenance risk, but they do not eliminate it, and they do not apply uniformly to every service. Do not assume that having the pair means you are never both in maintenance.
- Pick your own secondary where you can. For services that let you choose (Azure SQL failover groups, Cosmos DB, Azure Site Recovery, application-level replication), you are free to use a different region if the pair lacks a required service, lacks capacity or violates a constraint. Just be consistent: scattering secondaries across many regions complicates operations.
- Reserve the capacity you will need. In a regional disaster many customers fail over at once and capacity is contended. On-demand capacity reservations and pre-provisioned quota in the DR region are how you avoid discovering a capacity shortfall during an incident.
- Zone-redundant configuration (HA). Replicas are spread across zones in one region, synchronous commit, failover handled by the platform. RPO is effectively zero for a zone loss, RTO is short and automatic, and the connection string does not change. This only works if the region supports zones and your chosen tier supports zone redundancy.
- Auto-failover group to a second region (DR). Replication is asynchronous to a secondary in another region, the application connects through the failover group listener endpoints, and failover is either policy-driven or manually initiated. You must accept a non-zero RPO, and you must make sure the application tier, secrets, networking and DNS exist in the secondary.
- Both. Most serious designs combine them: zone-redundant in the primary, a geo-secondary elsewhere. Region choice determines whether this is even possible: a region without zone support forces you to lean on cross-region replication for what would otherwise be a simple HA problem, which is slower to fail over and costs more.
- Choosing a region with no zone support and expecting zonal resilience. Check zone support at design time, not at deployment time.
- Forgetting residency for DR, backups and telemetry. Compliance applies to every copy of the data.
- Not testing failover. A DR plan that has never been executed is a hypothesis. Schedule regular failover exercises and measure real RTO and RPO.
- Assuming DR capacity will be there. Without reserved capacity or pre-provisioned quota, you may be unable to scale up at the moment you need to.
- Overlooking dependencies. The application fails over, but the key vault, container registry, private DNS zones or monitoring workspace were single-region. The failover "works" and the application cannot start.
- Choosing on price or proximity alone. Residency, service availability and resilience requirements should be validated first.
- Hard-coding region assumptions. Parameterize region in infrastructure-as-code so that a region change or a DR rebuild is a deployment, not a rewrite.
- Decide the constraints before the candidates. Document residency requirements, required services and SKUs, latency targets, and RTO/RPO per workload tier. Then shortlist regions that satisfy them.
- Validate against official sources. Check the Azure documentation for current regions and region pairs, availability zone support, products available by region, and per-service resiliency guidance. Do this at design time and again before production deployment.
- Design HA and DR as separate layers. Use zones for datacenter-level resilience; use a secondary region for regional disasters. State explicitly which layers each workload has.
- Tier your workloads. Not everything needs active-active. Match the resilience investment to business impact, and use the Azure Well-Architected Framework reliability guidance to formalize the trade-offs.
- Enforce with policy. Use Azure Policy to restrict deployments to approved regions, and use landing-zone patterns so region decisions are applied consistently across subscriptions.
- Plan capacity in the DR region. Pre-request quota and consider capacity reservations for critical compute.
- Automate everything you intend to fail over. Infrastructure as code, scripted failover steps and configuration management reduce recovery time and human error.
- Test regularly and measure. Run planned failover drills, record actual RTO and RPO, and feed the results back into the design.
- Revisit periodically. Region and service capabilities evolve. A decision that was constrained two years ago (no zone support, a missing service) may no longer be constrained, and the reverse can also happen.
Decision Criteria for Choosing a Region
1. Data residency and compliance
Start here, because it is usually a hard constraint rather than a trade-off.
HA vs. DR angle: HA within one region rarely creates residency issues. DR is where residency breaks: a DR target outside the permitted jurisdiction is a compliance failure even if the technical design is perfect. In countries or markets with only one region, you may need a DR approach that stays within the geography, or a documented exception.
2. Service and SKU availability
Not every service, feature or VM size is offered in every region, and new capabilities typically roll out region by region. Preview features are often limited to a few regions. GPU families, specialized VM series, certain database tiers, and AI services with model-specific regional availability are common places where this bites.
Practical approach:
HA vs. DR angle: for HA you need the zone-redundant variants of your services in the primary region. For DR you need every service in the dependency chain to exist in the secondary region, including the less obvious ones: private DNS, key management, monitoring, container registries, and identity-related dependencies.
3. Latency and proximity to users
Physics sets the floor. Round-trip time between your users (or your on-premises estate) and the region is determined by distance and network path, and no amount of tuning removes it.
If you are using paired-region features, design with the pair explicitly in mind.
How Region Choice Changes Architecture: Concrete Examples
Example 1: Database across zones vs. across regions
Take a business-critical Azure SQL Database workload.
The same pattern applies to storage: ZRS for zone resilience, GRS for geographic replication, GZRS for both. Which one is available depends on region support.
Example 2: A required service pins the region
Suppose the design needs a specific service or SKU (a particular GPU family, a database tier, or an AI model that is only deployed in certain regions). If your preferred region lacks it, you have three options: choose another region, adopt a split-region architecture where only that component lives elsewhere, or wait for rollout. Each has costs.
Split-region designs sound attractive but add cross-region latency and data-transfer cost on every call between components, plus a compliance question about what data crosses the boundary. Often the right answer is to move the whole workload to the region that supports the dependency, as long as residency permits.
Example 3: Active-active across regions
For workloads that need very low RTO across regional failure, an active-active design runs the application in two or more regions simultaneously behind a global load balancer. This requires a data tier that supports multi-region writes or a carefully designed partitioning strategy (Azure Cosmos DB is a common choice because it supports multi-region replication natively, with consistency trade-offs you must understand). The region selection criteria all apply twice, and the cost is roughly proportional to the number of active regions.
Most workloads do not need this. Active-passive with tested failover is far more common and far cheaper.
Example 4: Compute across zones
Deploying VMs across zones, or using zone-aware node pools in AKS or zone-redundant App Service plans, delivers HA without a second region. The architecture needs a zone-redundant entry point (Standard Load Balancer, Application Gateway v2) and a zone-redundant or zone-replicated data tier. A single zonal VM with no replication gives you none of this benefit, even though it is "in a zone-enabled region."
Practical Recommendations
Closing
Regions, geographies, pairs and zones are building blocks, not guarantees. The region you pick determines what resilience patterns are available to you, what compliance boundaries you can honor, what your users experience, and what the design costs to run. Treat region selection as an architectural decision with documented criteria, not a default, and verify the current facts against the official Azure documentation before you commit.
