Placing compute instances in two Availability Zones does not make a workload multi-AZ if identity, data, networking, deployment, or operations still depend on one boundary. Resilience claims should follow the full request and recovery path.
\nThe AWS Fault Isolation Boundaries whitepaper describes AWS isolation constructs that customers can use when designing resilient workloads. It discusses Availability Zones and Regions as important geographic and infrastructure boundaries, and it distinguishes service control planes from data planes. The whitepaper’s prescriptive guidance encourages builders to understand service dependencies and choose boundaries that align with workload resilience needs.
\nAn Availability Zone is intended as an isolated location within a Region, while a Region provides a wider boundary. Control-plane operations used to create or change resources can have different availability characteristics from the data-plane operations that handle established workload traffic. These concepts inform architecture; they do not certify a customer workload as fault tolerant or establish that every AWS service behaves identically.
\nAWS service architecture, regional availability, quotas, replication modes, endpoints, and recovery features differ and evolve. A diagram showing multiple zones does not prove independent capacity, routing, data, secrets, or deployment. Multi-Region design adds consistency, failover, cost, security, and operational complexity and is not automatically required. Customer software and third-party services can introduce shared failures outside AWS boundaries.
\nDraw a dependency graph from user entry through DNS, network, compute, messaging, storage, database, secrets, identity, telemetry, and operational tooling. Annotate each component with its actual isolation boundary and the API operations needed for recovery. Identify supposedly redundant components that share an Availability Zone, Region, account dependency, quota, artifact store, or external service.
\nDefine the smallest credible failure for each required recovery objective and test it using supported fault-injection or controlled isolation methods. Verify traffic shifts, data behavior, capacity, operator access, monitoring, and return to normal. Prefer recovery actions that use already provisioned data-plane capability when a control-plane impairment is in scope. Document architectural gaps and narrow service claims until remediation is tested.
\nKeep the dated dependency graph, AWS service and Region matrix, configuration evidence, quotas and capacity assumptions, data-replication settings, fault scenario, synchronized telemetry, user-transaction results, and recovery timestamps. Evidence should show the component that failed, the boundary contained or propagated the failure, and the exact dependency used during recovery. Revisit the map after new services, regions, accounts, or deployment pipelines are introduced.
\n