AWS Global Infrastructure
How Regions, Availability Zones, and Edge Locations are laid out physically, and why that layout is the foundation of every AWS availability and latency decision.
Want a visual for this topic?
Generate a diagram tailored to AWS Global Infrastructure — the AI picks whichever visual (architecture, flowchart, ER diagram, etc.) best fits this specific AWS concept.
Sign in to generate a visual →🎓 Learning objectives
- •Explain the difference between a Region, an Availability Zone, and an Edge Location
- •Explain why deploying across multiple AZs increases availability
- •Choose an appropriate Region for a given set of users and compliance requirements
- •Understand which AWS services are Region-scoped, AZ-scoped, or global
What is it?
AWS's global infrastructure is organized as a hierarchy: geographic Regions (large areas like 'US East' or 'Mumbai'), each containing multiple Availability Zones (physically separate data centers within that Region), plus a much larger number of Edge Locations spread across the world for content delivery (CloudFront) and DNS (Route 53). This physical layout is the foundation every AWS availability, latency, and compliance decision is built on.
Why it exists
A single data center can fail — power outage, fire, network cut, flooding. If your entire application runs in one building, that building's failure is your application's failure. AWS built physically separate Availability Zones within each Region specifically so an application can be architected to survive the loss of an entire data center, and built many Regions around the world so companies can place data close to their users (for latency) and within specific legal jurisdictions (for data residency/compliance).
Problem it solves
It solves the single-point-of-failure problem (one data center going down shouldn't take your whole application down), the latency problem (a user in Mumbai getting a response from a server in Virginia is much slower than from a server in Mumbai), and the data-residency/compliance problem (some countries and industries legally require certain data to stay within that country's borders).
Intuition
Think of a Region as a city, and Availability Zones as separate physical buildings within that city — each with its own power supply, cooling, and network connection, but connected to each other by fast private links so they can work together as one system. If one building loses power, the others keep running, and traffic can be redirected to them within seconds. An Edge Location is more like a small local kiosk (there are hundreds of them, all over the world) that just caches copies of your content close to end users, without running your actual application.
Analogy
A national retail chain with regional distribution centers (Regions), each having multiple separate warehouses on different power grids in the same metro area (Availability Zones), plus thousands of small local pickup points around the country for fast last-mile delivery (Edge Locations) — that's structurally the same shape as AWS's Region / AZ / Edge Location hierarchy.
Technical explanation
Each Availability Zone consists of one or more discrete physical data centers with redundant power, networking, and connectivity, and AZs within a Region are connected by high-bandwidth, low-latency private fiber links (typically single-digit-millisecond round trip), while different Regions are connected over the public internet or AWS's backbone with much higher latency (tens to hundreds of milliseconds) because of the physical distance involved. Some AWS services are Regional (e.g. an S3 bucket lives in one Region, though it may replicate data across that Region's AZs internally for durability), some are Zonal (e.g. a specific EC2 instance or EBS volume lives in exactly one AZ), and a few are Global (e.g. IAM, Route 53, CloudFront — these aren't tied to a single Region at all).
Architecture
A highly available architecture typically deploys redundant resources across at least 2, often 3, Availability Zones within a Region: e.g. an Auto Scaling Group with EC2 instances spread across 3 AZs, behind a Load Balancer that also spans all 3 AZs, with an RDS database configured Multi-AZ (a synchronously replicated standby in a second AZ that takes over automatically if the primary AZ fails). If one entire AZ goes down, the other AZs continue serving traffic with no manual intervention.
Workflow
When you launch a resource, you first pick a Region (in the Console's top-right selector or via the --region CLI flag), then for zonal resources like EC2 you either pick a specific AZ explicitly or let AWS auto-place it; for a highly-available design, you explicitly spread resources across multiple AZs rather than letting everything default to one.
Example
An e-commerce site serving Indian customers deploys entirely in ap-south-1 (Mumbai) for low latency to those users, with EC2 instances and RDS spread across ap-south-1a, ap-south-1b, and ap-south-1c. During a monsoon-related power event affecting one Mumbai data center (one AZ), the Auto Scaling Group and Load Balancer automatically continue routing traffic to the healthy instances in the other two AZs — users see no downtime, even though a third of the physical infrastructure is offline.
Real-world usage
AWS's own published Regional outage post-mortems (e.g. the well-known 2021 us-east-1 incidents) repeatedly show that services and customer applications architected across multiple AZs within the affected Region continued operating, while single-AZ deployments went down — this is cited directly in AWS's own Well-Architected best practices as the primary justification for multi-AZ design being close to mandatory for production workloads.
Trade-offs
Multi-AZ within a single Region is the standard, relatively low-cost way to get high availability against data-center failures, and is considered close to mandatory for production workloads. Multi-Region adds protection against a whole-Region outage and reduces latency for globally distributed users, but multiplies operational complexity — data replication, consistency, failover orchestration, and cost all increase substantially, so most teams only go multi-Region when the business impact of a Regional outage or the latency needs of a genuinely global user base justify it.
Visual explanation
Draw three nested circles. The outermost circle is 'AWS Cloud' (the whole global network). Inside it are several large ovals labeled with Region names (us-east-1, eu-west-1, ap-south-1, ...) — each Region is geographically separate and mostly independent. Inside each Region oval are 3+ smaller circles labeled AZ-a, AZ-b, AZ-c — these are physically separate data centers within that Region, connected by dedicated low-latency fiber. Scattered outside all of this, as small dots covering the whole map, are Edge Locations — far more numerous than Regions, used only for caching/DNS, not for running your compute.
Advantages
- —
Multi-AZ deployment gives high availability against data-center-level failures without needing multi-Region complexity
- —
Choosing a Region close to users directly reduces network latency for every request
- —
Global services (IAM, Route 53) mean identity and DNS configuration doesn't need to be duplicated per Region
- —
Edge Locations (used by CloudFront) push content close to users worldwide without running compute in every Region
Disadvantages
- —
Cross-AZ data transfer within a Region isn't free — high-traffic multi-AZ architectures incur real data transfer costs
- —
Multi-Region architectures (for disaster recovery or global latency) are significantly more complex than multi-AZ — data replication across Regions has real latency and consistency tradeoffs
- —
Not every AWS service is available in every Region — newer services often launch in a handful of Regions first
- —
A full Region-wide outage (rare, but has happened) is not protected against by multi-AZ alone — only a multi-Region architecture protects against that
Common mistakes
- —
Deploying all resources into a single Availability Zone 'because it's simpler,' silently creating a single point of failure that only shows up during an actual AZ outage
- —
Assuming multi-AZ automatically protects against a whole-Region outage — it doesn't; that requires a multi-Region architecture
- —
Choosing a Region based on habit or a tutorial's default (often us-east-1) rather than actual user proximity or data-residency requirements
- —
Forgetting that cross-AZ (and especially cross-Region) data transfer has real cost and latency implications that should be factored into architecture decisions
In the AWS Console
- 1
AWS Console → EC2 → Launch Instance → Network settings
Under Subnet, note the dropdown shows options like 'No preference' or specific subnets tied to specific AZs (e.g. ap-south-1a).
Picking 'No preference' lets AWS auto-place the instance; for a highly-available design you'd instead deliberately launch instances across multiple AZ-specific subnets.
- 2
AWS Console → EC2 → Load Balancers → Create Load Balancer
In the Availability Zones section, select at least 2 (commonly all available) AZs for the load balancer to span.
A load balancer that only spans one AZ can't route around that AZ's failure — always select multiple.
- 3
AWS Console → RDS → Create database → Availability & durability
Toggle 'Multi-AZ deployment' to create a synchronously replicated standby database in a second AZ.
This roughly doubles the database cost but means an AZ failure triggers automatic failover instead of downtime — a core Well-Architected reliability practice.
🎤 Interview questions
What's the difference between a Region, an Availability Zone, and an Edge Location? (Listen for: Region = large geographic area; AZ = physically separate data center(s) within a Region; Edge Location = local caching/DNS point, not compute.)
Why does deploying across multiple Availability Zones increase availability? (Listen for: AZs have independent power/network/cooling, so one AZ's failure doesn't take down resources in other AZs.)
Does a multi-AZ deployment protect you from a full Region outage? (Listen for: no — multi-AZ protects against data-center-level failure within a Region; only multi-Region protects against a whole-Region outage.)
How would you choose which AWS Region to deploy a new application into? (Listen for: proximity to users/latency, data residency/compliance requirements, service availability in that Region, cost differences between Regions.)
📂 Subtopics
Regions and Availability Zones
Why Regions are geographically independent and AZs within a Region are physically separate but tightly connected.
~10 min
Edge Locations & Global Services
The much larger network of caching points used by CloudFront, and the handful of AWS services that aren't tied to any single Region.
~8 min