Skip to Content

Global Infrastructure (Regions, AZs, Edge Locations)

When to use

Pick a region for residency/latency; deploy across AZs for HA; accelerate reads with CloudFront.

Analogy

Region = country; AZs = cities within; Edge Locations = airports where content meets the world.

Data-flow diagram

  Region us-east-1
     +-- AZ us-east-1a   (1+ isolated DCs)
     +-- AZ us-east-1b   (private fibre)
     +-- AZ us-east-1c
  Edge Locations: 600+ POPs worldwide (CloudFront caches here)

Deep explanation

AWS Regions are geographic areas (us-east-1, eu-west-1). Each region hosts >= 3 AZs - physically separate data centres on a low-latency private backbone. Resources in different AZs survive a single facility outage (HA). Edge Locations serve CloudFront caches. Replicate stateful services across AZs; front static assets with CloudFront for global latency.

Examples

Example 1

aws ec2 describe-regions \
  --query 'Regions[].RegionName' --output text

lists all 30+ regions enabled on your account.

Example 2

aws ec2 describe-availability-zones --region eu-west-1 \
  --query 'AvailabilityZones[].ZoneName'

shows AZs in eu-west-1 (eu-west-1a, 1b, 1c). Pick distinct AZs for HA.

Example 3

aws cloudfront list-distributions \
  --query 'DistributionList.Items[].DomainName'

Edge Locations serve CloudFront distributions; same domain, 600+ POPs.

Common mistake

Treating one AZ as ‘highly available’ - it isn’t. Always deploy across >= 2 AZs for stateful workloads. Deploying sensitive data in us-east-1 if your compliance regime requires EU residency.

Key takeaway

2+ AZs in 1 Region for HA; 2+ Regions for DR. Pick regions for compliance AND latency. Use Edge Locations via CloudFront to reduce global latency.

Production Failure Playbook

Failure scenario 1: single-az-dependency

Failure scenario 2: us-east-1-picked-for-everything