RDS Multi-AZ vs Read Replicas vs Aurora Global Database: RPO & RTO compared
AWS now ships four different ways to put a standby or a copy next to an RDS or Aurora database, and most write-ups blur them into two: "Multi-AZ" and "read replicas." That was accurate a few years ago. It isn't anymore — RDS has had a second, readable-standby Multi-AZ option since 2022, and most comparisons online still don't mention it, or quietly conflate it with a plain read replica because both happen to accept read traffic. Below are all four options lined up against AWS's own published failover-time and replication-lag figures, not third-party estimates that disagree with each other.
The four options at a glance
| Option | Replication | Standby serves reads? | Failover | Scope |
|---|---|---|---|---|
| Multi-AZ DB instance (1 standby) | Synchronous | No | Automatic, typically 1–2 minutes | Same Region, cross-AZ |
| Multi-AZ DB cluster (2 standbys) | Semisynchronous | Yes | Automatic, typically under 35 seconds | Same Region, cross-AZ |
| Read replica | Asynchronous | Yes (read-only) | Manual promotion | Same Region or cross-Region |
| Aurora Global Database | Storage-based, asynchronous | Yes (read-only) | Switchover (planned) or failover (unplanned) | Cross-Region: 1 primary + up to 10 secondaries |
Multi-AZ DB instance: the original one-standby design
This is what most people mean when they say "RDS Multi-AZ" without qualification. RDS provisions a single standby DB instance in a different Availability Zone and replicates to it synchronously. The AWS documentation is blunt about its one limitation: "the high availability option isn't a scaling solution for read-only scenarios. You can't use a standby replica to serve read traffic." The standby exists purely as a failover target.
When the primary fails, RDS detects it and automatically promotes the standby, updating the DB instance's DNS record to point at it — no application reconfiguration needed, just a reconnect. AWS's own Multi-AZ FAQ states failovers "typically complete within one to two minutes," with a best case of "as quickly as 60 seconds." Because replication is synchronous, there's effectively no data loss on a clean failover: the standby already has every committed transaction.
Multi-AZ DB cluster: the newer, readable-standby design
Launched in 2022 and still the option most comparison articles skip, a Multi-AZ DB cluster replaces the single non-readable standby with two readable standby DB instances, one writer and two readers spread across three Availability Zones. AWS's documentation calls this "a semisynchronous, high availability deployment mode," meaning a write only needs acknowledgment from at least one reader to commit — not both, and not full execution confirmation. That relaxation is what buys "lower write latency when compared to Multi-AZ DB instance deployments," per AWS's own description, while still being able to serve read traffic from the two standbys, something the single-standby option can never do.
Failover is automatic here too, and faster: AWS's documentation states plainly, "failover times are typically under 35 seconds," whether the trigger is an actual outage or a manual failover request. Failover only completes once both readers have applied the failed writer's outstanding transactions, which is why heavy write load with growing replica lag can push the real number higher than the "typical" figure.
The distinction that trips people up: a Multi-AZ DB cluster's readers look like read replicas because you can query them, but they behave like a Multi-AZ standby because failover to them is automatic. A plain read replica is neither.
Read replicas: scaling and DR, not automatic HA
A read replica is an asynchronous, read-only copy built with the database engine's own native replication. AWS lists its actual use cases directly: scaling beyond one instance's read capacity, serving reads "while the source DB instance is unavailable" (with the caveat that the data served then may be stale), business reporting against a copy instead of production, and "implementing disaster recovery" by promoting a replica to standalone if the primary fails.
Two things separate a read replica from either Multi-AZ option. First, promotion is always manual — AWS states plainly, "you must manually create read replicas," and the same is true of promoting one to a standalone writer; there's no automatic failover path here at all. Second, because replication is asynchronous, a read replica's RPO isn't a fixed number the way a Multi-AZ deployment's is — it's whatever the replication lag happens to be at the moment you need it, which is also why AWS explicitly warns that the data on a replica serving reads during a primary outage "might be stale." A read replica can be configured in the same Region or cross-Region, which is the one dimension plain Multi-AZ can never offer: cross-Region reach for an RDS (non-Aurora) engine.
Aurora Global Database: cross-Region, at the storage layer
Aurora Global Database solves a different problem: surviving the loss of an entire AWS Region for an Aurora cluster. One primary cluster writes in its home Region; up to 10 secondary Regions each hold a read-only copy. Replication happens "using dedicated infrastructure, with latency typically under a second," because Aurora replicates at the storage layer rather than shipping engine transaction logs the way a read replica does.
AWS deliberately splits moving the primary into two distinct operations with different guarantees:
- Switchover — for planned, healthy-cluster scenarios like scheduled Regional rotation drills. Aurora waits for the target secondary to fully synchronize before promoting it, so "the new primary continues operations for the Aurora global database without losing any data": RPO is zero by design. On qualifying engine versions (Aurora MySQL 3.09+/8.0.40+, or recent Aurora PostgreSQL releases), AWS states "switchover recovery time for read/write operations is typically under 30 seconds."
- Failover — for an actual, unplanned Regional outage. Because it "doesn't wait for data to synchronize" first, AWS is explicit that "the RPO for this approach is typically a non-zero value measured in seconds," governed by however far behind the chosen secondary's replication lag was at the moment of failure. For recovery time, AWS's business-continuity guidance states "RTO can be in the order of minutes," and the failover procedure itself notes the chosen secondary "typically assumes the primary role within a few minutes."
Worked example 1: same-Region, RDS for PostgreSQL
A team runs RDS for PostgreSQL and needs automatic failover inside one Region in well under a minute, and wants to offload nightly BI reporting queries so they stop competing with production traffic on the primary. Running through the same-Region options:
- A Multi-AZ DB instance gives automatic failover, but its standby can't serve the reporting queries at all — fails requirement two.
- A read replica can absolutely serve the reporting queries, but there's no automatic failover if the primary itself goes down — promotion is a manual step, so it fails requirement one.
- A Multi-AZ DB cluster does both: its two standbys are readable (send the reporting workload there) and failover to one of them is automatic, typically under 35 seconds.
Multi-AZ DB cluster is the only option that clears both bars at once — which is exactly the kind of two-requirement scenario the exam uses to separate it from a plain read replica.
Worked example 2: cross-Region, Aurora
A compliance team using Aurora MySQL needs two unrelated things: a scheduled quarterly drill that rotates the primary to a different Region with zero tolerated data loss, and a disaster-recovery runbook for a genuine Regional outage that accepts an RTO of a few minutes and up to a few seconds of lost writes. These map directly onto Aurora's own split: the quarterly drill, a planned rotation of a healthy cluster, is a switchover (RPO zero by design, recovery typically under 30 seconds on current engines). The outage runbook, which can't wait for synchronization first, is a failover (RPO measured in seconds of lag, RTO in the order of minutes). Using failover for the planned drill would work but needlessly risk data loss that switchover is built to avoid entirely.
Cheat sheet
| What you need | Pick |
|---|---|
| Automatic same-Region failover; standby doesn't need to serve reads | Multi-AZ DB instance |
| Automatic same-Region failover and readable standbys / lower write latency | Multi-AZ DB cluster |
| Read scaling, reporting offload, or a manually-promoted DR target | Read replica |
| Planned cross-Region rotation of an Aurora cluster, zero data loss | Aurora Global Database switchover |
| Recovering an Aurora cluster from a real Regional outage | Aurora Global Database failover |
The pattern across all four: a synchronous or semisynchronous design (the two Multi-AZ options) gets you a fixed, near-zero RPO and automatic failover, in exchange for staying inside one Region. An asynchronous design (read replicas, Aurora Global Database) can reach across Regions, but its RPO becomes a function of replication lag rather than a guarantee, and someone — you, or a switchover/failover operation — has to initiate the promotion. To practice telling these apart under exam-style scenarios, try PassDrill's AWS SAA RDS, DynamoDB & databases practice questions.
Source: AWS Amazon RDS User Guide, "Configuring and managing a Multi-AZ deployment," "Multi-AZ DB instance deployments," "Multi-AZ DB cluster deployments," "Failing over a Multi-AZ DB cluster," and "Working with DB instance read replicas"; Amazon RDS Multi-AZ product page (failover-time FAQ); Amazon Aurora User Guide, "Using Amazon Aurora Global Database" and "Using switchover or failover in Amazon Aurora Global Database" (docs.aws.amazon.com), retrieved 2026-10-16.