Regions and Availability Zones

Every cloud resource runs on a physical server in a physical building somewhere. "The cloud" is just someone else's datacenter, and the geography of those datacenters matters enormously for latency, resilience, compliance, and cost. Understanding regions and availability zones is the foundation for designing systems that survive failures.

The Core Concepts

A region is a geographic area — think "Northern Virginia" or "London" or "Tokyo." Each region is fully independent with its own power, networking, and cooling infrastructure. A failure in one region should not affect another.

An availability zone (AZ) is a discrete datacenter (or cluster of datacenters) within a region. AZs within a region are connected by low-latency, high-bandwidth private fiber — typically sub-millisecond latency. But they have independent power supplies, cooling, and networking, so a fire, flood, or power failure in one AZ doesn't take down the others. Most regions have three or more AZs.

Edge locations are smaller points of presence (PoPs) used for content delivery (CDN) and DNS. They're not where you run compute — they're where cached content sits closer to users. All three providers operate hundreds of edge locations globally.

Multi-AZ vs Multi-Region

Multi-AZ deployment means spreading your resources across AZs within a single region. This protects against datacenter-level failures — hardware issues, power outages, network problems in one building. Latency between AZs is negligible (1-2ms), so synchronous replication is practical. This is your baseline for production.

Multi-region deployment means running in multiple geographic regions. This protects against region-level failures and reduces latency for globally distributed users. But it's dramatically more complex: cross-region latency is tens to hundreds of milliseconds, making synchronous replication impractical for most workloads. You're dealing with eventual consistency, conflict resolution, and double the infrastructure cost.

Rule of thumb: multi-AZ is table stakes for production. Multi-region is for when you need global low-latency, regulatory compliance across jurisdictions, or you're big enough that a full regional outage would be catastrophic.

Choosing a Region

Four factors drive region selection:

Latency: deploy close to your users. If your customers are in Europe, don't run in us-east-1 just because it's the default. Every 100ms of added latency costs you conversions.

Data residency: GDPR, data sovereignty laws, and industry regulations may require data to stay in specific geographies. Healthcare data in Germany might need to stay in eu-central-1.

Service availability: not every service is available in every region. New services launch in major regions first (us-east-1, us-west-2, eu-west-1) and roll out to others over months or years.

Price: identical resources cost different amounts in different regions. US regions are typically cheapest; Asia-Pacific and South America are often 10-30% more expensive.

AWS Implementation

AWS has 30+ regions, each with typically 3 AZs (some have 6). AZs are named like us-east-1a, us-east-1b, etc. — but the mapping of letters to physical datacenters is randomized per account so that not everyone's "a" is the same building.

AWS resources are region-scoped by default. An EC2 instance in us-east-1 has no relationship to us-west-2. Some services are global: IAM, Route 53, CloudFront. S3 bucket names are globally unique but data lives in the region you choose.

The us-east-1 problem: this region is the oldest, the largest, and the default. It's where many global services (IAM, billing) have their control planes. It's also had the most outages, and when it goes down, the blast radius is enormous because so many people default to it. Consider whether you actually need to be there.

GCP Implementation

GCP has 35+ regions with typically 3 zones each (named us-central1-a, us-central1-b, etc.). The big architectural difference: GCP's VPC is global by default. A single VPC spans all regions, and subnets are regional. This is simpler than AWS's region-scoped VPCs but means a misconfiguration has a wider blast radius.

GCP also has global resources that don't exist in the same way on AWS: the global HTTP(S) load balancer routes traffic to the nearest healthy backend anywhere in the world using Google's backbone network. This is a genuine differentiator — in AWS, you'd use CloudFront + regional ALBs to approximate this.

Azure Implementation

Azure has 60+ regions — the most of any provider — but not all regions support availability zones. Those that do typically have 3 AZs. Azure also has the concept of region pairs: each region is paired with another region in the same geography (e.g., East US + West US) for cross-region disaster recovery. Some services automatically replicate to the paired region.

Azure's naming uses friendly names like "East US," "West Europe," "Southeast Asia" rather than the code-style naming of AWS and GCP.

Side-by-Side Comparison

Aspect	AWS	GCP	Azure
Regions	30+	35+	60+
AZs per region	Typically 3-6	Typically 3	3 (where supported)
VPC scope	Regional	Global	Regional
Global load balancing	CloudFront + regional ALBs	Native global HTTP LB	Front Door / Traffic Manager
Region pairing	No formal concept	No formal concept	Built-in region pairs
AZ naming	us-east-1a (randomized per account)	us-central1-a (consistent)	Zone 1, 2, 3 (numeric)
Edge locations	400+ (CloudFront)	100+ (Cloud CDN)	170+ (Front Door)

When to Use Which

Every provider has had full regional outages. AWS us-east-1 has gone down multiple times. GCP had a global networking outage in 2019. Azure has had several regional failures. The question isn't whether your region will have an outage — it's whether your architecture can survive it.

For most applications: pick one region close to your users, deploy across all AZs in that region, and call it done. Add a second region only when you have a concrete requirement — global users, regulatory mandates, or an SLA that demands it.

If you're choosing between providers based on geography: Azure has the most regions (great for enterprise compliance), GCP has the best global networking primitives, and AWS has the deepest service availability per region.

Key Takeaways

• A region is a geographic area; an AZ is an independent datacenter within that region — multi-AZ is your baseline for production resilience
• Choose regions based on latency to users, data residency requirements, service availability, and price — in roughly that priority order
• GCP's global VPC and global load balancer are architecturally distinct from AWS and Azure's regional defaults
• Multi-region adds complexity far beyond the infrastructure cost — you're signing up for eventual consistency and conflict resolution
• Every provider has had regional outages; design for failure at the AZ level at minimum
• Avoid defaulting to us-east-1 just because it's the default — it's the most congested region and its outages have outsized blast radius

Next, we'll look at the original cloud primitive that runs inside these zones — virtual machines.