Availability Zone Independence
The property that a failure in one zone does not propagate to another, and the design work needed to actually benefit from it.
Zones are separate failure domains within a region — distinct power, cooling and networking, close enough for single-digit millisecond latency between them. That combination is unusually valuable: it allows synchronous replication with strong consistency and still survives a facility-level failure.
The mistake is assuming that deploying across zones delivers zone independence. It does not on its own. The system must also have capacity headroom to serve full load with a zone gone, which means running at most two-thirds utilisation across three zones; it must not have a singleton in one zone, such as a primary database with no automatic failover, a single message broker, or a scheduler; and it must not depend on cross-zone chatter so heavily that losing a zone causes a latency collapse.
The failure people plan for least is the partial zone impairment — the zone is not down, it is slow or intermittently unreachable, which is far more common than a clean loss and defeats health-check-based failover that expects a binary state.
The cost dimension that surprises teams: cross-zone data transfer is billed, and a chatty architecture spread across three zones can generate a substantial and entirely unnoticed network bill. Zone-aware routing that prefers local endpoints while retaining cross-zone failover is the usual resolution.