Multi-AZ Patterns for Stateful Services

Stateful services — databases, caches, file systems — are the hardest components to make highly available because they hold data that must survive failures. If a single-AZ database fails, your entire application loses its data store. AWS's answer is Multi-AZ deployments, where the service maintains a synchronous or near-synchronous replica in a second Availability Zone that can take over rapidly when the primary fails.

RDS Multi-AZ maintains a synchronous standby replica in a different AZ. Every write to the primary is synchronously replicated before acknowledging success — this means zero data loss (RPO=0) but a slight write latency increase. When the primary fails, RDS automatically updates the DNS endpoint to point to the standby in 60-120 seconds. Your application only needs to reconnect to the same endpoint — no code changes required.

Amazon Aurora takes Multi-AZ further with a shared distributed storage layer that automatically replicates data across three AZs in six copies. Aurora instances are stateless — they read and write to this shared storage. When the primary Aurora writer fails, a read replica in another AZ is promoted to writer in under 30 seconds. This is faster than RDS Multi-AZ failover and the data is always consistent across AZs without explicit standby replication.

ElastiCache for Redis supports Multi-AZ through replication groups. A primary node accepts writes and asynchronously replicates to read replicas in other AZs. When the primary fails, ElastiCache automatically promotes a replica to primary. For Redis cluster mode enabled, data is sharded across multiple node groups each with their own primary and replicas across AZs — this provides both HA and horizontal scaling.

Amazon Elastic File System (EFS) is inherently Multi-AZ — it is a regional service that stores data redundantly across multiple AZs within a region. You create mount targets in each AZ's subnet, and EC2 instances in any AZ can mount the file system through their local mount target. There is no manual Multi-AZ configuration required. EFS provides shared POSIX file storage that multiple instances across AZs access simultaneously.

Elastic Load Balancers are themselves Multi-AZ — ALB and NLB deploy load balancer nodes in each AZ you specify. With cross-zone load balancing enabled (the default for ALB), each load balancer node distributes traffic evenly across all registered targets in all AZs, not just its own AZ. This ensures that even if all instances in one AZ fail, the load balancer continues serving traffic through instances in the remaining AZs.

A common mistake is deploying a single NAT Gateway in one AZ while private subnets in other AZs route through it. If that AZ fails, all private instances lose internet access. The correct Multi-AZ pattern is to deploy one NAT Gateway per AZ and configure each AZ's private route table to route 0.0.0.0/0 through its own NAT Gateway. This eliminates the NAT Gateway as a cross-AZ SPOF and reduces cross-AZ data transfer costs.

DynamoDB is a fully managed service that automatically replicates data across three AZs within a region — you do not configure Multi-AZ manually. Every write is durably stored across all three AZs before success is returned. DynamoDB is effectively fault-tolerant at the AZ level out of the box. This is why DynamoDB is often the recommended database choice when the exam question emphasises high availability with minimal operational overhead.

During an RDS Multi-AZ failover, applications that maintain persistent database connections may experience failures as the endpoint changes. RDS Proxy sits between your application and RDS, maintaining a pool of connections to the database. During failover, RDS Proxy automatically reroutes to the new primary — reducing failover impact from 60-120 seconds to under 30 seconds for applications using the proxy endpoint. RDS Proxy also helps with Lambda functions that create many short-lived connections.

Understanding replication modes is critical for choosing Multi-AZ patterns. Synchronous replication (RDS Multi-AZ, EFS) ensures RPO=0 because every write is confirmed in both AZs before success. The trade-off is slightly higher write latency. Asynchronous replication (ElastiCache Redis replicas, RDS Read Replicas) offers lower write latency but accepts a small replication lag — meaning some data could be lost if the primary fails before replication completes.

You should regularly test Multi-AZ failover to validate your RTO assumptions. For RDS, you can trigger a failover using the console's Reboot with failover option or the CLI. Monitor CloudWatch for the FailedSQLServerAgentJobsCount metric and watch your application logs to verify it reconnects successfully. Document the actual failover duration — it may differ from AWS documentation depending on your instance class and workload.

Test your understanding of AWS Solutions Architect (SAA-C03) concepts from this lesson.

In this lesson you learned: RDS Multi-AZ uses synchronous replication with automatic DNS failover, Aurora uses a shared storage layer across three AZs for faster failover, and EFS and DynamoDB are inherently Multi-AZ without manual configuration. Deploy one NAT Gateway per AZ to avoid cross-AZ SPOFs. Next up we explore multi-region active-active and active-passive patterns.