Map AWS dependencies to the fault boundary they actually use

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.

Source fact:

The 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.

An 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.

Boundary

AWS 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.

Applicability questions

• What customer transaction or essential function is the resilience claim intended to preserve?
• For each hop, which Region, Availability Zone, endpoint, control plane, data plane, and external provider is used?
• Where are state, keys, DNS, identity, observability, deployment artifacts, and operator access located?
• Is failover preprovisioned with tested capacity, or does it depend on creating resources during the incident?
• What consistency and recovery-point tradeoffs are accepted for replicated data?

DSE recommendation:

Draw 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.

Define 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.

Verification and evidence

Keep 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.

Official references

• AWS Fault Isolation Boundaries whitepaper