Azure Global Infrastructure
Regions, zones and paired regions
Azure is built on regions, availability zones and availability sets. Understanding the three tiers — geography, region, zone — decides your latency, residency and HA posture.
What you will learn
- Explain Azure's geography → region → zone hierarchy
- Use availability zones vs availability sets correctly
- Design for regional pairs for disaster recovery
Azure regions are data-center area groupings; zones are physically separate facilities within a region offered by some regions; paired regions provide regional DR via automatic replication for certain services.
What is this?
Azure organizes the world into geographies (e.g. Americas, Europe) containing regions (e.g. eastus, westeurope). Some regions offer multiple availability zones — 3 physically isolated facilities with independent power/cooling/network, connected by redundant low-latency fiber. Availability sets protect against rack faults using fault/update domains (older concept). Regions come in pairs (e.g. East US ↔ West US) for systemic disaster recovery, with data residing inside its geography unless you replicate it.
Why do you need it?
- Zone-aware placement is the difference between surviving a facility failure and not.
- Data residency laws tie storage to a geography; you pick the region the law allows.
- Paired regions give a built-in DR target for complex multi-component systems.
- Not every service pays attention to zones; SQL Database, VM and AKS do, and you must configure them to.
Mental model
A country's cities, hospitals and twin-city agreements
Geography, regions, zones, paired regions
The country (geography) sets the law; cities (regions) host the load; independent hospitals (zones) mean one fire can't kill everything; twin cities (pairs) back each other up in a disaster.
How it works
- Choose a region near your users and data; services are either regional, zonal or global.
- For zonal services (VM, AKS, Azure SQL, Standard Public IP) place replicas across ≥2 zones.
- Availability sets (no zones legacy) group VMs into fault/update domains for rack-level protection.
- Paired regions: during a regional outage Azure may prioritize the paired region; use them for async DC style.
- Continuation and recovery: zone failures are localized; regional failures trigger paired-region strategies.
Azure geographic layers.
In production
- A UK healthcare app runs in uksouth across 3 zones with Azure SQL zone redundancy and Azure Front Door in front.
- A retailer uses regional pairing: primary eastus, async geo-replication of Blob and Azure SQL to westus.
- A gaming backend pins zonal VMs for a low-latency in-region mesh, with AKS node pools spanning 2 zones.
Best practices
- Treat zones as real: configure zonal redundancy, don't rely on a single zonal resource.
- Shoot for cross-zone spreads for VMs, Azure SQL zone redundancy, and AKS across zones.
- Use paired regions for DR, and keep a regional outage playbook.
- Recheck your region announcements yearly — not all services reach all regions.
Common mistakes
- Believing 'the region is available' means every service in it has zones.
- Placing replicas in the same zone because it's cheaper.
- Choosing a region by habit instead of user location + data residency.
- Ignoring paired regions until DR is needed.
Common issues
All replicas fail togetherInstances claim multi-zone but share one availability zone
Verify actual placement with az vm list and spread across ≥2 zones.
Can't provision a service in a 'zone-enabled' regionThe specific service or SKU isn't available in that region
Check regional availability docs or use an alternate region/SKU.
Debugging tips
- For latency variance, measure from the user's region, not your office.
- On a zone failure, Route 53/Azure Front Door weight changes beat redeploys.
- Verify the actual zone of each VM with the Azure CLI, not the label.
- Check whether a service is zonal or regional before chasing cross-zone surprises.
Interview checkpoint
Quick quiz
What is an Azure availability zone?