Availability and read scaling are different decisions
RDS Multi-AZ
Choose for high availability and managed failover. A Multi-AZ DB instance standby is not a read-scaling target; Multi-AZ DB clusters use a different three-instance topology with readable standbys.
RDS read replica
Choose to offload read queries, reporting or read-heavy workloads. Replication is asynchronous, applications connect to replica endpoints, and lag can produce stale reads.
Amazon Aurora
Choose a MySQL- or PostgreSQL-compatible cluster architecture with distributed storage, writer and reader endpoints, Aurora Replicas, and managed replica promotion.
Current Multi-AZ terminology matters
A Multi-AZ DB instance deployment has one primary and one standby DB instance. The standby supports failover but does not serve read traffic. This remains the correct answer when a scenario emphasizes availability without changing the database engine or application read path.
A Multi-AZ DB cluster deployment has one writer and two standby DB instances across three Availability Zones. Those standbys can also serve read traffic. Do not apply the older “standby never serves reads” statement to every modern RDS Multi-AZ topology.
Exam-reading habit: identify whether the question explicitly says “Multi-AZ DB instance” or “Multi-AZ DB cluster.” The architecture and read behavior differ.
Scenario-based architecture choices
Payment database needs automatic same-Region failover
The workload is write-heavy and does not need extra read capacity. Choose an RDS Multi-AZ deployment appropriate to the engine and topology. The requirement is availability, not read scaling.
Analytics queries overload the transactional primary
Add read replicas and direct reporting queries to their endpoints. Monitor replica lag and do not send read-after-write operations to a replica when the application requires the newest committed data.
MySQL-compatible service needs multiple readers and fast managed failover
Evaluate Aurora with Aurora Replicas in different Availability Zones. The application writes through the cluster writer endpoint and sends read-only connections through the reader endpoint.
Writer endpoint → current writer instance
Reader endpoint → available Aurora Replicas
Cross-Region recovery requirement
A cross-Region RDS read replica can support disaster recovery and can be promoted, but this is not the same as same-Region automatic Multi-AZ failover. For Aurora, evaluate Aurora Global Database when the requirement specifically calls for cross-Region Aurora replication and recovery.
Real-world troubleshooting sequence
- Endpoint: confirm whether the application uses a writer, reader or individual replica endpoint.
- Replication: inspect replica lag before treating a stale result as missing data.
- Connection pools: ensure applications refresh DNS and connections after failover rather than pinning an old IP.
- Health and events: review RDS events, instance health, failover state and database logs.
- Workload split: confirm only read-safe queries use replicas and all writes use the writer.
- Capacity: separate CPU, memory, connections, storage I/O and query-efficiency problems before adding replicas.
Fast SAA-C03 decision rule
Availability: Multi-AZ. Read-heavy scaling: read replicas. MySQL/PostgreSQL-compatible cluster with shared storage, reader endpoint and managed replica promotion: Aurora. A design can combine availability and read-scaling features when both requirements exist.
Official AWS references
Frequently asked questions
Does an RDS Multi-AZ standby serve read traffic?
A traditional Multi-AZ DB instance standby provides failover support and does not serve read traffic. A newer Multi-AZ DB cluster has two standby instances that can serve read traffic.
What is the main purpose of an RDS read replica?
A read replica offloads read-heavy queries from the primary. Standard RDS read replicas use asynchronous engine replication, so applications must account for replica lag and use the replica endpoint explicitly.
Can an RDS read replica be used for disaster recovery?
A replica can be promoted to a standalone instance, including in some cross-Region recovery designs, but promotion and application endpoint changes are different from automatic Multi-AZ failover.
How do Aurora Replicas help both scaling and availability?
Aurora Replicas serve reads through the reader endpoint and can be promoted automatically if the writer becomes unavailable. Aurora cluster instances share the cluster volume rather than each maintaining a separate full storage copy.