Picture an application running in two availability zones. One zone loses power. The load balancer sends requests to the surviving application instances, but those instances still use a database in the failed zone. The infrastructure has redundant compute; the application does not have a complete recovery path.

What a zone actually separates

AWS defines availability zones as distinct data-center groupings with redundant infrastructure and links to other zones in the region. A region contains one or more zones and is designed to be isolated from other regions. Individual services and resources have their own regional or zonal scope.

Two instances in one zone can protect against an individual machine failure. Placing one in another zone changes the exposure to a site-level problem, but only if traffic and required state can reach the second instance. A second database replica, for example, needs an appropriate promotion and routing mechanism.

Azure's availability-zone documentation distinguishes zonal resources from services that provide zone redundancy. A service marked regional does not necessarily distribute every resource across all the zones. Check the specific service, tier and configuration rather than counting zone names in the console.

Software can fail across physical boundaries

A separate power feed protects against certain electrical faults. It does not protect against a configuration mistake deployed simultaneously to every zone. A broken application release, invalid credential or faulty control-plane policy can travel further than a facility failure.

Google's 12 June 2025 incident report describes widespread API errors following a Service Control policy change. The affected services were geographically distributed. The common software dependency mattered more than the physical separation of their machines.

Distinguish the data plane, which serves customer work, from the control plane, which manages configuration and resources. Some data-plane operations can continue without a healthy control plane. Others depend on live authorization or policy checks. An existing application may remain functional while provisioning a replacement instance fails.

That matters during recovery. If changing DNS, creating a replica or retrieving a secret requires the affected management service, the standby location may be healthy but unusable. AWS's multi-region dependency guidance discusses planning around such dependencies.

Can the surviving location handle the load?

Suppose two zones each normally serve 600 requests per second and each has been tested to handle 800. Losing one sends 1,200 requests per second to a location rated for only 800 under the same response-time objective. The application may be running, yet customers still experience failures or long queues.

You can buy spare capacity, reserve room for scaling or deliberately offer a reduced service during an incident. Autoscaling is not a substitute for testing: the required capacity may not be available, or new instances may take too long to become ready. Model the load after failure rather than sizing only for ordinary operation.

The data layer creates a second limit. Asynchronous replication can leave the recovery region behind the primary. If the primary loses accepted writes, failover can restore the service without recovering those transactions. Synchronous replication has latency and availability trade-offs of its own. Google's disaster-recovery guidance describes these choices and the possibility of correlated multi-zone outages.

What to measure during a failover

A recovery-time objective (RTO) describes how quickly a service needs to recover. A recovery-point objective (RPO) describes how much recent data loss the business can tolerate. A deployment spanning zones or regions does not meet either objective simply because the replicas exist.

For an order-processing application, measure the time until customers can complete orders again and establish the latest durable transaction available at the recovery site. Include DNS or load-balancer convergence, dependency access, database promotion and the capacity available at the destination. Confirm that the old primary cannot continue accepting conflicting writes after promotion.

A meaningful resilience description might promise continuity for a single-zone failure and recovery within a stated time for a regional failure. Those are distinct goals. Cloud SLAs and service credits describe yet another boundary: the supplier's contractual commitment, which cannot establish whether your entire application survived.