Control planes fail differently from data planes

A cloud service has two halves. The data plane does the service's actual job: a running instance, reads and writes to a volume, Route 53 answering queries. The control plane is the set of APIs that create, describe, update and delete resources. AWS keeps them apart and finds control planes likelier to fail, having more moving parts.

A failover plan made of control plane calls, launching capacity or editing a record, leans on the more fragile half at the worst moment. AWS's answer is static stability: resources already provisioned keep working through the impairment, and recovery needs no changes. A running EC2 instance keeps sending the traffic it already could, even while new launches and rule changes stall.

So the failover is built beforehand, and on the day only data plane mechanisms act, such as health checks that stop routing to an unhealthy endpoint. That is why Capacity must already be there, since adding it is a control plane action, and why DNS failover should rest on health checks rather than record edits.

Some global services, IAM and Route 53 among them, run one control plane for every region, in us-east-1: an easy case of a dependency nobody listed.