Medium · 8 steps · ~40 min

Design a web tier that survives a zone failure

Spread across zones, size for N+1, and know what each failover really does.

Availability Zones are separate failure domains inside a Region. A web tier in one zone goes down with it. You will spread tasks across zones, size capacity so the survivors can carry the load, and plan for the database writer failing.

Same problem as Customer portalsBooking sitesLine-of-business apps

This lab uses real AWS services. Limits are AWS's documented default quotas; figures AWS does not publish are marked as assumptions on each component. See every source and assumption.

How it works

• An ALB sends requests only to healthy targets in the zones you enable. Each target is checked every 30 seconds by default and removed after 2 failed checks, so about 60 seconds.
• In an RDS Multi-AZ DB instance deployment the one standby supports failover but does not serve reads. In a Multi-AZ DB cluster deployment two standbys can serve reads. Aurora Replicas serve reads and are the failover targets.
• Aurora recommends putting replicas in different Availability Zones from the writer.
• Limits come from AWS documentation (default quotas in us-east-1). Where AWS publishes no figure, such as how many requests a container or database handles, the lab states its assumption on the component.

What you'll build

1. A zone-aware stack for 4,000 requests a second
2. Capacity that survives losing a task
3. The arithmetic of losing a whole zone
4. A peak design with a cache
5. An empty cache at peak
6. A database that survives its writer failing
7. Failover that applications ride out

Steps

1. 1Serve 4,000 requests/s
2. 2Lose a task
3. 3Losing a whole zone
4. 4Handle a 12,000 requests/s peak
5. 5Survive an empty cache at peak
6. 6Lose the writer
7. 7Is the standby a reader?
8. 8Riding out a failover