Multi-AZ vs read replicas: practical tips and trade-offs

Multi-AZ vs read replicas: practical tips and trade-offs

When you're running databases in production, you'll quickly face a decision that shapes your entire architecture: do you need Multi-AZ for availability, read replicas for scale, or both? We've seen teams spend weeks debugging replication lag and failover issues because they picked the wrong tool. Let's walk through how these features work, when to use each, and the real trade-offs you'll encounter in the field.

Understanding Multi-AZ: automatic failover, standby not readable

Multi-AZ (Multi-Availability Zone) deployment creates a synchronous replica of your database in a different availability zone. The primary database and its standby remain in constant sync through synchronous replication, meaning writes don't return success until both nodes acknowledge the write.

Here's the critical point: the standby is not readable by default. It sits idle, ready to take over if the primary fails. When a failure occurs—whether hardware failure, network partition, or AWS maintenance—RDS performs automatic failover in typically 60–120 seconds, promoting the standby to primary.

We deployed a payment processing service with a PostgreSQL database in a single AZ. After a routine AWS maintenance event knocked it offline for 45 minutes, management asked why we weren't using Multi-AZ. We switched to Multi-AZ and immediately felt the cost increase, but the failover test three months later restored the database in 90 seconds with zero data loss. That's what Multi-AZ buys you: automatic recovery from infrastructure failure without manual intervention.

The trade-off is straightforward: you're paying roughly 2x the storage cost and accepting 10–20ms latency overhead on writes (because of the synchronous commit). But you get a contractual guarantee via RDS SLAs: 99.95% uptime for Multi-AZ deployments versus 99.5% for single-AZ.

Multi-AZ failover is transparent to your application if you're using connection pooling correctly. The DNS endpoint stays the same; RDS handles the promotion automatically. However, in-flight transactions will fail, so your connection pool must retry.

Read replicas: scale reads, asynchronous

Read replicas are completely different beasts. They're full, standalone database instances that replicate data asynchronously from the primary. You can have up to 15 read replicas per primary database, and they're readable from day one.

The main use case: your application can't handle all read traffic on a single instance. You're hitting CPU or IOPS limits on the primary, and scaling vertically isn't an option or is too expensive. You create replicas and send read-only queries there, keeping writes on the primary.

Here's a concrete example. We had a reporting dashboard running complex aggregations against a PostgreSQL database. During business hours, these queries were blocking transactional writes. We created two read replicas, redirected the reporting queries there, and freed up the primary for OLTP traffic. Cost went up, but latency on transactional queries dropped from 800ms to 150ms.

The asynchronous nature of read replicas means they lag behind the primary. On a healthy network with low write volume, lag is milliseconds. Under high write load, lag can stretch to seconds or even minutes. Your application must handle stale reads gracefully. If a customer just placed an order and immediately tries to view it on the dashboard replica, there's a window where it won't exist yet.

Read replicas also live independently from the primary. If the primary fails, replicas keep running but won't automatically promote. You need manual intervention or a failover script. They're not a replacement for Multi-AZ when uptime is critical.

One underrated benefit: read replicas can live in different regions. A read replica in eu-west-1 can serve European traffic with lower latency while the primary sits in us-east-1. This is how global SaaS platforms keep latency reasonable for international users.

Multi-AZ clusters: readable standbys change the game

AWS introduced Multi-AZ clusters for RDS a few years ago, and it's worth understanding how they differ from classic Multi-AZ. With Multi-AZ clusters, you get one primary and two readable replicas spread across three availability zones. All three are in sync. You can send read traffic to the replicas, and if the primary fails, promotion is automatic.

This is a middle ground that many teams should consider more seriously. You get automatic failover and read scaling. The cost is higher than single-AZ with replicas (you're running three instances), but you eliminate the operational burden of managing failover scripts and detecting primary failures.

We migrated a customer-facing SaaS application to Multi-AZ clusters last year. The readable replicas handled all reporting queries, the primary took writes, and when we tested failover, the cluster promoted a replica and recovered in 30 seconds. Operations never woke up. For critical workloads, this architecture has become our default.

One caveat: Multi-AZ clusters aren't available for all engine versions or instance types. Always check the AWS documentation for your specific database engine before planning around this feature.

Common mistakes

Mistake 1: Using read replicas instead of Multi-AZ for availability. A replica won't promote automatically, and replication can break if your application writes to a replica by accident. If your database going down for an hour is a problem, you need Multi-AZ, not replicas.

Mistake 2: Not accounting for replication lag in your application logic. We've seen teams create read replicas for scale, then get confused when freshly written data doesn't appear immediately. Write your application assuming replicas are always behind. Use the primary for reads that must be current.

Mistake 3: Over-provisioning read replicas without understanding query patterns first. Four read replicas won't help if your bottleneck is query execution time, not connection count. Profile your workload. Use CloudWatch and query logs to see where time is actually spent.

Mistake 4: Creating read replicas across regions without understanding data transfer costs. Cross-region replication incurs data transfer charges—typically $0.02 per GB. If you're replicating 100 GB/day, that's $2/day or $60/month just for replication. Still often worth it for latency, but don't be surprised by the bill.

Mistake 5: Setting up failover automation without testing it. We've seen teams configure read replica promotion scripts that break during actual failures because the script never ran in a real scenario. Always test failover in staging first, even if it's painful.

Key takeaways

• Multi-AZ provides automatic failover with zero data loss for infrastructure failures; the standby is not readable and acts as a hot standby only.
• Read replicas scale read traffic and can be in different regions, but they're asynchronous and won't promote automatically; they introduce replication lag.
• Multi-AZ clusters offer readable standbys with automatic failover, combining benefits of both approaches at higher cost.
• Most production databases need Multi-AZ as a minimum for uptime guarantees; add read replicas only after you've identified specific read bottlenecks.
• Replication lag is real and your application must handle stale reads on replicas; always test failover scenarios before they happen in production.
• Cross-region replicas solve latency but add data transfer costs; measure query patterns and region-specific latency before deploying.
• Connection pooling, retry logic, and DNS handling matter more than the replication architecture itself; get the fundamentals right first.