Capacity Headroom
The deliberate gap between current load and maximum capacity, sized to absorb growth, spikes and the loss of a failure domain.
Headroom is frequently treated as waste by anyone reading a utilisation chart, and it is the purchase of three specific properties.
Failure absorption: with three availability zones, losing one shifts its load onto the remaining two, so running above roughly 66% utilisation means a zone failure causes an overload rather than a degradation. This is the calculation most often missed in multi-zone designs, which are declared resilient while running at 85%.
Latency: queueing delay rises hyperbolically near capacity, so headroom is not idle capacity, it is response time. A system at 90% utilisation has poor and unstable latency even though it is technically serving everything.
Spike absorption: real traffic is not smooth, and the time to detect and act on a spike — including autoscaling reaction time, which is minutes not seconds — must be covered by existing capacity.
The sizing conversation should therefore be explicit rather than defaulted: what failure must be survived, what latency is required, and how fast can capacity be added. Those three answers give a number, and the number is defensible in a cost review in a way that "we run at 60%" is not.
The related trap: autoscaling is often assumed to remove the need for headroom, and it does not. Scaling depends on a control plane that may be unavailable during the event, takes time to react, and can be constrained by account quotas that nobody has checked.