Multi-AZ Deployments

An Availability Zone is one or more discrete data centers with redundant power, networking, and connectivity in an AWS Region.

Key Characteristics:

• Each Region has a minimum of 3 AZs (most have 3-6)
• AZs are connected with high-bandwidth, low-latency networking
• Physical separation provides fault isolation
• AZ names are mapped differently per account (us-east-1a in your account may be different physical location than in another account)
• AZ IDs (e.g., use1-az1) are consistent across accounts

Distance & Latency:

• AZs are physically separated by a meaningful distance (many kilometers)
• Connected via dedicated metro fiber providing single-digit millisecond latency
• Far enough apart to reduce correlated failure risk

When designing Multi-AZ architectures, follow these core principles:

1. Eliminate Single Points of Failure

• Deploy resources in at least 2 AZs (preferably 3)
• Use managed services with built-in Multi-AZ support
• Design for AZ independence (each AZ can operate standalone)

2. Plan for Capacity

• 2 AZ deployment: Provision 200% capacity (each AZ handles 100%)
• 3 AZ deployment: Provision 150% capacity (each AZ handles 50%)
• Account for failover traffic redistribution

3. Use Appropriate Replication

• Synchronous replication for zero data loss (higher latency)
• Asynchronous replication for better performance (potential data loss)

Aurora separates compute from storage, providing inherent Multi-AZ durability:

Storage Layer:

• Data automatically replicated 6 ways across 3 AZs
• Can lose 2 copies and still write
• Can lose 3 copies and still read
• Self-healing storage with continuous backup to S3

Compute Layer:

• Primary (writer) instance in one AZ
• Up to 15 Aurora Replicas across AZs
• Replicas can serve read traffic
• Failover to replica in under 30 seconds
• Failover priority tiers (0-15) control promotion order

With Cross-Zone Enabled:

• Each LB node distributes traffic across ALL targets in ALL AZs
• Even distribution regardless of target count per AZ
• Better utilization, but prevents Availability Zone Independence

With Cross-Zone Disabled:

• Each LB node only routes to targets in its own AZ
• Uneven distribution if targets are imbalanced
• Enables Availability Zone Independence (AZI)
• Required for zonal shift/evacuation strategies

NAT Gateways are AZ-scoped resources - each operates within a single AZ.

Best Practice Architecture:

• Deploy one NAT Gateway per AZ where you have private subnets
• Update route tables so each private subnet uses its local NAT Gateway
• Prevents cross-AZ traffic and avoids single point of failure

Why This Matters:

• If using a single NAT Gateway and its AZ fails, private resources in other AZs lose internet access
• Cross-AZ NAT traffic incurs data transfer charges
• AZ-local NAT Gateway provides fault isolation

ElastiCache for Redis supports Multi-AZ with automatic failover:

How It Works:

1. Primary node handles reads and writes
2. Read replicas in different AZs receive asynchronous updates
3. On primary failure, ElastiCache promotes replica with lowest replication lag
4. DNS update propagates (application reconnects automatically)
5. New replica created to maintain redundancy

Failover Triggers:

• Primary node failure
• Primary AZ network connectivity loss
• Primary AZ availability loss

Key Points:

• Memcached does NOT support Multi-AZ replication
• Redis cluster mode works with Multi-AZ
• Replicas should be in different AZs than primary