Azure region pairs and nonpaired regions

Azure regions are independent of each other. However, Microsoft 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 nonpaired regions and region pairs 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.

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. 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.

List of region pairs

The table below lists Azure region pairs:

(*) 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.

Nonpaired regions

Azure continues to expand globally, and many of our 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. It's important to understand how multi-region support works for the particular services you use. To learn about the details of each service, see Azure service reliability guides.

List of nonpaired regions

The table below lists Azure regions without a region pair:

Next steps

• What are Azure regions?
• Azure regions with availability zones
• Reliability guidance