beginnerintermediateadvanced

AWS · Regions and Resilience

Regions, Availability Zones, and Resilience

Why multi-AZ is the baseline, and what has to hold at every layer for one failure to stay a degradation

Region ≠ AZ ≠ edgeyou choose a Region, often an AZ, never an edge location
Multi-AZ is the baselinenear-zero cost, no reason to skip it in production
RPO looks back, RTO looks forwarddata you can lose vs time you can be down
Contained layer by layercompute, load balancer, and data each need it independently

1.Region vs Availability Zone vs edge location

A Region is where you choose to run most resources. An Availability Zone is one of several isolated data-center clusters inside it. An edge location is neither — it caches content physically close to a user, outside any Region you picked.

What you actually control at each level

What you actually control at each level
Level	You choose	Fails independently of
Region	Yes — explicitly, per resource	Other Regions
Availability Zone	Sometimes — often spread automatically	Other AZs in the same Region
Edge location	No — AWS routes to the nearest one	Nothing you architect around directly

Command

text

Region              eu-west-1               a geographic area, most services live here
Availability Zone   eu-west-1a, eu-west-1b   isolated data centers inside the Region
Edge location        (unnamed, nearest one)  CDN/DNS point of presence, outside any AZ

You explicitly choose a Region and often an AZ; you never choose an edge location — AWS routes each request to whichever is physically closest.

2.Multi-AZ as the normal production baseline

Every AWS Region has multiple Availability Zones so a single-AZ failure does not have to take your whole service down. Running production in only one AZ throws that protection away for no benefit — spreading across AZs costs nothing extra.

Key features

Every Region has multiple AZs, physically separate
Cross-AZ traffic within a Region is fast and usually low/no cost
A load balancer with multi-AZ targets is the most common pattern
A managed database's Multi-AZ option is a setting, not a redesign
Single-AZ is a deliberate exception, never the unexamined default

What one AZ failing actually does to each

Single-AZ

One AZ outage is a full service outage
No cost saved — same instance types, same pricing
Nothing protects you if that one data center has a bad day

Multi-AZ

One AZ outage degrades capacity, does not take the service down
Cross-AZ data transfer within a Region is typically free or low-cost
The load balancer and Auto Scaling already expect this shape

Command

text

Single-AZ (fragile)                Multi-AZ (baseline)
─────────────────────              ─────────────────────
ALB target: eu-west-1a only   →    ALB targets: eu-west-1a AND eu-west-1b
RDS: single instance          →    RDS: Multi-AZ enabled (--multi-az)

Spreading across AZs is close to free and is what the load balancer and Auto Scaling already expect — single-AZ should be a deliberate exception.

3.Regional vs global services — the architectural implications

A Regional service (EC2, RDS, most of AWS) exists independently in every Region — a Region-wide outage only takes down that Region's copy. A global service (IAM, Route 53) has one instance for the whole account, with no Regional fallback.

Command

text

Regional (independent per Region)     Global (one instance, whole account)
────────────────────────────────      ──────────────────────────────────
EC2, RDS, S3 buckets, Lambda           IAM (identities and policies)
VPC, ECS, most compute/data            Route 53 (hosted zones)
                                        CloudFront (distributions)

A Regional outage isolates to that Region; a global service having a bad day is felt everywhere at once — why IAM and Route 53 aim for very high availability.

4.RPO, RTO, and the resilience vocabulary

RPO is how much data you can afford to lose, in time since the last good backup. RTO is how long you can afford to be down before recovery finishes. Every DR decision is really about which of these you are willing to pay for.

The resilience vocabulary

The resilience vocabulary
Term	Answers
RPO (Recovery Point Objective)	How much data can we afford to lose, measured in time?
RTO (Recovery Time Objective)	How long can we afford to be down before service resumes?
High availability (HA)	Design that tolerates individual component failure without full downtime
Disaster recovery (DR)	The plan for recovering after a large-scale failure — a Region, not one instance
Failover	The act of switching traffic from a failed resource to a healthy one
Active/standby	One side serves traffic; the other is ready but idle until failover
Active/active	Both sides serve traffic simultaneously; either can absorb the other's load
Multi-Region	Resources exist in more than one Region — protects against a Region-wide event

Command

text

Tighter RPO/RTO  →  more replication, more standby capacity, more cost
Looser RPO/RTO   →  cheaper, slower and lossier to recover — a real trade-off, not a shortcut

RPO looks backward at data loss, RTO looks forward at downtime — state both before choosing active/standby, active/active, or multi-Region.

5.Designing so one failure does not become a full outage

Containing blast radius means every layer — compute, load balancing, data — can lose one instance or one AZ and keep serving at reduced capacity, rather than any single failure taking the whole service down.

Key features

N+1 capacity: size for one AZ being unavailable, not just peak load
Health checks must detect real failure, not just "process is running"
No single AZ should hold the only copy of anything you cannot lose
Auto Scaling replaces failed capacity; multi-AZ decides where it lands
This composes: compute, load balancer, and data layer each need it

One AZ failing, layer by layer

detectedwithin secondstrafficshifts to 1bnew capacity needsa live databasefailovercompletes

eu-west-1a fails

power or network event

Load balancer

health check removes 1a targets

Auto Scaling

replaces capacity in 1b

Database

Multi-AZ standby in 1b promotes

Degraded, not down

reduced capacity, still serving

Command

text

Layer            Contained                          Not contained
──────────────   ─────────────────────────────────  ───────────────────────
Compute          ASG spans ≥2 AZs, N+1 sized         min-size in one AZ/subnet
Load balancer     Health check hits a real dependency  Health check is just TCP-open
Data              Multi-AZ replica in a second AZ     Single instance, single AZ

Containment is layer by layer — trace an AZ failure through compute, load balancer, and data, confirming each independently survives with spare capacity.

Spotted a mistake on this page? Tell us.

Read Sheet