Global infrastructure

Regions, Availability Zones, edge locations.

Every AWS architecture decision starts with the global infrastructure: Regions, Availability Zones, and edge locations. Understanding how they relate is what lets you design for both low latency and high availability.

Regions and Availability Zones

A Region is a geographic area (like eu-west-1 in Ireland) that contains multiple Availability Zones. An Availability Zone (AZ) is one or more discrete data centers with independent power, cooling, and networking, close enough for low-latency links but far enough apart to fail independently. This two-level structure is the foundation of AWS resilience: you deploy across multiple AZs within a Region so that a single data-center failure does not take down your application. Choose a Region for latency to your users, data-residency requirements, service availability, and cost, since prices vary by Region.

Region: eu-west-1  (Ireland)
 ├─ AZ eu-west-1a   ┐
 ├─ AZ eu-west-1b   ├─ deploy your app across 2–3 AZs
 └─ AZ eu-west-1c   ┘  → survives a single-AZ failure
 
# A subnet lives in exactly ONE AZ; a VPC spans all AZs in the Region.
# Edge locations (100s, separate from AZs) cache content via CloudFront.

Edge locations and global services

Separate from AZs, AWS runs hundreds of edge locations used by CloudFront (the CDN) and other edge services to cache content and terminate connections close to users worldwide. A few services are global rather than Regional — IAM, Route 53, and CloudFront are managed globally — while most (EC2, VPC, RDS, S3 buckets) are Regional. Knowing which scope a service has matters for design: you place compute and data in Regions and AZs for the workload, and use global/edge services to bring it close to users. This global-then-Regional-then-AZ hierarchy is the mental model behind almost every resilient AWS design.