Amazon RDS gives you two features that sound alike and are often confused: Multi-AZ deployments and read replicas. Both create extra copies of your database, but for different reasons. Multi-AZ is about surviving failure. Read replicas are about scaling reads. Many production databases use both.
Side by side
| Multi-AZ (instance) | Read replica | |
|---|---|---|
| Purpose | High availability, durability | Read scaling, reporting, cross-Region copies |
| Replication | Synchronous | Asynchronous |
| Can you read from the copy? | No, the standby is passive | Yes, it has its own endpoint |
| Failover | Automatic, DNS endpoint stays the same | Manual promotion to a standalone database |
| Location | Another AZ in the same Region | Same AZ, other AZ or another Region |
Multi-AZ instance deployments
With Multi-AZ, RDS keeps a standby in a different Availability Zone and copies every write to it synchronously before acknowledging the commit. You cannot connect to the standby; it waits.
When the primary fails (host failure, AZ problem, storage issue), or during certain maintenance, RDS fails over: it promotes the standby and points the same DNS endpoint at it. Applications reconnect to the same hostname. Failover usually completes in one to two minutes. During that window, connections drop, so your app needs retry logic and should not cache DNS forever.
Multi-AZ also makes maintenance gentler: patching happens on the standby first, then a failover, minimizing downtime. And backups are taken from the standby, avoiding I/O pauses on the primary.
Multi-AZ DB clusters
For MySQL and PostgreSQL, RDS also offers Multi-AZ DB clusters: one writer and two readable standbys in three AZs, using semi-synchronous replication. Failovers are typically faster than with the instance model, and the standbys serve reads through a reader endpoint. It sits between classic Multi-AZ and Aurora in features and cost.
Read replicas
A read replica receives changes from the primary asynchronously. It has its own endpoint, and your application sends read-only queries to it: product catalogs, dashboards, reports, search pages.
- Replication lag means a replica can be seconds (or more, under heavy write load) behind. Read-after-write flows ("show the order I just placed") should go to the primary.
- You can create several replicas per source; the limit depends on the engine.
- Cross-Region replicas bring data close to users in other Regions and act as a disaster-recovery copy.
- A replica can be promoted to a standalone database, breaking replication. That is a manual DR step, not automatic failover.
Read replicas do not help write throughput. If writes are the bottleneck, look at instance size, storage IOPS, query tuning, caching or sharding.
Which do you need?
- Production database, any size: Multi-AZ. The cost of a standby is far lower than the cost of an outage.
- Reads overwhelm the primary: add read replicas and route reads to them, or add a cache (ElastiCache) for hot data.
- Need a copy in another Region: cross-Region read replica (or Aurora Global Database).
- Dev and test: single-AZ is usually fine.
Where Aurora fits
Amazon Aurora separates compute from a shared, six-way replicated storage layer across three AZs. Aurora replicas read from the same storage, so lag is typically very low, and any replica can become the writer during failover, usually faster than classic RDS. You get a cluster writer endpoint, a reader endpoint that load-balances across replicas, and custom endpoints for specific groups of instances.
Failover and connections: avoid the storm
When a database fails over, every application instance reconnects at once. Without care, this connection storm overwhelms the new primary. Protect it with connection pooling, exponential backoff with jitter in retries, and RDS Proxy, which pools connections and holds them during failover. We dig into this in Aurora and RDS Failover Connection Storms.
Practice it
Start with the free Getting Started with AWS RDS (MySQL), then build Secure 3-Tier App with Multi-AZ RDS and run failover drills in Aurora Operations: Custom Endpoints, Failover Drills and Fast Clones. For recovery skills, try RDS Operations: Point-in-Time Restore.
FAQ
Does Multi-AZ improve performance?
Not for reads, since the standby is not readable (except in Multi-AZ DB clusters). Synchronous replication can add a little write latency.
Can a read replica be Multi-AZ?
Yes, for several engines you can enable Multi-AZ on a replica so it survives an AZ failure too.
Are backups the same as replicas?
No. Replicas copy mistakes immediately: a dropped table is dropped everywhere. Keep automated backups and snapshots for point-in-time recovery.