Amazon RDS Multi-AZ deployments and read replicas both create additional database instances or copies, but they exist for different reasons. Multi-AZ is primarily an availability design. Read replicas are primarily a read-scaling design, with promotion and cross-Region options that can also support recovery and migration strategies.
The current AWS Certified Solutions Architect – Associate exam expects architects to separate availability, performance, consistency, and disaster recovery rather than assuming that “another copy of the database” solves every requirement. The important first step is to identify whether the workload needs a managed failover target, more read capacity, geographic separation, or some combination of those goals.
Separate availability from read scaling
A highly available database should continue operating when a component or Availability Zone fails. A read-scaled database should handle more read traffic without overloading its writer. Those objectives overlap in some modern RDS designs, but they are not the same architectural requirement.
Traditional RDS Multi-AZ DB instance deployments use a primary instance and a standby in another Availability Zone. The standby is maintained for failover and is not an application read endpoint. RDS manages the synchronous replication and the failover process. Read replicas, by contrast, are separately addressable copies used to serve read-only workloads and normally receive changes asynchronously.
A scenario that says “the database must survive an Availability Zone failure with minimal administrative intervention” points toward Multi-AZ. A scenario that says “reporting queries are consuming most of the writer’s CPU” points toward read replicas. Treating those phrases as interchangeable leads to the wrong design.
Understand traditional Multi-AZ DB instance deployments
In a Multi-AZ DB instance deployment, RDS maintains a standby DB instance in a different Availability Zone from the primary. The standby is part of the availability mechanism. Application traffic uses the DB instance endpoint, and RDS can redirect that endpoint to the new primary during a managed failover.
Failover can occur for infrastructure failures and certain maintenance or operational events. The application should therefore use the DNS endpoint rather than hard-coding an underlying IP address. It must also tolerate connection interruption while clients resolve the endpoint and establish new sessions. Multi-AZ reduces the recovery burden, but it does not make in-flight database connections immortal.
The synchronous nature of the standby path is one reason this model is about resilience rather than read throughput. The standby is not a second query server for reports. If the requirement includes both high availability and read scaling, additional design elements are needed.
Multi-AZ DB clusters combine availability with readable instances
AWS also supports Multi-AZ DB clusters for supported engines. This architecture is different from the traditional two-instance Multi-AZ deployment. A Multi-AZ DB cluster has one writer and two readable DB instances across three Availability Zones. The readers can serve read traffic and are also candidates for failover.
That distinction is important because the old statement “Multi-AZ instances cannot serve reads” is too broad. It remains true for the standby in a traditional Multi-AZ DB instance deployment, but not for the readable instances in a Multi-AZ DB cluster. Architecture questions should identify which deployment model is being discussed.
Multi-AZ DB clusters can reduce the gap between the availability and read-scaling requirements, but they do not remove application design concerns. The application still needs a strategy for writer versus reader endpoints, connection pools, transaction semantics, and the possibility that a recently committed write is not appropriate to read from every path in exactly the same way.
Use read replicas to offload read-heavy work
RDS read replicas are intended to move eligible reads away from the source database. Reporting, analytics, catalog browsing, dashboards, and other read-dominant workloads can query a replica instead of competing with transactions on the writer.
Replication to a read replica is generally asynchronous, so the replica can lag behind the source. The amount of lag depends on the engine, workload, network conditions, and replica capacity. This makes read replicas unsuitable for requests that must immediately observe the result of a just-committed transaction unless the application deliberately sends those reads to the writer.
A practical application may use the writer endpoint for account updates and immediately subsequent account reads, while sending historical reports to replicas. The architecture is therefore not just “add replicas.” It includes routing decisions in the application or data-access layer.
Promotion is useful, but it is not the same as Multi-AZ failover
A read replica can be promoted to a standalone database. Promotion can support disaster recovery, migrations, testing, or a planned topology change. However, promotion is conceptually different from the managed failover of a Multi-AZ deployment.
With Multi-AZ, the standby or reader failover target is already part of the managed availability design and the DB endpoint is handled by RDS. With a standard read replica, promotion changes the replica into an independent database. Applications, DNS records, secrets, connection strings, or other routing mechanisms may need to be updated to use it.
That difference affects recovery objectives. If the requirement is rapid local failover with minimal manual intervention, traditional read-replica promotion is not a substitute for Multi-AZ. If the requirement is to keep a geographically separated copy that can be promoted during a regional disaster, a cross-Region replica may be an important part of the plan.
Cross-Region replicas solve a different failure boundary
For supported engines and configurations, RDS read replicas can exist in another AWS Region. This creates geographic separation that a Multi-AZ deployment inside one Region does not provide. Cross-Region replicas can support regional read locality, migration, and disaster-recovery preparation.
The tradeoffs are greater replication latency, inter-Region data-transfer considerations, additional cost, and a more involved failover process. A cross-Region replica is not automatically a complete disaster-recovery solution. The recovery plan must also cover networking, application deployment, DNS, secrets, encryption keys where relevant, dependencies, and the operational procedure for promotion.
Recovery point objective matters as well. Because read-replica replication is asynchronous, the promoted copy may not contain the very latest transactions if a regional failure occurs before all changes arrive. The business must decide whether that data-loss window is acceptable.
Plan for replica lag and connection behavior
Replica lag is not only a monitoring metric; it affects application correctness. A user might update a record through the writer and then query a replica that has not yet received the update. The result can appear as though the write failed even though the database is behaving as designed.
Applications can address this in several ways. Critical read-after-write paths can remain on the writer. Less time-sensitive reads can use replicas. Some systems record a consistency boundary or temporarily pin a user’s reads to the writer after an update. The correct pattern depends on the business requirement rather than a universal rule.
Connection behavior also matters during Multi-AZ failover. Test failover during a controlled window so the team can measure DNS refresh, pool recovery, and application retry behavior instead of discovering those client-side assumptions during an outage. DNS endpoint changes are managed by RDS, but clients may cache DNS, hold long-lived connections, or use connection pools with retry settings that delay recovery. A resilient design tests client reconnection behavior instead of assuming the managed service alone guarantees application continuity.
Backups, replicas, and Multi-AZ protect against different events
Neither Multi-AZ nor a read replica replaces a backup strategy. Replication normally copies valid writes and many forms of logical change, including accidental changes that the application successfully commits. If a user deletes important rows, the replication mechanisms are doing their job when that deletion reaches additional copies.
Automated backups, snapshots, and point-in-time recovery address a different need: restoring an earlier data state. Multi-AZ addresses infrastructure availability. Read replicas address read scaling and can support some recovery topologies. Backups address historical recovery. A production design often needs all three capabilities in different combinations.
This is why an architect should ask what failure is being protected against. Hardware failure, Availability Zone loss, regional loss, accidental deletion, and overloaded read traffic are not one problem and should not be solved with one feature by default.
Combine the patterns when the workload needs multiple outcomes
A common production architecture uses Multi-AZ for the writer’s local availability and read replicas for read scaling. A globally distributed application might add a cross-Region replica for geographic read access or regional recovery. A Multi-AZ DB cluster can provide readable instances and managed failover within its supported model.
The selection should therefore be requirement-driven. Choose a traditional Multi-AZ DB instance deployment when the central requirement is managed high availability and the standby does not need to serve reads. Evaluate a Multi-AZ DB cluster when supported engines and workload characteristics benefit from readable instances plus high availability. Add read replicas when the application needs to scale reads, isolate reporting load, or maintain promotable copies. Add cross-Region replicas only when the geographic requirement and recovery process justify their cost and operational complexity.
A third-party SAA-C03 database resilience case should make its failure goal explicit before naming an AWS database feature. An Availability Zone outage calls for failover reasoning, read-heavy reporting calls for read-throughput reasoning, and a cross-Region disruption calls for a different recovery design. Multi-AZ, read replicas, and backups are complementary tools with different jobs, not three interchangeable answers.