Azure region pairs and nonpaired regions
Azure regions are independent of each other. However, Azure associates some Azure regions with another region, where both are usually in the same geography. Together the regions form a region pair. Many other regions aren't paired, and instead use availability zones as their primary means of redundancy. This article describes both how region pairs and nonpaired regions are used in Azure.
Region pairs are used by some Azure services to support geo-replication and geo-redundancy, and to support some aspects of disaster recovery in the unlikely event that a region experiences a catastrophic and unrecoverable failure.
However, many Azure services support geo-redundancy whether the regions are paired or not, and you can design a highly resilient solution whether you use paired regions, nonpaired regions, or a combination.
Paired regions
Some Azure services use paired regions to build their multi-region geo-replication and geo-redundancy strategy. For example, Azure geo-redundant storage (GRS) can automatically replicate data to a paired region.
If you're in a region with a pair, then using its pair as a secondary region provides several benefits:
- Region recovery sequence. In the unlikely event of a geography-wide outage, the recovery of one region is prioritized out of every region pair. Components that are deployed across paired regions have one of the regions prioritized for recovery.
- Sequential updating. Planned Azure system updates are staggered across region pairs to minimize downtime, impact of bugs, and any logical failures in the rare event of a faulty update.
- Physical isolation. Azure strives to ensure a minimum distance of 300 miles (483 kilometers) between paired regions, although it isn't possible across all geographies. Region separation reduces the likelihood that natural disasters, civil unrest, power outages, or physical network outages affects multiple regions simultaneously. Isolation is subject to the constraints within a geography, such as geography size, power or network infrastructure availability, and regulations.
- Data residency. To meet data residency requirements, almost all regions reside within the same geography as their pair. To learn about the exceptions, see list of region pairs.
Important
Deploying resources to a region in a pair doesn't automatically make them more resilient, nor does it provide automatic high availability or disaster recovery capabilities or failover. It's critical that you develop your own high availability and disaster recovery plans, regardless of whether you use paired regions or not.
Even if you configure service features to use region pairs, don't rely on Azure-managed failover between those pairs as your primary disaster recovery approach. For example, Azure-managed failover of GRS-enabled storage accounts is only performed in catastrophic situations and after repeated failed recovery attempts.
You aren't limited to using services within a single region, or within your region's pair. Although an Azure service might rely upon a specific regional pair for some of its reliability capabilities, you can host your services in any region that satisfies your business needs.
List of region pairs
The table below lists Azure region pairs:
| Geography | Region in pair | Region in pair |
|---|---|---|
| China | China North | China East |
| China North 2 | China East 2 | |
| China North 3 | China East 3* |
(*) Certain regions are access restricted to support specific customer scenarios, such as in-country disaster recovery. These regions are available only upon request by creating a new support request.