Regions and Availability Zones
The geography of resilience and compliance
A region is an isolated geographic cluster of data centers; availability zones are isolated data centers within it. Resilient designs span AZs; compliant designs care about regions.
What you will learn
- Distinguish regions, AZs and edge locations
- Design for AZ independence (no single points of failure)
- Use regions for both latency and data-residency requirements
A region is a set of independent data centers (AZs) in one geographic area. Spread your critical workloads across at least two AZs so one burning data center can't take you down.
What is this?
Cloud providers organize infrastructure into regions — distinct geographic clusters of data centers — and within each region, availability zones (AZs) which are separate, fault-isolated facilities with independent power and networking. Edge locations (CDN/global accelerator points of presence) sit outside this model for caching and acceleration. Regions are fully independent: services, data and accounts are isolated per region unless you deliberately replicate.
Why do you need it?
- AZ independence gives you real HA: power, cooling or network loss in one AZ must not affect the other.
- Region isolation is your compliance lever: data in 'eu-central-1' stays inside the EU boundary.
- Latency follows physics: serving Brazilian users from US-East adds real round-trip time.
- Provider outages are usually scoped to a region or AZ — spreading workloads capitalizes on that.
Mental model
Separate buildings of a campus vs the campus itself
AZs vs a region
If one building loses power, the other keeps running — that's AZ redundancy. The whole campus (region) like the whole city can still fail, which is why cross-region DR exists as a separate question.
How it works
- Each region hosts multiple AZs; each AZ is one or more data centers with independent power, network and cooling.
- AZs interconnect with very low-latency, high-bandwidth links so you can replicate between them cheaply.
- Region pairs (e.g. GCP regions <25km apart for synchronous replication; Azure availability regions; AWS has no fixed pairings but supports region replication services) provide different models of cross-region DR.
- Traffic to an AZ is served by that AZ's resources; you control placement via subnets, instance config or load balancer settings.
- Edge locations cache content near users but do not host your durable state — they accelerate, they don't store truth.
Regions, AZs, and edge locations.
Examples
Ask the platform which regions and AZs exist
# List regions your account can use (read-only, free)aws ec2 describe-regions --output table # List AZs inside one region (read-only, free)aws ec2 describe-availability-zones --region us-east-1 --output table # No credentials? These public endpoints still answer:curl -s https://api.github.com/meta | grep -o '"[a-z0-9-]*"' | head -5describe calls are read-only and cost nothing. If your CLI isn't configured, the curl example replaces the demo with a public, credential-free API — the point is that geography is discoverable, not magic.
In production
- An API service runs an autoscaled fleet across three AZs with a regional load balancer; losing one AZ changes latency, not availability.
- A multi-AZ managed database keeps a synchronously replicated standby in another AZ for automatic failover.
- A company with EU customers pins all PHI storage to eu-central-1 and blocks other regions at the organization level.
Best practices
- Replicate critical workloads across ≥2 AZs and test that each AZ can carry the full load alone.
- Keep session/data access inside the region wherever possible — cross-region calls add latency for every request.
- Enforce allowed regions at the organization/folder level to prevent accidental non-compliant infrastructure.
- Choose regions for your users' latency and your compliance requirements, not for where the provider's logo is largest.
Common mistakes
- Launching everything in one AZ and calling it HA, because 'it's in the cloud'.
- Choosing a region for latency but ignoring that its compliance profile forbids your data.
- Assuming AZ failure is impossible — providers warn AZs fail independently; single-AZ deployments still go down.
- Replicating across regions and ignoring the replication latency and conflict cost.
Common issues
Whole app errors during one AZ eventAll instances are in the same AZ despite 'cloud' expectations
Fan the fleet and databases across ≥2 AZs and test single-AZ evaporation in a game day.
Data residency audit fails for one regionReplication or backup job wrote outside approved regions
Add organization/folder-level allowed-region policies and list all replicated destinations.
Users two continents away report slownessSingle-region app plus long physical distance
Move to multi-region or use global acceleration/CDN layers that shorten the path.
Debugging tips
- When an AZ degrades, confirm your footprint in the remaining AZs can absorb 100% of load before scaling hard.
- Check AZ health via provider status pages before assuming your config is at fault.
- Use latency CLI tools in the region your users are in, not your office, to measure true user-facing latency.
- Verify a cross-AZ copy actually lives in a separate AZ — a 'multi-AZ' label on one subnet is a trap.
Interview checkpoint
Hands-on lab
- List regions available to your cloud account
- Map availability zones inside one region
- Practice reading geography from the CLI without creating anything
Discover Regions and Availability Zones
25 min · beginner
Quick quiz
Which of these provides true fault isolation from a single data center failure?
An availability zone is never within the same physical building as another AZ.