beginnerintermediateadvanced

AWS · Section 3

AWS Regions, Availability Zones, and Resilience

Level: intermediate
Read: 26 min
Concepts: 5

Every AWS Region has multiple isolated Availability Zones specifically so a single AZ failure does not have to take a whole service down. This section covers what Region/AZ/edge location each actually control, why multi-AZ is the default rather than an upgrade, and how to verify a design is contained layer by layer rather than assuming it.

AWS overview

AWS Full Course 2026 | AWS Cloud Computing Tutorial for Beginners | AWS Training | SimplilearnSimplilearn

What is true here

You explicitly choose a Region and often an AZ; an edge location is chosen for you, by proximity, never architected around directly.
Multi-AZ is close to free within a Region — treat single-AZ production as a deliberate, examined exception, not the unexamined default.
A Regional outage isolates to that Region; a global service (IAM, Route 53) failing is felt everywhere at once, with no Regional fallback.
RPO (data you can lose) and RTO (time you can be down) should be stated explicitly before choosing a disaster recovery strategy.

What you will be able to do

Explain what you control at the Region, AZ, and edge-location level, and what AWS controls instead
Justify multi-AZ as the default for production rather than an optional upgrade
State a system's RPO and RTO targets, and connect them to active/standby vs active/active vs multi-Region
Trace a single AZ failure through compute, load balancer, and data, and identify which layer is not actually contained

What one AZ failure has to survive

Multi-AZ baseline

spread across ≥2 AZs from the start

RPO / RTO targets

how much data loss, how much downtime

Every layer contained

compute, load balancer, data — each survives alone

Degraded, not down

Regions, Availability Zones, and Resilience

What each level of the AWS map actually controls, and how to design so one failure stays a degradation.

Region vs Availability Zone vs edge location

standardintermediate

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.

Think of it as

A national retail chain. The Region is the country you decided to operate in. Availability Zones are separate warehouses inside it, so one warehouse fire does not empty every shelf. Edge locations are the small local pickup points scattered everywhere else, holding only what customers grab most often.

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

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

Together

text

# Region: explicit, in every CLI/SDK call
aws ec2 run-instances --region eu-west-1 ...

# AZ: often left to AWS, or spread deliberately
aws ec2 run-instances --region eu-west-1 --placement AvailabilityZone=eu-west-1a

# Edge location: never named — CloudFront picks the nearest one to the requester
curl https://d111111abcdef8.cloudfront.net/photo.jpg

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

See also: core concepts · multi az baseline

Multi-AZ as the normal production baseline

coreintermediate

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.

Think of it as

A restaurant with two kitchens on different floors instead of one. Both cook the same menu. If one floor loses power, service continues from the other — the customer never has to know which kitchen made their order.

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)

What we're doing: See what changes at the infrastructure level between single- and multi-AZ, using the same application.

terminaltext

# single-AZ: every target in one place
aws elbv2 register-targets --target-group-arn tg-app \
  --targets Id=i-0a1b,AvailabilityZone=eu-west-1a Id=i-0c2d,AvailabilityZone=eu-west-1a

# multi-AZ: targets spread across two AZs
aws elbv2 register-targets --target-group-arn tg-app \
  --targets Id=i-0a1b,AvailabilityZone=eu-west-1a Id=i-0c2d,AvailabilityZone=eu-west-1b

3: Both targets sit in the same AZ — losing eu-west-1a removes 100% of capacity.
6: One target per AZ — losing either AZ removes only half of capacity, and the service stays up.

Why this works: The load balancer and the application code do not change at all between these two setups — only which AZ each target lives in. Multi-AZ resilience is almost always a placement decision, not a rewrite.

Assuming an Auto Scaling Group is automatically multi-AZ

Wrong

text

aws autoscaling create-auto-scaling-group \
  --auto-scaling-group-name app-asg \
  --vpc-zone-identifier subnet-0c2d \
  --min-size 2 --max-size 4

Better

text

aws autoscaling create-auto-scaling-group \
  --auto-scaling-group-name app-asg \
  --vpc-zone-identifier "subnet-0c2d,subnet-0e3f" \
  --min-size 2 --max-size 4

What you see: An Auto Scaling Group with min-size 2 looks resilient in the console — two healthy instances — but a single subnet means both instances are in the same AZ, and the group replaces failed capacity in that same AZ.

Why: `vpc-zone-identifier` is what actually determines which AZs an Auto Scaling Group can place instances in. A single subnet means a single AZ, no matter how large min-size or max-size is set.

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

Remember: 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.

Regional vs global services — the architectural implications

standardintermediate

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.

Think of it as

A company with an HR system in head office and a warehouse in every city. If one city's warehouse goes offline, the others keep shipping. If head office's HR system goes down, every city is affected at once — there is no second head office to fail over to.

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)

Remember: 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.

See also: core concepts · multi az baseline

RPO, RTO, and the resilience vocabulary

standardintermediate

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.

Think of it as

RPO looks backward: how far back does the surviving copy of your data go? RTO looks forward: from the moment of failure, how long until customers can use the system again? A tighter number on either axis costs more to build and run.

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

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

Together

text

# a payments system's stated targets
RPO: 5 minutes    → replication must lag no more than 5 minutes behind primary
RTO: 15 minutes   → failover must complete, end to end, within 15 minutes

# active/standby DR in a second Region:
Primary (eu-west-1): serves all traffic
Standby (eu-west-2):  RDS read replica, warmed but idle — promoted on failover

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

Designing so one failure does not become a full outage

coreintermediate

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.

Think of it as

A ship with watertight compartments. One compartment flooding is a repair job; without the compartment walls, the same leak sinks the ship. Each AWS layer — Auto Scaling, load balancer health checks, database replicas — is one of those walls.

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

What we're doing: Trace what actually has to be true at each layer for a real AZ failure to stay a degradation instead of an outage.

failure-trace.txttext

eu-west-1a loses power. What happens to a request arriving right now?

1. ALB health checks against eu-west-1a targets start failing
   → ALB stops routing new requests there within its health-check interval
2. ASG detects unhealthy instances, launches replacements in eu-west-1b
   → only possible because vpc-zone-identifier already included 1b's subnet
3. RDS Multi-AZ standby (already in eu-west-1b) is promoted to primary
   → only possible because --multi-az was set at creation, not added after
4. Result: elevated latency for ~1 minute, zero full outage

2: This step needs nothing extra — health checks fail on their own once the targets stop responding.
4: This step only works because the Auto Scaling Group was already configured to span both AZs — see the mistake below.
6: This step only works because Multi-AZ was enabled before the failure, not something you can add during an incident.

Why this works: Blast-radius containment is not one setting — it is every layer independently surviving the loss of one AZ. A single layer left single-AZ (usually the database, since it is the easiest to forget) turns an otherwise well-contained failure back into a full outage.

Containing compute and the load balancer, but leaving the database single-AZ

Wrong

text

ALB targets:  spread across eu-west-1a and eu-west-1b  ✓
ASG subnets:  eu-west-1a and eu-west-1b                ✓
RDS:          single instance, eu-west-1a only          ✗

Better

text

ALB targets:  spread across eu-west-1a and eu-west-1b  ✓
ASG subnets:  eu-west-1a and eu-west-1b                ✓
RDS:          --multi-az, standby in eu-west-1b        ✓

What you see: eu-west-1a fails. The load balancer correctly routes around it and Auto Scaling correctly launches replacement instances in eu-west-1b — and every one of those new instances immediately fails, because the only database they can reach is also in eu-west-1a.

Why: Containment has to be verified layer by layer. A system can look fully resilient at the compute and networking layer and still have exactly one uncontained dependency — commonly the database — that turns the whole design back into a single point of failure.

One AZ failing, layer by layer

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

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