c2.23 Design for Multi-AZ redundancy
Deploy across multiple Availability Zones to improve fault tolerance and resilience. AZs are physically separated yet close enough to avoid meaningful latency, so a failure in one is unlikely to affect the others.
Implementation guidance
Spread workloads across Availability Zones
Run redundant capacity in multiple Availability Zones so the failure of a single AZ does not take your workload down. AZs are physically separated (typically tens of kilometers apart) to keep a localized failure or disaster from spreading, yet close enough that inter-AZ latency stays low.
Build it into the architecture
- Place subnets in at least two (ideally three) AZs and let load balancers and Auto Scaling distribute across them.
- Use Multi-AZ deployments for managed data stores (for example Amazon RDS Multi-AZ, Amazon Aurora) so a standby is ready in another AZ.
- Availability is a security property too: a resilient design resists denial-of-service and reduces the impact of an incident isolated to one AZ.
Related
For a broader failure domain, combine Multi-AZ with a multi-account structure and, where required, multi-Region design in later phases.
How to validate
- Are your critical workloads deployed across multiple Availability Zones?
- Do your managed data stores use Multi-AZ deployments with a standby?
- Do load balancing and autoscaling distribute capacity across AZs?
Threats addressed
- A workload confined to a single Availability Zone loses availability if that AZ suffers a failure or disaster, turning a localized event into an outage.
AWS services
Amazon RDS 
Amazon EC2