case-study

AWS: Static Stability Across Availability Zones

also called Static Stability

AWS designs services to keep working with the capacity they already have when a zone fails, rather than needing the control plane to provision replacements.

awsresiliencecontrol-planecapacity

The principle

AWS's Builders' Library describes static stability directly: a statically stable system continues operating correctly with the resources it already has when a dependency fails, rather than requiring an action to recover.

The specific application is availability zone failure. A naive design runs enough instances for normal load and, on losing a zone, calls the control plane to launch replacements. A statically stable design runs enough instances across all zones in advance that losing one leaves sufficient capacity — so the failure requires no provisioning at all.

Why the naive version fails

The control plane is the least reliable part. Control planes are more complex and lower-volume than data planes, and a large-scale event is exactly when they are most stressed — by your request and by everyone else's simultaneously.

Capacity may not be available. During a zone event, every customer requests the same instance types at once.

Provisioning takes time, and that time frequently exceeds the recovery objective it is supposed to serve.

So the design depends on the component most likely to be unavailable, at the moment it is most likely to be unavailable. This is why AWS separates its own data planes from control planes so carefully: running instances continue running even when the API to create new ones is degraded.

The cost

Running across three zones with enough headroom to lose one means operating at roughly two-thirds utilisation or below. That headroom is the purchase, and it is what a cost review will identify as waste unless the reasoning is written down.

The transferable lesson

Do not put a control plane in a recovery path. The same reasoning applies to disaster recovery plans that provision the secondary region at failover time, to autoscaling as a capacity plan, and to services that fetch configuration or secrets per request rather than caching them with a fallback.

The diagnostic question: if the provisioning API were unavailable right now, what would stop working? In most estates the honest answer is more than expected — and every item on that list is a hidden dependency of the data plane on the control plane.