AWS Global Infrastructure (Task 3.2)
AWS Global Infrastructure
Source: https://aws.amazon.com/about-aws/global-infrastructure/Every HA or DR question on the exam reduces to this hierarchy. Seniors reason about it as fault domains: AZ failure is common and cheap to survive (multi-AZ); Region failure is rare and expensive to survive (multi-Region) — the business's RTO/RPO decides how far up you go.
Region — the isolation boundary
Brief: A Region is a geographic cluster of Availability Zones (us-east-1 N. Virginia, eu-west-1 Ireland, ap-south-1 Mumbai…), fully independent of every other Region.
How it works: Regions share nothing — separate failure domains, separate service catalogs, separate pricing. Data does NOT leave a Region unless you explicitly replicate it. Choosing a Region is a four-factor decision: latency to users, service availability, cost differences, and legal/data-sovereignty requirements (German data must stay in Frankfurt).
Real use-case: A company serves users in Brazil, Germany, and Japan. It deploys in sa-east-1, eu-central-1, and ap-northeast-1 for latency, and replicates only non-personal data between them — personal data stays in-region for GDPR.
Gotchas & interview notes: some services are GLOBAL (IAM, CloudFront, Route 53, WAF can be global), some are Regional (EC2, RDS, Lambda), a few exist in one Region only. A Region choice is also a compliance choice — the exam pairs "data sovereignty" with "choose the Region."
Availability Zone — the fault-isolation unit
Brief: An AZ is one or more discrete data centers with independent power, cooling, and networking inside a Region — 2–6 per Region, 3+ in all major ones.
How it works: AZs are deliberately spaced so fires, floods, or power-grid failures hit at most one, yet connected with high-bandwidth, low-latency private fiber so synchronous replication between AZs is practical (RDS Multi-AZ does exactly this). Each AZ has a code like use1-az2 — and importantly, az2 in your account may be a different physical zone than az2 in mine (AWS maps codes per account to prevent predictable targeting).
Example: The default HA pattern: run each tier in at least 2 AZs behind a load balancer. If one AZ fails, the other keeps serving. EC2's SLA promises 99.99% availability for instances spread across 2+ AZs.
Real use-case: A booking API in eu-central-1: ALB spans three AZs, two app instances per AZ in an ASG, RDS Multi-AZ. Overnight, an entire AZ loses power — the ALB stops routing to that AZ's targets, RDS fails over in ~60–120 seconds, users see a brief blip. No data loss, no redesign.
Gotchas & interview notes: AZs do NOT share single points of failure — memorized verbatim by exam takers. Cross-AZ data transfer within a Region is free for RDS/Aurora replication but billed for EC2-to-EC2 chatter (~$0.01/GB each direction) — large inter-AZ chatter is a real cost line. "Multi-AZ" is the default HA answer; "multi-Region" only when the scenario says Region failure, sovereignty, or global latency.
Edge Locations — the latency killers
Brief: Edge locations (and Regional Edge Caches) are the points of presence for CloudFront and Route 53 — hundreds of them in 90+ cities, far more numerous than Regions.
How it works: Edge PoPs cache content close to end users (CloudFront) and answer DNS near users (Route 53 anycast). Regional Edge Caches sit between origin servers and edge PoPs, improving cache hit ratios for less-popular content.
Real use-case: A video platform serves the same 2 MB poster image to Manila users at 280 ms from the origin Region; through CloudFront's Manila edge PoP, the cached copy returns in ~20 ms.
| Unit | Count (approx.) | Purpose |
|---|---|---|
| Region | 30+ worldwide | Isolated geographic clusters of services |
| Availability Zone | 2–6 per Region | Fault isolation domain for HA |
| Edge location | 400+ globally | CloudFront caching, Route 53 DNS |
| Local Zones | Select metros | Millisecond latency for metro users |
| Wavelength Zones | Inside 5G carrier networks | Ultra-low-latency 5G apps (gaming, AR/VR) |
Edge Services: CloudFront vs Global Accelerator
Brief: CloudFront is a CDN — it CACHES content at 400+ edges (static assets, video, API responses). Global Accelerator does not cache: it routes TCP/UDP over the AWS backbone to the nearest healthy Regional endpoint using two static anycast IPs.
How to choose: content that can be cached → CloudFront; non-HTTP (game UDP traffic), static-IP requirements, or instant regional failover for TCP → Global Accelerator. They pair well together (CloudFront origin traffic can ride Global Accelerator).
Real use-case: A gaming company uses Global Accelerator for its UDP game protocol (static IPs + backbone routing) and CloudFront for game downloads and patch files — same edge network, different mechanisms.
Special-Purpose Zones
- AWS Local Zones: compute/storage a few milliseconds from users in a specific metro (e.g., Los Angeles) — media rendering, real-time gaming, VDI that would suffer cross-metro latency.
- AWS Wavelength Zones: infrastructure embedded inside telecom 5G networks — ultra-low-latency mobile experiences (AR/VR, connected vehicles).
- Multiple AZs (same Region): high availability, zero data-copy infrastructure, the default HA answer.
- Multiple Regions: disaster recovery against Regional failures, data sovereignty, lower latency for globally distributed users, business continuity.
When to Use Multiple AZs vs Multiple Regions
- AWS Local Zones: compute/storage a few milliseconds from users in a specific metro (e.g., Los Angeles) — media rendering, real-time gaming, VDI that would suffer cross-metro latency.
- AWS Wavelength Zones: infrastructure embedded inside telecom 5G networks — ultra-low-latency mobile experiences (AR/VR, connected vehicles).
- Multiple AZs (same Region): high availability, zero data-copy infrastructure, the default HA answer.
- Multiple Regions: disaster recovery against Regional failures, data sovereignty, lower latency for globally distributed users, business continuity.