AWS Solutions Architect Associate Training Course

If you learn one comparison in this module properly, make it this one. It appears in some form on nearly every SAA-C03 attempt, and the two options look similar enough that candidates who half-know them lose the question. They solve different problems, and a well-written scenario tells you which problem it has.

Multi-AZ: an availability feature

An RDS Multi-AZ deployment maintains a standby in a different Availability Zone in the same Region, kept in step by synchronous replication. Every committed write lands on both the primary and the standby before the write is acknowledged.

• The standby is not readable in the classic Multi-AZ instance deployment. You cannot point reporting traffic at it. This is the fact most often tested.
• Failover is automatic. RDS promotes the standby and updates the DNS record for the endpoint, so applications reconnect to the same hostname. Expect a brief interruption while connections are re-established, typically a small number of minutes or less; the exact figure varies, so treat it as "fast and automatic" rather than a fixed number.
• RTO is minutes, RPO is effectively zero, because replication is synchronous.
• It triggers on primary instance failure, AZ failure, storage failure, and also during patching and instance-type changes, which is why Multi-AZ is what makes maintenance non-disruptive.
• Backups and snapshots are taken from the standby, so they do not add I/O load to the primary.
• It is same-Region only. Multi-AZ protects against a zone failure, not a Region failure.

There is also a Multi-AZ DB cluster deployment for some engines, with two readable standbys across three AZs and faster failover. It blurs the classic distinction, so read the option text carefully: if it says Multi-AZ DB cluster, the standbys are readable; if it says Multi-AZ instance deployment or simply Multi-AZ, they are not.

Read replicas: a performance feature

A read replica is a separate database instance kept up to date by asynchronous replication from the source.

• It is readable, and it has its own endpoint. Applications must be written or configured to send read queries to it — RDS does not split traffic for you on the engines that use instance replicas.
• Replication lag exists. A read immediately after a write may return stale data, so a scenario requiring strong read-after-write consistency rules out a replica for that path.
• You can have several, and they can be in the same AZ, another AZ, or another Region. Cross-Region replicas are the building block for regional disaster recovery and for serving low-latency reads to distant users.
• A replica can be promoted to a standalone primary, manually. That promotion is what makes a cross-Region replica a disaster recovery option, with an RPO equal to the replication lag and an RTO equal to the time to promote and repoint the application.
• Replicas can have different instance sizes and, on some engines, their own indexes, which makes them useful for analytics that would otherwise disturb the production workload.

The distinctions in one table's worth of prose

Multi-AZ is synchronous, same Region, not readable, fails over automatically, and exists for availability. A read replica is asynchronous, optionally cross-Region, readable, promoted manually, and exists for read scaling — with cross-Region disaster recovery as a second use. They are not mutually exclusive: a production database commonly runs Multi-AZ for availability and several read replicas for load, and each replica can itself be Multi-AZ.

Matching the requirement

• "Reporting queries are slowing down the application" → read replica, with reports pointed at it.
• "The database must survive the loss of an Availability Zone with no data loss" → Multi-AZ.
• "Patching causes an outage window we cannot accept" → Multi-AZ, which patches the standby and fails over.
• "Users in another continent see slow reads" → cross-Region read replica.
• "We must recover in another Region if this one fails" → cross-Region read replica, promoted on failure; or Aurora Global Database for a faster RTO.
• "Improve write throughput" → neither. Replicas do not accept writes and the standby is not a write target. The answer is a larger instance, storage tuning, sharding, caching writes upstream, or a different database.

That last one deserves emphasis, because it is a favorite trap. Both mechanisms scale reads or protect availability. Neither scales writes. When a scenario describes write saturation, look for vertical scaling, Aurora, DynamoDB, or an architectural change such as buffering writes through a queue.

Supporting details worth carrying

Automated backups with point-in-time recovery are enabled per instance with a configurable retention period, and they are what let you rewind to any second within it. Manual snapshots persist until you delete them and can be copied to another Region or shared with another account, optionally encrypted with a key you control. RDS Proxy sits between the application and the database, pools connections, and shortens failover time by holding client connections open while the underlying endpoint moves — a good answer for serverless applications that open large numbers of short-lived connections. And the endpoint is the thing to reason about: applications should always connect to the RDS endpoint name, never a resolved address, because failover works by changing what that name resolves to.