RDS Multi-AZ: Synchronous Replication and Failover

Amazon RDS Multi-AZ is a high-availability feature that automatically creates and maintains a synchronous standby replica in a different Availability Zone (AZ) within the same AWS Region. Its primary purpose is to provide automatic failover in the event of an AZ outage, primary instance failure, or planned maintenance. It is NOT a read scaling solution—the standby is not accessible for reads or writes until it becomes the primary after a failover.

When Multi-AZ is enabled, RDS uses synchronous replication to the standby. This means that every transaction committed on the primary must also be written to the standby's storage before the commit is acknowledged to the client. The process:

This ensures zero data loss (RPO=0) during a failover, as long as the primary and standby remain in sync. The replication is synchronous at the storage layer—it is not logical replication (as in MySQL binlog or PostgreSQL WAL streaming to a read replica). RDS uses a proprietary block-level replication mechanism that mirrors the underlying EBS volumes. For Amazon Aurora, the replication is at the storage node level, but for RDS (MySQL, PostgreSQL, Oracle, SQL Server, MariaDB), it is a synchronous block-level mirror.

- Loss of network connectivity to the primary (e.g., AZ failure) - Primary DB instance failure (e.g., OS crash, hardware issue) - Storage failure on the primary - Manual failover (Reboot with failover) for testing - RDS maintenance events (e.g., patching, scaling) that require a reboot - Failover Time: Typically 60-120 seconds. During this time, the DNS record is updated, and the standby is promoted to primary. Existing connections are dropped and must reconnect. - No Application Changes Required: Because the endpoint remains the same, applications simply reconnect after failover.

You can enable Multi-AZ when creating a DB instance or modify an existing single-AZ instance to Multi-AZ. Modifying from single-AZ to Multi-AZ causes a brief outage (a few minutes) as a standby is created and replication is established.

To verify Multi-AZ status:

Example CLI command to create a Multi-AZ instance:

aws rds create-db-instance \
    --db-instance-identifier mymultiazdemo \
    --db-instance-class db.m5.large \
    --engine mysql \
    --master-username admin \
    --master-user-password mypassword \
    --allocated-storage 100 \
    --multi-az \
    --db-subnet-group-name mydbsubnetgroup

For MySQL and MariaDB, RDS uses a custom block-level replication driver that mirrors writes to the standby's EBS volume. It is not MySQL native replication (binlog). For Oracle, it uses Oracle Data Guard in SYNC mode. For SQL Server, it uses SQL Server Mirroring (with synchronous commit) or Always On Availability Groups. For PostgreSQL, it uses a custom synchronous replication mechanism that is not the built-in streaming replication.

Because replication is synchronous, write latency is inherently higher than single-AZ because the primary must wait for the standby's acknowledgment. The additional latency is roughly equal to the round-trip time (RTT) between AZs, typically 1-2 ms within the same region. This is acceptable for most OLTP workloads, but high-throughput write-heavy applications may see a performance impact.

When a failure is detected (e.g., health check failures, loss of heartbeat), RDS automatically initiates failover:

The entire process is automatic and typically completes within 1-2 minutes. Applications must be designed to retry connections with exponential backoff.

In production, I have deployed RDS Multi-AZ for a financial services application that required zero data loss and high availability. The database was a 2 TB MySQL instance handling credit card transactions. We enabled Multi-AZ from the start. During a real AZ outage in us-east-1 (the infamous 2017 S3 outage that also affected EC2), our RDS instance automatically failed over to the standby in us-east-1b. The failover took about 90 seconds. Our application had connection retry logic with a 5-second backoff, so after about 2 minutes, all connections were re-established. We lost zero transactions because of synchronous replication. The only impact was a brief write unavailability.

Another scenario: an e-commerce platform with a global customer base used Multi-AZ for its product catalog database. They also had read replicas in three other regions for read scaling. The Multi-AZ primary handled all writes, and the replicas served read traffic. During a planned maintenance (OS patching), RDS automatically failed over to the standby, which then became the new primary. The read replicas automatically re-pointed to the new primary. The entire maintenance window was transparent to the application except for a 1-minute write pause.

A common mistake I've seen: a startup enabled Multi-AZ but placed both instances in the same AZ by using a subnet group that only covered one AZ. The configuration succeeded, but when that AZ went down, both instances were lost. The fix is to ensure the DB subnet group includes subnets in at least two AZs. Also, some engineers assume they can use the standby for read offloading—they can't. They end up adding read replicas anyway, which increases costs. The lesson: Multi-AZ is for availability, not performance.

Performance considerations: For a write-heavy workload (e.g., 10,000 writes/second), the synchronous replication adds about 1-2 ms per write. This is acceptable for OLTP, but for batch inserts, you might see throughput drop. In one case, we had to move to Aurora for its better write performance with built-in replication. Also, storage type matters: Provisioned IOPS (io1/io2) is recommended to avoid replication lag spikes due to EBS burst balance depletion.