sdlc.dev

AWS fundamentals path · Running it · Topic 18 of 18

Resilience: multi-AZ, multi-Region and Well-Architected

Not started

Every building block in this path has a failure boundary: an instance, a zone, a Region, a quota, a dependency. **Resilience** is choosing which of those failures your system must survive, designing for them, and proving that the design works. AWS's **Well-Architected Framework** collects the guidance in six pillars (operational excellence, security, reliability, performance efficiency, cost optimisation and sustainability); the reliability pillar is the one this topic draws on.

Why it matters: Availability is a design choice with a price. Multi-AZ covers the common failures cheaply; multi-Region covers rare ones at a high cost. Knowing which you need, and testing it, is the job.

  1. 1Multi-AZ is the baseline

    Spread every tier over at least two zones (three is better) with load balancers, Auto Scaling and Multi-AZ databases. It handles most real failures.

  2. 2Multi-Region is a business decision

    Surviving a Regional outage means duplicating data and infrastructure, and choosing a disaster recovery strategy from backup-and-restore to active/active.

  3. 3Static stability

    Provision enough capacity in advance to lose a zone, so recovery does not depend on launching resources during the event.

  4. 4Test it

    Failovers you have never rehearsed do not work. Game days and fault injection turn assumptions into evidence.

1

How it works

The explanation, with examples you can run.

Start from two numbers

  • RTO (recovery time objective): how long the service may be unavailable.
  • RPO (recovery point objective): how much recently written data may be lost.

A shop that can be down for a day and lose an hour of orders needs a very different design from a payment system with an RTO of minutes and an RPO of zero. Agree these first; they decide everything else.

Multi-AZ: the default

Spreading across zones within one Region handles instance failures, data centre problems and most zone-wide events, for modest cost and little complexity:

  • Load balancer across at least two zones, targets in every one of them.
  • Auto Scaling groups or ECS and EKS services spread across the same zones.
  • RDS or Aurora with Multi-AZ, DynamoDB and S3 (already multi-zone).
  • One NAT gateway per zone (or a regional NAT gateway), so a zone failure does not cut outbound access everywhere.

Static stability is what makes this hold up: run enough capacity that losing a zone still leaves the rest below their limits, so you do not depend on launching instances or changing configuration while the failure is happening.

Multi-Region: when the business needs it

A Regional outage is rare but real. Surviving it requires data in a second Region (cross-Region replicas, Aurora Global Database, DynamoDB global tables, S3 replication), infrastructure ready there, and a way to move traffic (Route 53 health checks and failover records, or Application Recovery Controller). AWS describes four disaster recovery strategies:

StrategySecond Region holdsRecovery time
Backup and restoreBackups onlyHours
Pilot lightReplicated data, core infrastructure switched offTens of minutes
Warm standbyA scaled-down working copyMinutes
Multi-site active/activeFull capacity serving trafficNear zero

Cost and complexity rise down the table. Active/active also forces you to deal with writes in two places: conflicts, ordering and data that must live in one jurisdiction.

Limit the blast radius

Not every outage is infrastructure. A bad deploy, a configuration push or a runaway client can take down every zone at once. Defences: deploy gradually (one zone or cell at a time, with automatic rollback on alarms), use separate accounts per environment, set timeouts and retries with backoff on every call, protect dependencies with circuit breakers and load shedding, and keep quotas well above normal peaks.

Prove it

Rehearse: fail over the database in staging, block a zone's subnets, kill instances. AWS Fault Injection Service runs such experiments in a controlled way, including simulated zone power interruptions. A recovery plan that has never been run is a hope, not a plan.

2

Check yourself

3 questions. Get them all right to finish this topic.

  1. 1.An app runs in three zones with 3 instances per zone at 60 % CPU. A zone fails. Is it statically stable?
  2. 2.Which disaster recovery strategy has the lowest cost and the longest recovery time?
  3. 3.What are RTO and RPO?

0 of 3 right so far. Get all three to finish this topic.

Go deeper