Paired regions, explained
"Paired region" shows up as load-bearing fine print across the catalog — Key Vault's regional failover, Storage's GRS/GZRS, Backup's Cross-Region Restore — but nothing here has explained what it actually is. It's a fixed relationship Microsoft assigns at the platform level, not a secondary region you pick, and a growing share of Azure regions don't have one at all. If your region is one of them, or your paired region fails a compliance requirement, several services' entire built-in DR story quietly stops applying to you.
What it actually is
Microsoft's own definition is narrower than the phrase implies — it's an association a small set of services rely on, not a general resiliency mechanism:
"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… However, many regions aren't paired, and instead use availability zones as their primary means of redundancy."
Two things fall out of that. First, you don't choose your pair — it's determined by the primary region you deploy to, full stop. Second, deploying into a paired region doesn't buy you anything by itself: Microsoft is explicit that "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." It's an assigned relationship that certain features are built on top of — not a resiliency guarantee in its own right.
Which regions don't have one
Azure's newer regions are, deliberately, launched without a pair — they lean on availability zones as the primary redundancy mechanism instead. As of Microsoft's current list, these regions have no paired region at all:
| Geography | Nonpaired regions |
|---|---|
| Americas | Chile Central, Mexico Central |
| Europe | Austria East, Belgium Central, Denmark East, Italy North, Poland Central, Spain Central |
| Middle East | Israel Central, Qatar Central |
| Asia Pacific | Indonesia Central, Malaysia West, New Zealand North |
Treat that table as a snapshot, not gospel — Microsoft adds regions continuously, and the authoritative, always-current source is Azure region pairs and nonpaired regions (cross-check against the full region list before you commit to an architecture). A separate set of regions — Australia Central 2, Brazil Southeast, France South, Germany North, Norway West, South Africa West, Sweden South, Switzerland West, and UAE Central — do have a pair but sit behind Microsoft's restricted-access tier, reserved specifically for DR scenarios rather than general deployment.
The pair isn't always symmetric — or in your geography
Most pairs are bidirectional — East US and West US point at each other. A handful don't, and Microsoft calls these out explicitly as asymmetrical region pairs:
Brazil South → South Central US
South Central US doesn't pair back to Brazil South — and Brazil South's pair sits outside the Brazil geography entirely, in the United States. That's the one exception to Microsoft's usual same-geography rule, and it matters directly for data residency (see below).
West US 3 → East US, one-directional
West US 3 points at East US for pairing purposes, but East US's own bidirectional pair is West US, not West US 3. Key Vault specifically excludes West US 3 from Microsoft-managed cross-region failover as a result — see the built-on-pairing section below.
West India → South India
But South India's own pair is Central India, not West India — a three-region chain, not a simple pair.
India South Central → Central India
Same shape as above, in the other direction: Central India's own pair is South India, not India South Central.
Source: Azure region pairs and nonpaired regions, "Asymmetrically paired regions."
What being paired actually buys you
Three specific benefits, all sourced to the same page — none of them a substitute for a DR plan you designed and tested yourself:
Region recovery sequence
In a geography-wide outage, one region in every pair is prioritized for recovery. Anything you've deployed across a pair uses that prioritized region as its recovery target — a platform-level ordering, not something you configure.
Sequential platform updates
Microsoft staggers planned system updates across the two regions in a pair, so a faulty update rolling out to one side doesn't land on both at once — the direct answer to "does one region of a pair update before the other." Still no committed schedule you can plan around.
Data residency (almost always)
"Almost all regions reside within the same geography as their pair" — good enough for most residency requirements by default, with Brazil South as the one public exception where it isn't.
Source: Azure region pairs and nonpaired regions, "Paired regions." Microsoft's own caveat, verbatim: Microsoft-managed failover between paired regions "is only performed in catastrophic situations and after repeated failed recovery attempts" — plan for it as a last resort, never a primary DR mechanism.
Built on pairing, versus not
This is the split that actually matters when you're picking a service's redundancy option: does its geo-redundancy feature use your fixed pair, or can you point it at any region you want?
| Service / feature | Depends on your pair? | Detail |
|---|---|---|
| Storage GRS / GZRS | Yes — required | "GRS only works within Azure paired regions. If your storage account's region isn't paired, consider using the custom multiregion solutions for resiliency." The secondary region is auto-selected from your primary and can't be customized. |
| Key Vault Microsoft-managed failover | Yes — with named exceptions | Replicates asynchronously to your paired region and may fail over there — except Brazil South, Brazil Southeast, West US 3, and any nonpaired region, which get none of it. Notably, all three named exceptions are exactly the asymmetric pairs above. |
| Azure Backup Cross-Region Restore | Yes — required | Restores into the paired region during a primary-region outage, inheriting the same paired-region dependency as the GRS/GZRS vault it's built on. |
| Cosmos DB multi-region reads/writes | No — fully customer-chosen | "You can configure any Azure region as a read or write region for your Azure Cosmos DB account." No pairing concept involved at all — you pick every region explicitly, including nonpaired ones. |
Sources: Reliability in Azure Blob Storage, Reliability in Azure Key Vault, Reliability in Azure Cosmos DB, and the full Azure services that support multiple regions reference table, which flags every service's paired-vs-nonpaired support explicitly.
When your pair doesn't work for you
Two separate failure modes end up in the same place: your region has no pair at all, or it has one but a compliance requirement rules it out — Brazil South's pair sitting in the United States is the textbook case, since GRS replication would move data outside Brazil by design, not by misconfiguration. Either way, the built-in paired-region feature is off the table, and the fallback is the same shape across every service that hit this limit above:
Storage: Object Replication
Unlike GRS/GZRS's fixed pair, Object Replication copies block blobs asynchronously between storage accounts in any Azure region, paired or not — full control over source and destination, at the cost of managing the replication policy yourself instead of getting it for free with a SKU toggle.
Key Vault: build a second vault
Create a vault in whatever region you actually need, then use backup/restore or app-level dual-write to keep it in sync, with your application failover logic pointed at it — the same pattern the catalog entry for Key Vault already recommends for exactly this gap.
Prefer services that never needed a pair
Cosmos DB's customer-chosen multi-region model is the pattern worth copying architecturally: pick your own region, independent of anyone's pairing table, and the nonpaired-region question stops applying to that piece of the stack entirely.
The one number to remember: even where Microsoft-managed paired-region failover exists and applies to you, it is asynchronous, uncommitted on RPO, and triggered entirely at Microsoft's discretion after a prolonged outage — "a few minutes" of downtime for Storage's customer-managed failover stretches to "several hours or longer" for Microsoft-managed Key Vault failover. Nothing about being in a paired region changes that this is a last-resort mechanism, not a primary DR plan.
See the numbers behind this. The Key Vault catalog entry has the sourced RPO/RTO, the read-only-after-failover behavior, and the exact list of regions that don't get Microsoft-managed failover at all.
Same dependency, different service. The Storage Account catalog entry breaks down GRS/GZRS/RA-GRS against every tier, and where Object Replication becomes the real answer instead.