Multi-AZ Deployment

A Multi-AZ deployment is a database high-availability configuration that maintains a synchronously replicated standby copy of a database in a separate availability zone from the primary, so that the database can automatically fail over to the standby with minimal data loss and downtime if the primary’s zone experiences an outage.

How It Differs from Read Replicas

Multi-AZ and read replicas are often confused but serve different purposes. Multi-AZ standby replicas use synchronous replication specifically for high availability — a write isn’t considered committed until it’s confirmed on both the primary and the standby, ensuring near-zero data loss on failover — and the standby isn’t normally used to serve read traffic at all; it exists purely as a failover target. Read replicas, by contrast, use asynchronous replication and are actively queried to offload read traffic, accepting some replication lag as the cost of that scalability benefit.

How Failover Works

If the primary instance becomes unavailable — due to an availability zone outage, hardware failure, or planned maintenance — the database service automatically promotes the synchronous standby to become the new primary and updates the database’s DNS endpoint to point to it, typically completing failover within one to two minutes without requiring any application-level changes, since the application continues connecting to the same endpoint throughout.

Where It’s Used

Multi-AZ is available as a managed feature in services like Amazon RDS, Cloud SQL, and Azure Database, and it’s considered a baseline best practice for any production database workload where an availability zone outage causing extended downtime or data loss would be unacceptable — the synchronous replication cost is a deliberate tradeoff in favor of durability and availability over the last increment of write latency.

Multi-AZ’s Cost and When It’s Worth It

Because Multi-AZ maintains a full synchronous standby copy of the database, it roughly doubles the compute cost of the database tier compared to a single-instance deployment — a cost that’s straightforward to justify for production workloads where downtime or data loss has real business consequences, but that teams sometimes skip for development, staging, or genuinely non-critical internal tools where the availability guarantee isn’t worth the added expense. This cost-versus-availability tradeoff is one of the more common, deliberate decisions teams make when right-sizing database infrastructure across different environments in their deployment pipeline.

Some managed database services also support Multi-AZ configurations with a readable standby, letting the synchronous replica serve read traffic during normal operation rather than sitting completely idle until a failover event, narrowing the gap between pure high-availability Multi-AZ and read-scaling replicas somewhat, though the underlying replication guarantees remain distinct.