You run in three availability zones and must survive losing one. What is your maximum normal utilisation and why?

What is being tested

Whether you can compute headroom for failure-domain loss, which is the most commonly missed term in capacity planning.

The arithmetic

Three zones, equal capacity. Lose one and two remain, carrying 100% of the traffic. Each surviving zone therefore serves 50% of total load. For that to be within capacity, each zone's normal load must be at most 50% of its own capacity... but there are only two of them sharing what three used to carry.

Put simply: total capacity is 3 units; after failure it is 2. Peak load must fit in 2, so peak load must be ≤ ⅔ of total capacity — about 66% utilisation at peak.

The generalisation: with N failure domains and a requirement to survive losing one, maximum utilisation is (N−1)/N. Three zones gives 66%; four gives 75%; two gives 50%.

This is why higher domain counts are cheaper per unit of redundancy — and why two zones is an expensive configuration.

The second reason 66% is a ceiling rather than a target

Queueing delay rises sharply as utilisation approaches saturation: roughly 4x the service time at 80% utilisation, 9x at 90%, 19x at 95%. So running at 90% "for efficiency" destroys latency and removes any ability to absorb a spike.

For latency-sensitive services, a peak target of 50–70% is typical — and that lands at or below the failure-domain ceiling anyway, which is a convenient coincidence rather than an accident.

Why "autoscaling will handle it" is wrong

Three reasons, all of which matter:

• Autoscaling takes minutes; a zone failure is instantaneous. The surviving zones must absorb the load now, from existing capacity.
• Capacity may not be available. During a zone event, everyone else is also scaling into the remaining zones. On-demand capacity is not guaranteed; reserved capacity is.
• Not everything scales. Database capacity, connection limits and stateful components do not autoscale on a useful timescale, so the constraint binds there regardless.

What else the model must include

• Peak, not average. Average load has never sized anything.
• Growth between planning cycles, plus forecast error.
• Lead times. Reserved capacity, quota increases and database scaling take weeks; only the elastic tier can be reacted to.
• The assumptions, written down — "40 queries per order, 12% monthly growth" — so that when reality surprises you, the model tells you which assumption broke.