RDS Multi-AZ vs Read Replica

RDS DB instances replicas can be created in two ways Multi-AZ & Read Replica, which provide high availability, durability, and scalability to RDS.

Purpose

• Multi-AZ DB Instance deployments provide high availability, durability, and automatic failover support.
• Multi-AZ DB Cluster deployments provide high availability with readable standbys, faster failover (under 35 seconds), improved write latency, and increased read capacity.
• Read replicas enable increased scalability and database availability in the case of an AZ failure. Read Replicas allow elastic scaling beyond the capacity constraints of a single DB instance for read-heavy database workloads.

Region & Availability Zones

• RDS Multi-AZ DB Instance deployment automatically provisions and manages a standby instance in a different AZ (independent infrastructure in a physically separate location) within the same AWS region.
• RDS Multi-AZ DB Cluster deployment provisions a writer DB instance and two readable standby DB instances across three different AZs within the same region.
• RDS Read Replicas can be provisioned within the same AZ, Cross-AZ or even as a Cross-Region replica.

Replication Mode

• RDS Multi-AZ DB Instance deployment manages a synchronous standby instance in a different AZ.
• RDS Multi-AZ DB Cluster deployment uses semi-synchronous replication (transaction acknowledged when at least one standby confirms write) for high durability with improved write latency.
• RDS Read Replicas have data replicated asynchronously from the Primary instance to the read replicas.

Standby Instance can Accept Reads

• Multi-AZ DB Instance deployment is a high-availability solution and the standby instance does not support read requests.
• Multi-AZ DB Cluster deployment provides two readable standby instances that can serve read traffic, increasing application read throughput.
• Read Replica deployment provides readable instances to increase application read-throughput.

Automatic Failover & Failover Time

• Multi-AZ DB Instance deployment performs an automatic failover to the standby instance without administrative intervention, and the failover time is typically 60–120 seconds based on crash recovery.
  • Planned database maintenance
  • Software patching
  • Rebooting the Primary instance with failover
  • Primary DB instance connectivity or host failure, or an
  • Availability Zone failure
• Multi-AZ DB Cluster deployment provides automated failover typically under 35 seconds with zero data loss. When combined with RDS Proxy, failover downtime can be reduced to under 1 second.
• RDS maintains the same endpoint for the DB Instance after a failover, so the application can resume database operation without the need for manual administrative intervention.
• Read Replica deployment does not provide automatic failover. Read Replica instance needs to be manually promoted to a Standalone instance.

Upgrades

• For a Multi-AZ DB Instance deployment, database engine version upgrades happen on the Primary instance with downtime of 60–120 seconds for failover.
• For a Multi-AZ DB Cluster deployment, minor version upgrades can be completed with 35 seconds or less of downtime (under 1 second with RDS Proxy).
• RDS Blue/Green Deployments provide a safer upgrade mechanism by creating a staging (green) environment, testing changes, and then switching over with typically under 5 seconds of downtime (as of Jan 2026).
• For Read Replicas, the database engine version upgrade is independent of the Primary instance.

Automated Backups

• Multi-AZ DB Instance deployment has the Automated Backups taken from the Standby instance (reducing I/O impact on Primary).
• Multi-AZ DB Cluster deployment takes automated backups from one of the reader instances.
• Read Replicas do not have any backups configured by default, but automated backups can be enabled on read replicas.

Cascading (Chained) Read Replicas

• RDS supports creating a Read Replica of another Read Replica (cascading), which helps scale reads without adding overhead to the source DB instance.
• MySQL: Supports cascading read replicas with up to 3 levels of chaining.
• PostgreSQL: Supports cascading read replicas from version 14.1 onwards, with up to 3 levels of chaining and 5 replicas per instance (up to 155 total read replicas per source).
• Cross-Region cascading read replicas are also supported for PostgreSQL.

Delayed Read Replicas (New – 2025)

• RDS for PostgreSQL now supports delayed read replicas (Aug 2025), allowing you to specify a minimum time period (0 to 24 hours) that a replica lags behind the source.
• Creates a time buffer that helps protect against accidental data loss from human errors such as table drops or unintended data modifications.
• When data corruption occurs on primary, the delayed replica can be promoted before the problematic operation is applied, providing recovery within minutes.
• Configured using the recovery_min_apply_delay parameter.
• Available with RDS for PostgreSQL versions 14.19, 15.14, 16.10, 17.6 and later.
• RDS for MySQL also supports delayed replication using the mysql.rds_set_source_delay stored procedure.

RDS Proxy for Improved Failover

• Amazon RDS Proxy is a fully managed, highly available database proxy that can significantly reduce failover times.
• RDS Proxy eliminates DNS propagation delay by continuously monitoring both primary and standby instances, allowing faster failover response.
• When used with Multi-AZ DB Cluster deployments, RDS Proxy can reduce minor version upgrade downtime to under 1 second.
• RDS Proxy also helps manage connection pooling and reduces database connection overhead for applications using many connections (e.g., Lambda functions).

SQL Server Multi-AZ Replication Technologies

• RDS for SQL Server supports Multi-AZ using Always On Availability Groups (AGs) for Enterprise and Standard editions.
• SQL Server Database Mirroring (DBM) was the legacy approach but is deprecated; AWS recommends migrating to Always On AGs.
• New (Nov 2025): RDS for SQL Server Web Edition now supports Multi-AZ using block-level replication, eliminating the need for more expensive Enterprise/Standard editions for high availability.
• SQL Server Read Replicas now support cross-region deployment in 16+ additional AWS Regions (Jan 2026) and additional storage volumes up to 256 TiB (May 2026).

Comparison Summary Table

Related Posts

• RDS Multi-AZ DB Instance
• RDS Multi-AZ DB Cluster
• RDS Multi-AZ DB Instance vs DB Cluster Deployment
• RDS Read Replicas
• RDS Cross-Region Read Replicas
• Amazon RDS Proxy
• Amazon RDS Blue/Green Deployments

📖 Related: AWS RDS Backup, Snapshots & Restore – Complete Guide

AWS Certification Exam Practice Questions

• Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
• AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
• AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
• Open to further feedback, discussion and correction.

1. You are running a successful multi-tier web application on AWS and your marketing department has asked you to add a reporting tier to the application. The reporting tier will aggregate and publish status reports every 30 minutes from user-generated information that is being stored in your web applications database. You are currently running a Multi-AZ RDS MySQL instance for the database tier. You also have implemented ElastiCache as a database caching layer between the application tier and database tier. Please select the answer that will allow you to successfully implement the reporting tier with as little impact as possible to your database.
   1. Continually send transaction logs from your master database to an S3 bucket and generate the reports of the S3 bucket using S3 byte range requests.
   2. Generate the reports by querying the synchronously replicated standby RDS MySQL instance maintained through Multi-AZ (Standby instance cannot be used as a scaling solution)
   3. Launch an RDS Read Replica connected to your Multi-AZ master database and generate reports by querying the Read Replica.
   4. Generate the reports by querying the ElastiCache database caching tier. (ElasticCache does not maintain full data and is simply a caching solution)
2. A company is deploying a new two-tier web application in AWS. The company has limited staff and requires high availability, and the application requires complex queries and table joins. Which configuration provides the solution for the company’s requirements?
   1. MySQL Installed on two Amazon EC2 Instances in a single Availability Zone (does not provide High Availability out of the box)
   2. Amazon RDS for MySQL with Multi-AZ
   3. Amazon ElastiCache (Just a caching solution)
   4. Amazon DynamoDB (Not suitable for complex queries and joins)
3. Your company is getting ready to do a major public announcement of a social media site on AWS. The website is running on EC2 instances deployed across multiple Availability Zones with a Multi-AZ RDS MySQL Extra Large DB Instance. The site performs a high number of small reads and writes per second and relies on an eventual consistency model. After comprehensive tests you discover that there is read contention on RDS MySQL. Which are the best approaches to meet these requirements? (Choose 2 answers)
   1. Deploy ElastiCache in-memory cache running in each availability zone
   2. Implement sharding to distribute load to multiple RDS MySQL instances (this is only a read contention, the writes work fine)
   3. Increase the RDS MySQL Instance size and Implement provisioned IOPS (not scalable, this is only a read contention, the writes work fine)
   4. Add an RDS MySQL read replica in each availability zone
4. Your company has HQ in Tokyo and branch offices all over the world and is using logistics software with a multi-regional deployment on AWS in Japan, Europe and US. The logistic software has a 3-tier architecture and currently uses MySQL 5.6 for data persistence. Each region has deployed its own database. In the HQ region you run an hourly batch process reading data from every region to compute cross-regional reports that are sent by email to all offices this batch process must be completed as fast as possible to quickly optimize logistics. How do you build the database architecture in order to meet the requirements?
   1. For each regional deployment, use RDS MySQL with a master in the region and a read replica in the HQ region
   2. For each regional deployment, use MySQL on EC2 with a master in the region and send hourly EBS snapshots to the HQ region
   3. For each regional deployment, use RDS MySQL with a master in the region and send hourly RDS snapshots to the HQ region
   4. For each regional deployment, use MySQL on EC2 with a master in the region and use S3 to copy data files hourly to the HQ region
   5. Use Direct Connect to connect all regional MySQL deployments to the HQ region and reduce network latency for the batch process
5. What would happen to an RDS (Relational Database Service) Multi-Availability Zone deployment if the primary DB instance fails?
   1. IP of the primary DB Instance is switched to the standby DB Instance.
   2. A new DB instance is created in the standby availability zone.
   3. The canonical name record (CNAME) is changed from primary to standby.
   4. The RDS (Relational Database Service) DB instance reboots.
6. Your business is building a new application that will store its entire customer database on a RDS MySQL database, and will have various applications and users that will query that data for different purposes. Large analytics jobs on the database are likely to cause other applications to not be able to get the query results they need to, before time out. Also, as your data grows, these analytics jobs will start to take more time, increasing the negative effect on the other applications. How do you solve the contention issues between these different workloads on the same data?
   1. Enable Multi-AZ mode on the RDS instance
   2. Use ElastiCache to offload the analytics job data
   3. Create RDS Read-Replicas for the analytics work
   4. Run the RDS instance on the largest size possible
7. Will my standby RDS instance be in the same Availability Zone as my primary?
   1. Only for Oracle RDS types
   2. Yes
   3. Only if configured at launch
   4. No
8. Is creating a Read Replica of another Read Replica supported?
   1. Only in certain regions
   2. Only with MySQL based RDS Yes, for MySQL and PostgreSQL (14.1+). Both support cascading read replicas with up to 3 levels of chaining.
   3. Only for Oracle RDS types
   4. No
9. A user is planning to set up the Multi-AZ feature of RDS. Which of the below mentioned conditions won’t take advantage of the Multi-AZ feature?
   1. Availability zone outage
   2. A manual failover of the DB instance using Reboot with failover option
   3. Region outage
   4. When the user changes the DB instance’s server type
10. When you run a DB Instance as a Multi-AZ deployment, the “_____” serves database writes and reads
    1. secondary
    2. backup
    3. stand by
    4. primary
11. When running my DB Instance as a Multi-AZ deployment, can I use the standby for read or write operations?
    1. Yes
    2. Only with MSSQL based RDS
    3. Only for Oracle RDS instances
    4. No (for Multi-AZ DB Instance deployment. Note: Multi-AZ DB Cluster deployment provides readable standbys)
12. Read Replicas require a transactional storage engine and are only supported for the _________ storage engine
    1. OracleISAM
    2. MSSQLDB
    3. InnoDB
    4. MyISAM
13. A user is configuring the Multi-AZ feature of an RDS DB. The user came to know that this RDS DB does not use the AWS technology, but uses server mirroring to achieve replication. Which DB is the user using right now?
    1. MySQL
    2. Oracle
    3. MS SQL (Note: AWS now recommends Always On Availability Groups over Database Mirroring. SQL Server Web Edition uses block-level replication for Multi-AZ as of Nov 2025.)
    4. PostgreSQL
14. If I have multiple Read Replicas for my master DB Instance and I promote one of them, what happens to the rest of the Read Replicas?
    1. The remaining Read Replicas will still replicate from the older master DB Instance
    2. The remaining Read Replicas will be deleted
    3. The remaining Read Replicas will be combined to one read replica
15. If you have chosen Multi-AZ deployment, in the event of a planned or unplanned outage of your primary DB Instance, Amazon RDS automatically switches to the standby replica. The automatic failover mechanism simply changes the ______ record of the main DB Instance to point to the standby DB Instance.
    1. DNAME
    2. CNAME
    3. TXT
    4. MX

16. When automatic failover occurs, Amazon RDS will emit a DB Instance event to inform you that automatic failover occurred. You can use the _____ to return information about events related to your DB Instance
    1. FetchFailure
    2. DescriveFailure
    3. DescribeEvents
    4. FetchEvents
17. The new DB Instance that is created when you promote a Read Replica retains the backup window period.
    1. TRUE
    2. FALSE
18. Will I be alerted when automatic failover occurs?
    1. Only if SNS configured
    2. No
    3. Yes
    4. Only if Cloudwatch configured
19. Can I initiate a “forced failover” for my MySQL Multi-AZ DB Instance deployment?
    1. Only in certain regions
    2. Only in VPC
    3. Yes
    4. No
20. A user is accessing RDS from an application. The user has enabled the Multi-AZ feature with the MS SQL RDS DB. During a planned outage how will AWS ensure that a switch from DB to a standby replica will not affect access to the application?
    1. RDS will have an internal IP which will redirect all requests to the new DB
    2. RDS uses DNS to switch over to standby replica for seamless transition
    3. The switch over changes Hardware so RDS does not need to worry about access
    4. RDS will have both the DBs running independently and the user has to manually switch over
21. Which of the following is part of the failover process for a Multi-AZ Amazon Relational Database Service (RDS) instance?
    1. The failed RDS DB instance reboots.
    2. The IP of the primary DB instance is switched to the standby DB instance.
    3. The DNS record for the RDS endpoint is changed from primary to standby.
    4. A new DB instance is created in the standby availability zone.
22. Which of these is not a reason a Multi-AZ RDS instance will failover?
    1. An Availability Zone outage
    2. A manual failover of the DB instance was initiated using Reboot with failover
    3. To autoscale to a higher instance class (Refer link)
    4. Master database corruption occurs
    5. The primary DB instance fails
23. You need to scale an RDS deployment. You are operating at 10% writes and 90% reads, based on your logging. How best can you scale this in a simple way?
    1. Create a second master RDS instance and peer the RDS groups.
    2. Cache all the database responses on the read side with CloudFront.
    3. Create read replicas for RDS since the load is mostly reads.
    4. Create a Multi-AZ RDS installs and route read traffic to standby.
24. How does Amazon RDS multi Availability Zone model work?
    1. A second, standby database is deployed and maintained in a different availability zone from master, using synchronous replication. (Refer link)
    2. A second, standby database is deployed and maintained in a different availability zone from master using asynchronous replication.
    3. A second, standby database is deployed and maintained in a different region from master using asynchronous replication.
    4. A second, standby database is deployed and maintained in a different region from master using synchronous replication.
25. A customer is running an application in US-West (Northern California) region and wants to setup disaster recovery failover to the Asian Pacific (Singapore) region. The customer is interested in achieving a low Recovery Point Objective (RPO) for an Amazon RDS multi-AZ MySQL database instance. Which approach is best suited to this need?
    1. Synchronous replication
    2. Asynchronous replication
    3. Route53 health checks
    4. Copying of RDS incremental snapshots
26. A user is using a small MySQL RDS DB. The user is experiencing high latency due to the Multi AZ feature. Which of the below mentioned options may not help the user in this situation?
    1. Schedule the automated back up in non-working hours
    2. Use a large or higher size instance
    3. Use PIOPS
    4. Take a snapshot from standby Replica
27. Are Reserved Instances available for Multi-AZ Deployments?
    1. Only for Cluster Compute instances
    2. Yes for all instance types
    3. Only for M3 instance types
28. My Read Replica appears “stuck” after a Multi-AZ failover and is unable to obtain or apply updates from the source DB Instance. What do I do?
    1. You will need to delete the Read Replica and create a new one to replace it.
    2. You will need to disassociate the DB Engine and re-associate it.
    3. The instance should be deployed to Single AZ and then moved to Multi-AZ once again
    4. You will need to delete the DB Instance and create a new one to replace it.
29. What is the charge for the data transfer incurred in replicating data between your primary and standby?
    1. No charge. It is free.
    2. Double the standard data transfer charge
    3. Same as the standard data transfer charge
    4. Half of the standard data transfer charge
30. A user has enabled the Multi-AZ feature with the MS SQL RDS database server. Which of the below mentioned statements will help the user understand the Multi-AZ feature better?
    1. In a Multi-AZ, AWS runs two DBs in parallel and copies the data asynchronously to the replica copy
    2. In a Multi-AZ, AWS runs two DBs in parallel and copies the data synchronously to the replica copy
    3. In a Multi-AZ, AWS runs just one DB but copies the data synchronously to the standby replica
    4. AWS MS SQL does not support the Multi-AZ feature
31. A company is running a batch analysis every hour on their main transactional DB running on an RDS MySQL instance to populate their central Data Warehouse running on Redshift. During the execution of the batch their transactional applications are very slow. When the batch completes they need to update the top management dashboard with the new data. The dashboard is produced by another system running on-premises that is currently started when a manually sent email notifies that an update is required The on-premises system cannot be modified because is managed by another team. How would you optimize this scenario to solve performance issues and automate the process as much as possible?
    1. Replace RDS with Redshift for the batch analysis and SNS to notify the on-premises system to update the dashboard
    2. Replace RDS with Redshift for the batch analysis and SQS to send a message to the on-premises system to update the dashboard
    3. Create an RDS Read Replica for the batch analysis and SNS to notify the on-premises system to update the dashboard
    4. Create an RDS Read Replica for the batch analysis and SQS to send a message to the on-premises system to update the dashboard.

New Practice Questions (Multi-AZ DB Cluster & Recent Features)

31. A company needs a highly available MySQL database with the fastest possible automatic failover time and the ability to offload read queries to standby instances. Which RDS deployment option should they choose?
    1. Multi-AZ DB Instance deployment with Read Replicas
    2. Single-AZ with automated backups
    3. Multi-AZ DB Cluster deployment
    4. Aurora Global Database
32. What is the typical failover time for an RDS Multi-AZ DB Cluster deployment?
    1. 60–120 seconds
    2. 5–10 minutes
    3. Under 35 seconds
    4. Under 5 seconds
33. Which replication method does the RDS Multi-AZ DB Cluster deployment use?
    1. Asynchronous replication
    2. Synchronous replication
    3. Semi-synchronous replication
    4. Logical replication
34. A database administrator wants to protect against accidental table drops by maintaining a replica that lags behind the primary by 1 hour. Which RDS feature should they use?
    1. Multi-AZ DB Instance standby
    2. Cross-Region Read Replica
    3. Delayed Read Replica
    4. Blue/Green Deployment
35. Which of the following DB engines support Multi-AZ DB Cluster deployments? (Choose 2)
    1. Oracle
    2. MySQL
    3. SQL Server
    4. PostgreSQL
    5. MariaDB
36. How can you reduce RDS Multi-AZ DB Cluster minor version upgrade downtime to under 1 second?
    1. Use Blue/Green Deployments
    2. Use Amazon RDS Proxy
    3. Use cross-region read replicas
    4. Use ElastiCache for connection pooling