RDS Multi-AZ vs Read Replicas

Concepts Covered

• RDS Multi-AZ DB instance deployments
• RDS Multi-AZ DB clusters
• Standby replicas
• Read replicas
• Synchronous replication
• Asynchronous replication
• Automatic failover
• Read scaling
• Cross-Region replicas
• Exam traps around database replicas

1. Plain-English Mental Model

RDS Multi-AZ and RDS read replicas both involve copies of database data, but they solve different problems.

Classic RDS Multi-AZ DB instance deployment is mainly for high availability. RDS maintains a standby in another Availability Zone. If the primary has a failure or maintenance event, RDS can fail over to the standby.

Read replicas are mainly for scaling read traffic. They are separate DB instances that can serve read-only queries. Applications send writes to the primary and eligible reads to replicas.

The short model is:

Multi-AZ = availability and failover
Read replica = read scaling

AWS has newer RDS Multi-AZ DB cluster deployments where reader instances can serve read traffic, so wording matters. But the classic SAA-C03 trap remains: a standby replica in a Multi-AZ DB instance deployment is not a read-scaling target.

2. Why This Service Exists

Relational databases are stateful. If a database instance fails, an application can be down even when the web and app tiers are healthy. If read traffic grows, the primary database can become overloaded even when writes are manageable.

Those are different problems.

High availability asks:

How do we keep the database available if the primary instance or AZ has trouble?

Read scaling asks:

How do we serve more read queries without overloading the primary?

RDS Multi-AZ addresses the first problem. RDS read replicas address the second. A mature design may use both, but the exam wants you to choose based on the stated requirement.

This distinction is also real architecture. If a system is slow because of read-heavy reporting queries, Multi-AZ will not fix that. If a system lacks automatic failover, a read replica alone may not satisfy the high availability requirement.

3. The Naive Approach And Where It Breaks

The naive approach is to see the word "replica" and assume every copy behaves the same.

That leads to wrong designs:

• using Multi-AZ standby for read traffic in a classic DB instance deployment
• using read replicas when the requirement is automatic failover
• using one primary database for all reads and writes until it overloads
• treating asynchronous replication as if it had no lag
• assuming cross-Region read replicas give instant disaster recovery without planning promotion and application routing

A clearer approach is to name the problem first:

need failover -> Multi-AZ
need read scale -> read replica
need regional DR -> cross-Region replica or backup strategy
need both -> combine patterns deliberately

4. Core Primitives

A classic RDS Multi-AZ DB instance deployment has a primary DB instance and a synchronous standby replica in a different Availability Zone. RDS manages failover. The application uses the database endpoint and should reconnect after failover.

A read replica is manually created from a source DB instance for supported engines. Replication is generally asynchronous. The replica has its own endpoint and can serve read-only traffic for supported engines.

A cross-Region read replica places the replica in another AWS Region. It can support lower-latency reads in another Region or disaster recovery patterns, but replication lag and promotion planning matter.

RDS Multi-AZ DB clusters are a newer high availability deployment mode with a writer and readable reader instances across three AZs for supported engines and instance classes. This is different from the classic single-standby Multi-AZ deployment.

Backups and snapshots are separate recovery tools. They protect against data loss and accidental changes, not live read scaling.

5. Architecture Use Cases

Use Multi-AZ when the requirement is high availability, automatic failover, planned maintenance resilience, or protection against DB instance or Availability Zone disruption.

Use read replicas when the workload is read-heavy, reporting queries should be offloaded, or regional read locality is needed.

Use cross-Region read replicas when the architecture needs a replica in another Region for disaster recovery or read locality. Promotion and DNS/application routing must be planned.

Use both when a production relational database needs high availability and read scaling:

app writes -> primary RDS DB instance
critical failover -> Multi-AZ standby
read-heavy queries -> read replicas

If the workload can tolerate a different data model and needs massive key-value scale, compare with DynamoDB instead of forcing RDS to solve every scaling problem.

7. Security Model

Multi-AZ does not change the basic RDS security model. Security groups, subnet groups, encryption, database users, IAM API permissions, and secrets management still matter.

Read replicas also need security group and network design. If a replica is cross-Region, security and networking must account for that Region. Applications need permission and connectivity to the replica endpoint.

Encryption behavior depends on source configuration and engine support. If the source is encrypted, replicas and snapshots must be designed with KMS key permissions in mind.

Read replicas should not become an accidental data exposure path. A replica contains copied production data. Treat it with the same data classification and access controls as the primary.

8. Reliability And Resilience

Classic Multi-AZ improves availability through synchronous standby replication and managed failover. It protects against many DB instance and AZ disruptions.

Read replicas improve read capacity and can support some recovery scenarios, but asynchronous replication means lag can exist. A replica may not contain the latest committed writes at every moment.

If a primary fails in a Multi-AZ deployment, RDS can fail over to the standby. If the source of a read replica fails, the replica does not automatically become the primary for the application unless a promotion and routing process exists.

Applications should use RDS endpoints and handle reconnection. Failover is not invisible to every connection pool. Timeouts, retries, and connection refresh behavior matter.

Backups and point-in-time recovery remain important even with Multi-AZ and replicas. Replication can copy bad writes too.

9. Performance And Scaling

Multi-AZ can add write latency because synchronous replication is involved. It is chosen for availability, not performance improvement.

Read replicas can reduce read load on the primary. They work best when read queries can tolerate eventual consistency and replica lag.

Applications must route read queries to the replica endpoint. RDS does not automatically split application reads between primary and replicas for all applications.

Slow queries, missing indexes, poor connection management, and bad schema design can still hurt performance. Replicas are not a substitute for database tuning.

For write scaling, read replicas are not enough. A single RDS primary still handles writes. Consider schema optimization, partitioning strategies, caching, Aurora features, or different data stores depending on the workload.

10. Cost Model

Multi-AZ costs more than Single-AZ because standby infrastructure and replicated storage are involved. The cost buys availability and managed failover.

Read replicas cost more because each replica is a DB instance with storage and operational cost. Cross-Region replicas can add data transfer and regional cost.

Using both Multi-AZ and read replicas is valid for critical workloads, but it should match requirements. Adding replicas "just in case" can create unnecessary spend.

Cost optimization should not remove availability from a production database unless the recovery requirements allow it. Conversely, do not pay for high availability when the workload is disposable or easily restored.

12. SAA-C03 Exam Signals

"High availability" points to Multi-AZ.

"Automatic failover" points to Multi-AZ.

"Scale read-heavy workload" points to read replicas.

"Offload reporting queries" points to read replicas.

"Standby cannot serve reads" points to classic Multi-AZ DB instance deployments.

"Replica in another Region" points to cross-Region read replica or snapshot copy depending on recovery and read requirements.

"Recover from accidental delete or bad write" points to backups and point-in-time recovery, not merely replicas.

13. Common Exam Traps

Do not use classic Multi-AZ standby for read scaling.

Do not use read replicas as the automatic failover answer unless the question explicitly describes promotion or a supported cluster behavior.

Do not ignore replication lag on read replicas.

Do not forget that read replicas must be manually created and application reads must use their endpoints.

Do not assume Multi-AZ removes the need for backups. Bad data can be replicated.

Do not miss wording about Multi-AZ DB clusters, which can include readable reader instances and differ from classic single-standby Multi-AZ DB instance deployments.

15. Related Topics

Review Amazon RDS for the base service model before memorizing the comparison.

Then compare with Amazon DynamoDB when the problem shifts from relational SQL to managed NoSQL access-pattern design.

Official AWS references:

• RDS Multi-AZ DB instance deployments
• RDS read replicas
• RDS Multi-AZ DB clusters