16.7 Multi-AZ and read replicas
These two solve different problems. Mixing them up is the most common RDS interview mistake.
| Multi-AZ | Read replica | |
|---|---|---|
| Why | Survive a failure of the primary | Scale reads, or run a report away from the primary |
| Copy | Synchronous standby in another AZ | Asynchronous copy |
| Endpoint | Same endpoint. After failover, DNS moves to the new primary | Its own endpoint |
| Can the app read the standby? | No. The standby is for failover, not for queries | Yes. Send SELECT traffic to the replica endpoint |
| Failover | Automatic | You promote the replica. It becomes a standalone database |
| Where | Another AZ, same Region | Same Region, or another Region |
| This lab? | No. A standby is a second instance and is billed. Leave it off | No full lab. Know the button |
Console (names may vary). Multi-AZ: select the instance, Modify, then Availability, then create a standby, then continue. Apply immediately only if you accept a short failover window. Read replica: Actions, Create read replica. Wait until it is Available, and use the replica endpoint only for read-only queries. Promote is also under Actions, and it is one-way.
Aurora is a different design. Its replicas share storage with the writer, and failover is faster. Do not describe an Aurora replica as "just an RDS read replica".