Visual overview
RDS provides separate topologies for a resilient writer and for distributing read traffic.
Technical reference
High-availability and read-scaling questions become straightforward once replication direction, synchrony, endpoint behavior, and promotion are separated.
The standby is maintained in another AZ for availability and does not serve normal read traffic.
For supported MySQL/PostgreSQL deployments, this topology supplies HA and readable capacity across three AZs.
Read replicas can offload queries but may return stale data when replication lag exists.
Multi-AZ is designed for managed failover; the application normally continues using the database endpoint rather than manually selecting a standby.
Promoting an RDS read replica breaks its replica role and creates an independently writable database instance.
Multi-AZ starts with availability, not read scaling
A traditional RDS Multi-AZ DB instance deployment maintains a synchronous standby in a different Availability Zone. The standby exists to support availability and managed failover; it does not serve application read traffic. If the primary can no longer serve the database for a supported failure or maintenance event, RDS can fail over to the standby while keeping the database endpoint abstraction for the application.
RDS also offers Multi-AZ DB cluster deployments for supported engines. This architecture has a writer and two readable DB instances across three Availability Zones and uses a different replication model from the single-standby Multi-AZ DB instance deployment. It can therefore combine high availability with additional read capacity. When an exam or design document says 'Multi-AZ,' determine which deployment form it means before inferring whether standbys are readable.
Read replicas create a separate readable copy
An RDS DB instance read replica is a read-only copy created from a source instance using the database engine's replication technology. Updates flow asynchronously from the source, so a replica can lag behind the primary. Applications can direct reporting, search, or other read-heavy work to replicas and reduce read pressure on the source. Because the replica has its own endpoint, the application must deliberately send appropriate read traffic there.
A read replica can also be promoted to an independent DB instance when a scenario requires it. Promotion is not the same experience as Multi-AZ automatic failover: the replica is a distinct resource and asynchronous replication means the recovery and data-freshness implications are different. Cross-Region read replicas can support geographic read or disaster-recovery patterns for supported engines, but they add distance, replication, and cost considerations.
Choose by failure objective and traffic shape
If the requirement is to keep a relational database highly available through an Availability Zone or primary-instance interruption, use the appropriate Multi-AZ architecture rather than adding a read replica and calling it HA. If the problem is a read-heavy primary, use a readable replica mechanism. Some architectures intentionally use both: Multi-AZ for availability of the writer and read replicas for read scale or disaster recovery.
Monitor replication lag wherever asynchronous reads influence correctness. A dashboard or recommendation engine may tolerate slightly stale results while a read-after-write transaction path may not. The correct architecture therefore follows both recovery objectives and consistency requirements, not just aggregate query volume.
- Traditional Multi-AZ DB instance: synchronous standby, automatic managed failover, no read traffic from the standby.
- Multi-AZ DB cluster: writer plus readable instances across Availability Zones for supported engines.
- DB instance read replica: asynchronous readable copy with a separate endpoint and possible replication lag.
- A read replica can be promoted, but promotion is not equivalent to a synchronous Multi-AZ failover path.
Key takeaways
- 01
Traditional RDS Multi-AZ DB instance deployments target high availability; their standby is not a read-scaling replica.
- 02
RDS Multi-AZ DB clusters have a distinct architecture with readable instances for supported engines.
- 03
DB instance read replicas use asynchronous engine replication and can lag behind their source.
- 04
Use read replicas to offload reads and Multi-AZ to meet the appropriate availability requirement; the mechanisms can coexist.
- 05
Replica promotion and managed Multi-AZ failover have different recovery semantics.
Official AWS sources
Use these primary AWS resources for the source material behind this article and for deeper reference.