Azure Regions & Zone Redundancy

Key Points

• Region = a set of datacenters in a geographic area. Availability Zone (AZ) = independent physical datacenter within a region (separate power, cooling, network). Most major regions have 3 zones.
• Paired regions (East US ↔ West US, North Europe ↔ West Europe) get coordinated maintenance windows and pair-aware geo-replication. Microsoft is moving away from strict pairing for newer regions (Azure Regional Pairs deprecation announced for many services).
• Zone-redundant SKUs auto-spread across 3 zones (you don't pick a zone). Zonal SKUs pin to a specific zone (1, 2, 3) — for proximity to other zonal resources.
• Geo-redundancy is async to a paired region: GRS, GZRS, RA-GRS, RA-GZRS. RPO is seconds-to-minutes; expect data loss in unplanned failover.
• Don't accidentally mix zone-redundant compute with zonal storage — your "zone-resilient" app actually has a zonal SPOF.

Concepts (deep dive)

Region structure

Geography (e.g., United States)
 ├─ Region (East US)
 │   ├─ AZ 1  ─ datacenter cluster
 │   ├─ AZ 2  ─ datacenter cluster
 │   └─ AZ 3  ─ datacenter cluster
 └─ Region (West US)
     └─ ...

A region is one or more buildings within ~100 km of each other; round-trip latency between zones in a region is typically 1–2 ms.

Paired regions

Microsoft historically paired regions for: - Coordinated maintenance: paired regions are not patched simultaneously. - Sequential platform updates: rollbacks possible across the pair. - Geo-replication targets: GRS/GZRS replicate to the pair by default. - Same geography: data residency stays inside a sovereign boundary.

⚠️ Newer regions are not paired. Azure published a guidance shift: many newer services let you pick the geo-replication target explicitly. Don't assume "GRS = my paired region" without checking the service docs.

Availability zones

Region: East US
 ┌──────────────────────────────────────────────────┐
 │  AZ 1            AZ 2            AZ 3            │
 │ ┌──────┐        ┌──────┐        ┌──────┐         │
 │ │ DC   │        │ DC   │        │ DC   │         │
 │ │ pwr  │        │ pwr  │        │ pwr  │         │
 │ │ net  │        │ net  │        │ net  │         │
 │ │ cool │        │ cool │        │ cool │         │
 │ └──────┘        └──────┘        └──────┘         │
 │   └────── ms-level latency ──────┘               │
 └──────────────────────────────────────────────────┘

Each AZ has independent power, cooling, networking. A zone outage takes out one DC; the other two keep running.

Zonal vs zone-redundant

💡 The trap: a zone-redundant App Service Plan with a zonal SQL Database = your DB is the SPOF. Always check the stateful tier.

Service zone-redundancy support (commonly asked)

Geo-redundant storage variants

LRS   ─ 3 copies in 1 DC (1 zone)
ZRS   ─ 3 copies across 3 zones in 1 region
GRS   ─ LRS + async LRS in paired region
GZRS  ─ ZRS + async LRS in paired region
RA-*  ─ Read-Access variant; paired region readable

• RPO for GRS/GZRS: typically <15 minutes, often seconds.
• Failover is manual for most services until you initiate it (or Microsoft does in catastrophic regional loss).
• Cost: GRS roughly 2× LRS for write traffic; ZRS small premium over LRS.

Designing for zone failure (within region)

Goal: tolerate one of 3 zones going dark.

   Front Door / App Gateway (zone-redundant)
            │
   ┌────────┼────────┐
   │        │        │
   AZ1     AZ2      AZ3
   App     App      App
   instance×N  zone-redundant pool
            │
       Azure SQL DB (Business Critical, ZR)
            │
       Storage GZRS / Cosmos with AZ

Checklist: - ✅ Load balancer / ingress: zone-redundant - ✅ Compute: zone-redundant SKU OR ≥3 instances spread zonal - ✅ Stateful tier: ZR-enabled - ✅ Storage: ZRS/GZRS - ✅ Caching layer: Redis Premium with zone redundancy - ❌ Don't pin to one zone unless that's an explicit design choice (low-latency colocation)

Designing for region failure

A region disaster (rare but real — Sydney Sept 2018, Texas Feb 2021) requires cross-region architecture.

Active-active (paired stamps)

   Front Door (global, anycast)
        │
    ┌───┴───┐
   East US  West US
    stamp    stamp
   (full)   (full)
        ↕ Cosmos multi-region writes
        ↕ Storage GZRS / cross-region read

Both regions serve traffic. Higher cost; lowest RTO. Requires multi-master data tier (Cosmos with multi-region writes, or app-level conflict resolution).

Active-passive (warm standby)

   Traffic Manager / Front Door
        │
   Primary (East US)  ──asynch──►  DR (West US)
   full traffic                    minimum compute,
                                   read replicas

DR scaled to minimum; promote on failover. Cheaper; minutes-to-hours RTO.

Pilot light / cold DR

ARM templates ready, no compute running. Cheapest, but RTO is hours/days. Acceptable for low-tier services.

Read-your-writes after regional failover

GRS/GZRS failover means promoting the secondary to primary. Any writes after the last replication will be lost. App design should: - Tolerate idempotent retries for writes lost during failover. - Use Cosmos Session consistency + multi-region writes for read-your-writes guarantees. - Track event sourcing or outbox for replay after failover.

Compliance / data residency

• Geographies group regions by sovereignty: US, Europe, China, Government.
• Data sovereignty: paired regions are in the same geography — your data does not leave the boundary on geo-replication.
• Sovereign clouds: Azure US Government, Azure China (operated by 21Vianet). Azure Germany was sunset; data moved to mainstream German regions.

⚠️ GDPR / data residency: explicitly choose region pair (or single region with ZRS only) to keep data in-jurisdiction. Some EU customers refuse cross-Atlantic geo replication entirely.

Cost: what zone/geo redundancy actually costs

💡 Don't pay for GZRS on transient telemetry; LRS is fine for replaceable data.

Decision matrix

How it works under the hood

• AZs are physically separate but share the regional fabric controllers and global Azure control plane. A zone outage is a data-plane event, not a control-plane.
• GRS replication uses Azure's internal pipeline: writes commit to LRS first, then async to paired region. Lag depends on write volume.
• Geo-failover flips DNS / control-plane targets; it's not instant — typically tens of minutes to coordinate, plus app reconfiguration.
• Front Door uses anycast: same IP advertised from 100+ POPs; BGP routes clients to nearest healthy edge.
• Traffic Manager is DNS-based: clients resolve to a region's IP via TM-controlled DNS; respects TTL (usually 60s).

Code: correct vs wrong

❌ Wrong: zone-redundant app + zonal storage

// App Service Plan zone-redundant: ✅
plan: { sku: 'P1v3', zoneRedundant: true }

// But linked Storage Account is LRS: ❌
storage: { sku: 'Standard_LRS' }

App tier survives a zone outage; storage doesn't. Whole stack down.

✅ Correct: matched redundancy

plan:    { sku: 'P1v3', zoneRedundant: true }
storage: { sku: 'Standard_ZRS' }
sql:     { sku: 'BusinessCritical', zoneRedundant: true }

❌ Wrong: 2-region active-active without multi-master DB

Both regions accept writes into the same SQL DB → split-brain or one region writes blindly fail.

✅ Correct: Cosmos multi-region writes OR partition by region

new CosmosClientOptions
{
    ApplicationRegion = Regions.EastUS,
    ConsistencyLevel = ConsistencyLevel.Session
};
// Cosmos account configured with multi-region writes enabled

❌ Wrong: hardcoded region name

var endpoint = "https://myacct.eastus.kusto.windows.net";

Failover requires code change.

✅ Correct: configuration-driven

var endpoint = config["DataEndpoint"];   // can swap on failover

Design patterns for this topic

Pattern 1 — "Zone-redundant by default"

• Intent: make HA the default; pay the small premium for ZR SKUs everywhere.

Pattern 2 — "Active-passive paired region"

• Intent: affordable DR with minutes-to-hours RTO.

Pattern 3 — "Active-active with Front Door"

• Intent: lowest RTO; users always hit nearest healthy region.

Pattern 4 — "Stateful tier matches stateless"

• Intent: never have zone-redundant app over zonal data.

Pattern 5 — "Failover drill quarterly"

• Intent: rehearse so the DR plan actually works.

Pros & cons / trade-offs

When to use / when to avoid

• Use zone-redundant SKUs as default for any prod workload above tier 3.
• Use GZRS for compliance-critical data and tier 1 services.
• Use active-active for global SaaS and tier-0 services.
• Avoid GRS for transient/derivable data — pay for what you actually need to recover.
• Avoid mixing zonal and zone-redundant tiers — easy to create silent SPOFs.
• Avoid assuming Microsoft will failover for you — most services require manual initiation.

Interview Q&A

Q1. Region vs zone? Region = geographic area with one or more datacenters. Zone = physically independent DC within a region (own power/cooling/network).

Q2. Paired regions? Microsoft pairs regions (East US ↔ West US) for coordinated maintenance and default geo-replication targets. Newer regions may not be paired.

Q3. Zonal vs zone-redundant? Zonal = pinned to specific zone. Zone-redundant = service auto-spreads across zones for HA.

Q4. LRS / ZRS / GRS / GZRS? LRS: 1 zone. ZRS: across zones. GRS: LRS + async to paired region. GZRS: ZRS + async cross-region.

Q5. RPO for GRS? Async, typically <15 min, often seconds. Failover may lose recent writes.

Q6. How to design for zone failure? Use ZR SKUs for compute, storage, and stateful tier. Don't mix.

Q7. Active-active vs active-passive? Active-active: both regions serve, lowest RTO, highest cost. Active-passive: standby promoted on failover, cheaper.

Q8. Front Door vs Traffic Manager for global? Front Door: L7 anycast, edge cache, WAF. Traffic Manager: DNS-only, supports any protocol.

Q9. Manual vs auto failover? Most services manual; you initiate. Cosmos can auto-failover writes if configured.

Q10. Why not always GZRS? Cost (~2.5× LRS) + write latency. Use only where data loss is unacceptable.

Q11. App Service zone redundancy? Premium v3 plan with zoneRedundant: true and ≥3 instances.

Q12. Read-your-writes after region failover? Some recent writes may be lost (async lag). Design idempotent writes; consider Cosmos multi-region with Session consistency.

Gotchas / common mistakes

• ⚠️ Zonal disk on zone-redundant VM scale set — disk pin defeats HA.
• ⚠️ GRS = paired region assumed — verify; some newer regions configurable.
• ⚠️ No DR drill — paper plans break in practice.
• ⚠️ Forgetting DNS / config — failover code path references primary endpoints.
• ⚠️ Writes during failover — async lag = data loss; warn users.
• ⚠️ Cost surprise — GZRS doubles write cost; not free.
• ⚠️ Mix of zonal and zone-redundant in same stack.
• ⚠️ Cosmos not enabled for AZ — by default, region replicas may not span zones; check setting.

Further reading

• MS Learn: Regions and AZs
• MS Learn: Region pairs
• MS Learn: Storage redundancy
• Azure Architecture Center: Multi-region
• Azure SLA summary