What's the impact of converting my Single-AZ Amazon RDS instance to a Multi-AZ instance and vice versa?

Last updated: 2021-09-30

I want to know the impact of converting my Single-AZ Amazon Relational Database Service (Amazon RDS) DB instance to a Multi-AZ instance.


I want to know the impact of converting my Multi-AZ Amazon RDS DB instance to a Single-AZ instance.

Short description

In a Single-AZ setup, one DB instance and one or more Amazon Elastic Block Store (Amazon EBS)storage volumes are deployed in one Availability Zone across data centers. In a Multi-AZ configuration, Amazon RDS DB instances and EBS storage volumes are deployed across multiple Availability Zones.

When you enable Multi-AZ on your instance, Amazon RDS maintains a redundant and consistent standby copy of your data using synchronous storage replication. Amazon RDS detects and automatically recovers from the most common failure scenarios for Multi-AZ deployments so that you can resume database operations as quickly as possible. For more information, see High availability (Multi-AZ) for Amazon RDS.

To convert a DB instance from Single-AZ deployment to a MultiAZ deployment and vice versa, see Modifying an Amazon RDS instance.

When you convert your Single-AZ instance to a Multi-AZ instance, you can see the following event in the Logs & Events section on the Amazon RDS console:

September 21, 2021, 8:45:04 PM UTC            Applying modification to convert to a Multi-AZ DB Instance


Impact of modifying a Single-AZ instance to a Multi-AZ instance

When you modify your Single-AZ instance to a Multi-AZ instance, you don't experience any downtime on the instance. During the conversion, Amazon RDS creates a snapshot of the instance and uses this snapshot to restore data into the new volumes created in another Availability Zone. Though these new volumes are immediately available for use, you might experience some performance issues. This is because, the DB instance continues to load data in the background. This process, called lazy loading, might lead to elevated write latency and a performance impact during and after the conversion. The performance impact is a function of your volume type, workload, instance, and volume size. The impact might be significant for large write-intensive DB instances during the peak hours of operations.

To reduce the latency after you modify the instance, it's a best practice to do the following:

  1. Initiate a failover for your instance after converting to Multi-AZ.
  2. Run a full dump of the data on your instance to fetch all the data from the snapshot.

When you convert an instance from Single-AZ to Multi-AZ, a new instance is created with the same configuration in another Availability Zone. This leads to additional costs. Also, because Multi-AZ deployment uses synchronous replication, the writes are slower than those in Single-AZ.

Impact of modifying a Multi-AZ instance to a Single-AZ instance

When you modify your instance from a Multi-AZ instance to a Single-AZ instance, you don't experience any downtime on the instance. During the conversion, Amazon RDS deletes only the secondary instance and volumes, and the primary instance is not impacted during this time.

Here are a few things to consider before modifying your instance from Multi-AZ to Single-AZ deployment:

  • With the Multi-AZ deployment, Amazon RDS automatically switches to a standby replica in another Availability Zone during a planned or unplanned outage of your DB instance. However, in a Single-AZ instance, you might have to initiate a point-in-time-restore operation. This operation might take several hours to complete, and any data updates that occurred after the latest restorable time isn't available. Therefore, you might experience an additional downtime on a Single-AZ instance in case of a failure.
  • In a Multi-AZ instance, automated backups are created from the secondary instance during the automatic backup window. For Amazon RDS for MariaDB, Amazon RDS for MySQL, Amazon RDS for Oracle, and Amazon RDS for PostgreSQL, I/O activity is not suspended on your primary instance during backup for Multi-AZ deployments, because the backup is taken from the secondary. For Amazon RDS for SQL Server, I/O activity is suspended briefly during backup for Multi-AZ deployments. The backup process on a Single-AZ DB instance results in a brief I/O suspension that can last from a few seconds to a few minutes, depending on the size and class of your DB instance.
  • In Multi-AZ deployments, operating system maintenance is applied to the secondary instance. The second instance is promoted to primary, and then maintenance is performed on the old primary, which becomes the new standby. Therefore, the downtime during certain OS patches in a MultiAZ instance is minimal.
  • If you're scaling your Multi-AZ instance, the downtime is minimal. This is because, the secondary instance is upgraded first. The secondary instance is promoted to primary, after which the primary instance is upgraded. A Single-AZ instance becomes unavailable during the scaling operation.

Did this article help?

Do you need billing or technical support?