Large cloud outages rarely begin with hardware failing. They usually begin with a control system behaving unexpectedly, and the effects spread through dependencies that were not visible beforehand.
Control planes and data planes fail differently
The data plane is what serves running workloads. The control plane is what creates, modifies and schedules them, and the two are built to different reliability standards for good reason.
A control plane failure often leaves existing systems running while preventing any change. Instances keep serving traffic, but nothing new can be launched and nothing broken can be replaced.
This is why an outage can look mild at first and worsen over hours, as normal failures accumulate with no ability to remediate them.
Shared dependencies concentrate risk
Almost every service depends on a small number of foundational ones: identity, storage, networking and a metadata service that other components query constantly.
When one of those degrades, services that appear unrelated fail together, because they all authenticate or resolve names through the same path. The blast radius follows dependency structure rather than product boundaries.
Status pages often lag here, since the reporting tooling itself may depend on the affected component. Customers frequently know before the dashboard does.
Retries make the recovery harder
When a service becomes slow, clients retry, which multiplies load on a system that is already struggling. This turns a partial degradation into a full one.
Recovery then has to contend with an enormous backlog of queued work arriving at once, which can knock the service down again immediately after it comes back.
Operators therefore restore capacity gradually and shed load deliberately, which is why full recovery takes far longer than the original failure did.
Multi-region designs are harder than they read
Running in a second region only helps if the failover path is exercised regularly, and if the data in the second region is current enough to be useful.
Synchronous replication keeps data identical but couples the regions, so a problem in one can slow the other. Asynchronous replication avoids that but accepts some loss on failover.
The dependency you forgot is the one that binds
Failover plans commonly assume the ability to change configuration, scale capacity or issue credentials during the incident, all of which are control plane operations.
If those operations run through the failing region, the plan cannot be executed at the moment it is needed. Working out that dependency in advance is the substance of resilience planning.
The useful test is not whether a second region exists but whether the system can be moved to it without touching the region that has failed.