Database reads are piling up, so you enable RDS Multi-AZ. Another instance exists, but SELECT latency does not improve. The likely issue is the role assigned to that second instance. In a single-standby Multi-AZ DB instance deployment, the standby prepares for failover; it does not take half of normal application reads.
Why does SELECT load stay on the primary?
This article discusses a Multi-AZ DB instance deployment with one standby. The primary handles reads and writes. A standby in another Availability Zone receives synchronized changes and is available for failover. Ordinary application SELECT requests do not go to it. AWS explicitly distinguishes this deployment type.
The diagram shows the single-standby DB instance deployment. The standby supports failover. Sending suitable SELECT requests to a separate Read Replica requires the application to choose its endpoint.
Imagine an order-list page whose 100 SELECT requests all reach the primary. Adding the standby does not redirect those 100 requests; the number is only an illustration, not a benchmark. Multi-AZ here addresses availability after a primary failure, not routine read distribution.
The deployment type matters. AWS also offers a Multi-AZ DB cluster deployment with two readable standby instances. The statement “the standby does not serve reads” applies to the single-standby DB instance deployment, not every product carrying the Multi-AZ name. Confirm the type in RDS before diagnosing traffic.
Does creating a Read Replica automatically distribute reads?
A Read Replica receives changes from its source and can handle read requests. Creating one does not automatically rewrite your application's connections. Route reads that can tolerate replica behavior to the replica endpoint; otherwise the primary still receives them.
| Order request | Endpoint | Intended role |
|---|---|---|
| Create or edit an order | Primary | Write the change |
| Read an order immediately after writing it | Primary | See the latest write |
| List or summarize orders when slight lag is acceptable | Read Replica | Offload eligible reads |
DB instance Read Replicas receive changes asynchronously. An immediate read from the replica may briefly show older data, so route read-after-write operations to the primary or design the interface to handle lag. AWS describes both replica connections and asynchronous replication.
Failover and read scaling solve different problems
The single standby is managed as an automatic failover target for the primary DB instance. A regular DB instance Read Replica is for read capacity; promoting it to an independent database is a separate operation and is not the same automatic failover path. After promotion, check the application's endpoint and the data point it sees.
The choices can be combined: a Multi-AZ DB instance can have a Read Replica. Evaluate cost, replication lag, and routing alongside availability.
What should you inspect in the current deployment?
- Deployment type: Is this a DB instance with one non-readable standby or a DB cluster with readable instances?
- Actual connections: Which endpoint receives list-page SELECTs? Avoid logging passwords or full connection strings while checking.
- Freshness requirements: Which reads must reflect a just-completed write, and which can tolerate lag?
- Observed behavior: Compare primary read load and replica lag before and after routing. If availability is the goal, inspect the failover path separately.
This is a request-routing example, not a claim that a live RDS failover or load test was performed.
Key takeaways
The standby in a single-standby Multi-AZ DB instance does not split normal SELECT traffic. It exists for failover. To offload reads, create a Read Replica and route appropriate requests to its endpoint, accounting for asynchronous lag. Check the deployment type and actual DB connections before expecting a performance change.
