Cloud regions, availability zones, and data residency — where your workloads physically run, how AZ isolation prevents outages, and what data residency means in practice for compliance.
Cloud regions, availability zones, and data residency — where your workloads physically run, how AZ isolation prevents outages, and what data residency means in practice for compliance.
A cloud region is a distinct geographic area — a named cluster of data centers owned and operated by one cloud provider. Regions are completely isolated from each other: separate power grids, separate networks, and often separate legal jurisdictions. AWS has 33 launched regions (2025); GCP has 40+; Azure has 60+.
An Availability Zone (AZ) is one or more physically separate data centers within a single region. AZs in the same region are connected by high-bandwidth, ultra-low-latency private fiber (typically <2ms), but each has its own power, cooling, and physical security. If one AZ floods, the others in the region keep running.
Why the distinction matters operationally
Most cloud HA (high availability) patterns deploy across multiple AZs in the same region — this protects against hardware failures, power outages, and network issues in a single data centre. Multi-region is reserved for disaster recovery (DR) scenarios where an entire geographic area becomes unavailable or for global latency requirements. AZ-level HA is the baseline; multi-region is the advanced play.
| Scope | What it protects against | Examples | Typical use |
|---|---|---|---|
| Single AZ | Nothing — single point of failure | eu-west-1a only | Development environments only |
| Multi-AZ (same region) | Data centre failure, power outage, AZ-level network issue | eu-west-1a + eu-west-1b + eu-west-1c | Production HA baseline |
| Multi-Region | Full region outage, regional internet disruption, catastrophic events | us-east-1 + eu-west-1 | Disaster recovery, global latency, compliance |
Deploying across multiple AZs is the most common resilience pattern in cloud architecture. Managed services handle AZ distribution for you — but only if you configure them correctly.
Key services and their multi-AZ behaviour
Cross-AZ data transfer costs money
Traffic between AZs in the same region is NOT free. AWS charges $0.01/GB each way for cross-AZ traffic. In a high-throughput system (e.g. 10 TB/day of inter-service traffic across AZs), this adds up to ~$100/day just in cross-AZ transfer. Design to minimise cross-AZ traffic: co-locate compute and its primary database replica in the same AZ when possible.
1# Verify an ALB is deployed across multiple AZsAn ALB should span all available AZs in the region for maximum resilience2aws elbv2 describe-load-balancers \3--names my-production-alb \4--query 'LoadBalancers[0].AvailabilityZones[*].ZoneName' \5--output text6# Check which AZs an RDS Multi-AZ instance usesSecondaryAvailabilityZone is the standby AZ — should be different from the primary8aws rds describe-db-instances \9--db-instance-identifier my-production-db \10--query 'DBInstances[0].{AZ:AvailabilityZone,MultiAZ:MultiAZ,SecondaryAZ:SecondaryAvailabilityZone}'11# Describe AZs available in the current region13aws ec2 describe-availability-zones \14--query 'AvailabilityZones[*].{Name:ZoneName,State:State}' \15--output table
Data residency is the requirement that certain data must be stored and processed within a specific geographic boundary — most commonly a country or jurisdiction. Cloud providers do not move data between regions unless you explicitly configure cross-region services.
| Regulation | Geographic scope | Key requirement | Cloud impact |
|---|---|---|---|
| GDPR (EU) | European Economic Area | Personal data of EU residents must be processed lawfully; transfers outside EEA require adequacy decision or SCCs | Use EU regions (eu-west-1, eu-central-1, etc.); avoid logging PII in US-region CloudWatch |
| UK GDPR | United Kingdom | UK-equivalent of GDPR post-Brexit | Separate UK regions (eu-west-2 London for AWS) |
| China PIPL | China | Personal data of China residents must be stored in China | Must use AWS cn-north-1 or cn-northwest-1 (separate entity from global AWS) |
| India DPDP | India | Financial and health data may need to remain in India | Use ap-south-1 Mumbai |
| FedRAMP (US Gov) | United States government data | Federal data must stay in FedRAMP-authorized regions | AWS GovCloud (us-gov-west-1, us-gov-east-1) |
Always verify which services are available in your required region before designing the architecture
Not every AWS/GCP/Azure service is available in every region. AWS has 200+ services but many are only in us-east-1 first, and some regions (especially newer ones or gov cloud) have a significantly smaller service catalog. Check the regional availability matrix before choosing a region for a compliance-constrained project.
Cloud engineer, solutions architect, and DevOps interviews always include AZ and region questions. Expect to design a multi-AZ architecture and explain failover behaviour for each tier.
Common questions:
Strong answer: Immediately asks about RTO/RPO when multi-region is mentioned. Distinguishes between AZ-level HA (common) and region-level DR (expensive, complex). Mentions specific services (ALB, RDS Multi-AZ, ASG) and their AZ behaviour.
Red flags: Confuses AZs with regions. Does not mention data residency when discussing EU deployments. Thinks "multi-AZ" and "multi-region" mean the same thing.
Match the cloud component to its AZ/Region role
0 / 6 matched
Match each AWS service or concept on the left with its correct availability and failover characteristic on the right.
Quick check · Regions & Availability Zones
1 / 5
Key takeaways
What is the single configuration that makes a subnet "public" in AWS?
A route table entry with destination 0.0.0.0/0 pointing to an Internet Gateway. Without this route, even a subnet labelled "public" is not internet-reachable.
Your RDS Multi-AZ instance fails over. Application reconnection takes 8 minutes. What is most likely wrong?
The application is caching the resolved IP address of the RDS endpoint DNS name instead of re-resolving it. RDS failover works by updating the DNS record; if the app caches the IP, it keeps connecting to the failed AZ. Fix: reduce DNS TTL and use RDS Proxy for connection pooling.
💡 Analogy
Think of regions as different cities, and AZs as different buildings within each city. If a building catches fire, the other buildings in the same city are fine (multi-AZ resilience). If a natural disaster hits the entire city, you need your backup office in a different city (multi-region DR). Most of the time, having offices in multiple buildings of the same city is sufficient protection.
⚡ Core Idea
AZs protect against hardware and data centre failures (the common case). Regions protect against geographic-scale events (the rare but catastrophic case). Multi-AZ is the baseline for any production workload; multi-region is for DR or global user bases.
🎯 Why It Matters
Virtually every cloud architecture interview question assumes you know to deploy across multiple AZs. Deploying in a single AZ is considered a design defect in production. Understanding the cost (cross-AZ transfer fees) and how managed services handle AZ failures distinguishes senior engineers from juniors.
Related concepts
Explore topics that connect to this one.
Ready to see how this works in the cloud?
Switch to Career Paths for structured paths (e.g. Developer, DevOps) and provider-specific lessons.
View role-based pathsSign in to track your progress and mark lessons complete.
Questions? Discuss in the community or start a thread below.
Join DiscordSign in to start or join a thread.