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 region pairs and nonpaired regions are used in Azure.
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. These region pairs are then used by a small number of Azure services to support geo-replication and geo-redundancy. The pairs are also used to 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.
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 the impact of bugs or logical failures in the rare event of a faulty update, and to prevent downtime to solutions that have been 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.
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.