Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
This article describes how Azure uses region pairs and nonpaired regions.
Azure regions are independent of each other. However, Microsoft associates some Azure regions with another region, where both regions are usually in the same geography. Together, the regions form a region pair. A small number of Azure services use these region pairs to support geo-replication and geo-redundancy. The pairs also support some aspects of disaster recovery in the unlikely event that a region experiences a catastrophic and unrecoverable failure.
However, many regions aren't paired, and instead use availability zones as their primary means of redundancy. In addition, many Azure services support geo-redundancy whether regions are paired or not.
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 multiregion 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 that's paired, using its pair as a secondary region provides several benefits:
- Region recovery sequence. In the unlikely event of a geography-wide outage, one region in every region pair is prioritized for recovery. Components that are deployed across paired regions use one of the regions as the prioritized region for recovery.
- Sequential updating. Azure strives to stagger any planned system updates across region pairs. This approach minimizes the impact of bugs or logical failures in the rare event of a faulty update, and it prevents downtime to solutions that are designed to use paired regions together for resiliency.
- Data residency. To meet data residency requirements, almost all regions reside within the same geography as their pair. To learn about the exceptions, see the list of Azure regions.
Important
Deploying resources to a region in a pair doesn't automatically make them more resilient, nor does it provide automatic high availability, disaster recovery capabilities, or failover. 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 Microsoft-managed failover between those pairs as your primary disaster recovery approach. For example, Microsoft-managed failover of GRS-enabled storage accounts is only performed in catastrophic situations and after repeated failed recovery attempts.
You're not 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. For example, an Azure solution can use Azure Storage in the Canada Central region with GRS storage to replicate data to the paired region, Canada East, while using Azure compute resources located in East US, and Azure OpenAI resources located in West US.
To see a list of regions that includes all region pairs, see List of Azure regions.
Asymmetrically paired regions
Most region pairs are symmetrical, which means that each region is bidirectionally paired with another region. For example, West US is paired with East US, and East US is paired with West US.
Asymmetrical region pairs involve regions that aren't bidirectionally paired. The following list includes public asymmetrical region pairs:
- Brazil South is paired with South Central US, which is outside of the Brazil geography. South Central US isn't paired with Brazil South.
- West India is paired with South India, but South India is paired with Central India.
- India South Central is paired with Central India, but Central India is paired with South India.
- West US 3 is paired in one direction with East US. East US is bidirectionally paired with West US.
For a list of regions that includes all asymmetrical region pairs, see Azure region pairs.
Nonpaired regions
Azure continues to expand globally. Many of the newer regions provide multiple availability zones for higher resiliency and don't have a region pair.
Many Azure services support geo-replication and geo-redundancy between any arbitrary set of regions and don't rely on region pairs. Others might require that you design and implement your own multiregion approaches. For a list of service multiregion capabilities, including those that work between nonpaired regions, see Azure services that support multiple regions. For detailed information about each service, see its reliability guide.
For a list of regions that includes all nonpaired regions, see Azure region pairs.