A service runs across three availability zones at 70% CPU during peak. The team wants to survive losing one zone at peak with no user impact. Roughly what does that require, and what does the same arithmetic say about running across two zones?

The assumptions, stated

Load is spread evenly across zones, and a lost zone's traffic is redistributed to the survivors rather than dropped. Peak is the number that matters, because zones fail without consulting the calendar. Autoscaling exists but takes minutes to add capacity, and a zone is lost in seconds.

The arithmetic

With three zones, losing one leaves two to carry all the load, so each survivor takes 3/2 of its previous share: a 1.5x increase. At 70% CPU before the failure, that is 105% after. The service is saturated, and it saturates in seconds, long before any scaling can respond.

Working backwards: to stay at or below 80% after losing a zone, peak utilisation before the failure must be at most 80% divided by 1.5, which is about 53%. Round it to a planning rule: with three zones, run below 55% at peak.

For two zones the factor is 2.0, so the same 80% ceiling requires 40% before the failure - each zone running at 40% and the pair therefore effectively half idle. For four zones the factor is 4/3, so the ceiling is about 60%.

Every additional zone makes headroom cheaper, which is the quantitative argument for three zones over two and the reason two-zone designs are usually a false economy.

What the number rules in and out

Running three zones at 70% peak does not meet the stated goal and no amount of autoscaling configuration fixes it, because the mismatch is between a failure that takes seconds and a response that takes minutes. The options are: add capacity so peak sits near 53%, accept degradation during a zone loss and design what that degradation is, or spread wider so the redistribution factor falls.

What it costs

Roughly 30% more standing capacity than the 70% design, sitting idle for the years between zone failures. This is the static stability trade: you pay continuously for capacity that is doing nothing, and in exchange the failure needs no control-plane action to survive. AWS's own guidance on static stability makes the same argument - a system that must call an API to survive a failure has taken a dependency on that API at the worst moment.

The second-order effects people miss

• Connection and pool limits scale too. The surviving zone's databases now take 1.5x the connections, which is often the real ceiling rather than CPU.
• Cross-zone traffic costs rise as the topology becomes lopsided.
• The scaling event may be impossible. If the lost zone held a third of the region's instance capacity for that type, the surviving zones may not have room for it at that moment.
• Warm-up matters. Newly added instances with cold caches and unprimed connection pools serve at a lower rate for their first minutes.

When not to buy the headroom

For a workload that can degrade, this is expensive insurance against a rare event. A queue-backed batch pipeline can simply run behind for an hour, and paying 30% year-round to avoid that is poor value. The headroom argument holds for the interactive path with a latency commitment, and the honest design for most platforms is tiered: static stability for the checkout path, and graceful lateness for everything else.