RDS Multi-AZ vs read replicas: availability or read scaling?

Amazon RDS can keep extra copies of your database in two very different ways, and exam questions are built on mixing them up:

• Multi-AZ keeps a copy so the database survives a failure. It’s about availability.
• Read replicas keep copies so you can spread out read traffic. They’re about performance.

Both copy data to another instance, often in another Availability Zone. What differs is how they copy, whether you can read from the copy, and what happens when the primary fails.

Multi-AZ: a standby that takes over

With a Multi-AZ DB instance deployment, RDS keeps a standby in a different Availability Zone and copies every change to it synchronously: a write isn’t confirmed until the standby has it too.

• Failover is automatic. If the primary fails, its host or storage has a problem, its Availability Zone is disrupted or it’s being patched, RDS switches to the standby. Failover typically takes 60–120 seconds.
• The endpoint doesn’t change. RDS points the database’s DNS name at the standby, so your application reconnects to the same name. (Applications that cache DNS for a long time should keep their TTL to 60 seconds or less.)
• The standby serves no traffic. You can’t read from it. It exists only to take over.
• The cost: you pay for the standby, and synchronous copying can add a little write latency.

There’s also a newer Multi-AZ DB cluster deployment (for MySQL and PostgreSQL): one writer and two readable standbys in three Availability Zones. Those readers can serve reads, which makes it a middle ground, but on the exam “Multi-AZ” usually means the classic single standby.

Read replicas: copies you can query

A read replica is a read-only copy of the database that RDS updates asynchronously.

• They scale reads. Point reporting, analytics or read-heavy pages at replicas and the primary has more capacity for writes.
• They can lag. Because copying is asynchronous, a replica can be slightly behind. CloudWatch’s ReplicaLag metric shows by how much. Don’t send reads there that must see a write made a moment ago.
• Each has its own endpoint. Your application has to send reads to the replicas itself.
• They can be in another Region. A cross-Region replica puts data closer to distant users and gives you a copy for disaster recovery.
• No automatic failover. If the primary fails, nothing switches over on its own. You can promote a replica: RDS stops replication and reboots it as a standalone database you can write to. It’s a manual step, and it’s one-way.
• Automatic backups must be on for the source database before you can create one.

You can combine them: a Multi-AZ primary for availability, plus read replicas for reads. A replica can even be Multi-AZ itself.

Side by side

How Aurora does it

Amazon Aurora blurs the line, which is why exam answers often prefer it.

• Aurora’s storage keeps six copies of your data across three Availability Zones, whatever instances you run.
• A cluster has one writer instance and up to 15 Aurora Replicas. The replicas serve reads and are failover targets: if the writer fails, Aurora promotes a replica automatically.
• The cluster endpoint always points at the writer, even after a failover. The reader endpoint balances connections across the replicas, so your application doesn’t track them itself.

So in Aurora, the same replicas give you both availability and read scaling.

Where RDS Proxy fits

Applications that open many short-lived connections, Lambda functions especially, can exhaust a database’s connections. RDS Proxy sits in front of the database and pools and reuses connections. It also keeps application connections open during a failover and reconnects to the new primary, so failovers disrupt the application less. It works with Secrets Manager or IAM authentication, so credentials stay out of your code.

Exam traps

• “The database must survive an Availability Zone failure with automatic failover.” Multi-AZ.
• “Reporting queries are slowing down the production database.” A read replica for the reports.
• “Use the Multi-AZ standby for read traffic.” Not possible with a Multi-AZ DB instance: the standby doesn’t serve reads. Use read replicas (or a Multi-AZ DB cluster).
• “Recover in another Region if the primary Region fails.” A cross-Region read replica, promoted when needed (or Aurora Global Database).
• “Users sometimes don’t see data they just saved.” They’re reading from a replica that lags. Read your own writes from the primary.
• “Thousands of Lambda invocations exhaust database connections.” RDS Proxy.
• “Highly available and read-scalable, with the least effort.” Aurora, with replicas behind the reader endpoint.

For the full details, see the Amazon RDS User Guide on Multi-AZ DB instance deployments, failing over a Multi-AZ DB instance, Multi-AZ DB clusters, read replicas, promoting a read replica and RDS Proxy, and the Aurora User Guide on endpoints.