azure"Deploy across zones" and "use region pairs" get repeated as resilience advice without anyone explaining what each actually protects against. They protect against different failure classes, they cost differently, and picking the wrong one leaves a gap exactly where your next incident lands. Here's the decision, grounded in how real Azure outages have failed.
What availability zones protect
An Azure region is a geography containing multiple availability zones - physically separate datacenters with independent power, cooling, and networking, connected by low-latency links. Deploying across two or more zones (zone-redundant VMs, zone-redundant storage, zonal databases) protects against the single most common serious failure: losing one datacenter. Zone redundancy is also what earns the higher 99.99% VM SLA versus 99.9% for a single instance.
What zones do not protect against is a region-scope event. The July 2024 Central US outage is the cautionary case: a storage-configuration error affected a zone's worth of storage scale units, and workloads without a cross-region plan waited on Microsoft's recovery. Zones are necessary and insufficient.
What only region pairs buy you
A region pair is two Azure regions in the same geography (East US / West US, North Europe / West Europe) with four properties zones can't provide:
- Sequential updates - Microsoft avoids applying platform updates to both regions in a pair simultaneously, so a bad platform change can't take out your whole footprint at once.
- Prioritized recovery - in a broad outage, Microsoft prioritizes restoring at least one region from each pair.
- Physical isolation - pairs are separated by at least ~300 miles, surviving a regional natural disaster.
- Data residency for replication - GRS storage and geo-replicated databases replicate to the pair, keeping data in-geography for compliance.
Region pairs are the answer to the failure class that took down Central US in 2024 and that the January 2023 global WAN event demonstrated at even larger scale - although a truly global control-plane event (WAN, identity) can reach both regions of a pair, which is why pairs are necessary but not a silver bullet either.
The newer-regions wrinkle
Historically every Azure region had a designated pair. Microsoft's newer regions increasingly launch as standalone availability-zone regions without a traditional pair, betting that three strong in-region zones cover most needs. If you deploy into one of these, the automatic paired-region behaviors (GRS's default secondary, sequential update guarantees) don't apply the same way - you must explicitly choose and configure a second region for cross-region resilience. Assuming a pair that doesn't exist is a real and growing gap in Azure DR plans.
Choosing per workload
| Workload tier | Zones | Region pair / second region |
|---|---|---|
| Mission-critical (minutes RTO) | Required | Required - active-passive or active-active |
| Important (tens of minutes) | Required | Warm standby or ASR failover to the pair |
| Standard (hours acceptable) | Required | GRS/geo-backup, restore on demand |
| Deferrable (a day acceptable) | Recommended | Geo-redundant backup only |
The rule: zones are the floor for everything; region pairs (or an explicit second region) are the ceiling you buy up to based on RTO/RPO. Set those targets in the business continuity hub first, then use this table to spend the minimum that meets them - and if you're in a newer standalone region, make the second region a deliberate choice, not an assumption.