Cloud providers describe regions as collections of independent zones designed to fail separately. Large outages regularly affect more than one zone, and the reasons are consistent.
Zones are separate, control planes often are not
Availability zones have independent power, cooling and networking, so a physical failure in one should not reach another.
The systems that manage resources, such as those that start instances or update configuration, frequently operate at the region level rather than per zone.
When a control system fails, existing resources may keep running while nothing can be created, changed or replaced, which prevents exactly the recovery actions the design assumed.
Recovery attempts create their own load
During an incident, every affected customer attempts to move workloads to the surviving zones at the same moment.
That demand arrives as a simultaneous surge on capacity that was provisioned for normal conditions, and requests begin to fail for lack of resources.
The result is a secondary failure caused by the response rather than the original fault, which is why reserved capacity in a second zone behaves differently from an assumption of availability.
Shared dependencies concentrate risk
Many services within a region depend on a small number of foundational ones, particularly identity, storage and internal name resolution.
A fault in one of those propagates widely, because services that appear unrelated all authenticate through the same system or resolve addresses through the same infrastructure.
This is why outage reports so often trace a broad failure to a single underlying component that most customers had never considered a dependency.
Status pages depend on the same infrastructure
Reporting systems are frequently hosted within the environment they report on, so a severe outage can delay or prevent updates.
Automated status detection also relies on monitoring that may itself be affected, which is part of why acknowledgement often lags customer experience.
Providers increasingly host status reporting separately for this reason, though the manual verification step before publishing remains.
Multi-region is a design commitment
Running in more than one region protects against these failures but requires data replication, traffic routing and a tested procedure for switching.
The cost is continuous, since standby capacity must exist and be exercised, and untested failover reliably fails when first attempted under pressure.
Most organisations conclude that regional redundancy is warranted for a small set of critical functions rather than for everything they run.