Amazon RDS Multi-AZ with one standby

Automatic fail over Protect database performance Enhance durability Increase availability 
Support high availability for your application with automatic database failover that completes as quickly as 60 seconds with zero data loss and no manual intervention.
Avoid suspending I/O activity on your primary during backup by backing up from your standby instance.
Use Amazon RDS Multi-AZ synchronous replication technologies to keep data on your standby database instance up to date with the primary. Enhance availability by deploying a standby instance in a second AZ, and achieve fault tolerance in the event of an AZ or database instance failure.

How it works

In an Amazon RDS Multi-AZ deployment, Amazon RDS automatically creates a primary database (DB) instance and synchronously replicates the data to an instance in a different AZ. When it detects a failure, Amazon RDS automatically fails over to a standby instance without manual intervention.
Amazon RDS Multi-AZ deployment How It Works Diagram

Amazon RDS Multi-AZ with two readable standbys

Automatically fail over in typically under 35 seconds Use separate endpoints for reads and writes Gain up to 2x faster transaction commit latency Minor version upgrades in typically under 1 second 
Automatically failover in typically under 35 seconds with zero data loss and with no manual intervention. Route queries to write servers and appropriate read replica standby instances to maximize performance and scalability.  Achieve up to 2x improved write latency compared to Multi-AZ with one standby. Reduce minor version upgrade downtime to typically under 35 seconds. Further reduce downtime to typically under 1 second by adding an open source or RDS Proxy to your deployment.

How it works

Deploy highly available, durable MySQL or PostgreSQL databases in three AZs using Amazon RDS Multi-AZ with two readable standbys. Gain automatic failovers in typically under 35 seconds, up to 2x faster transaction commit latency compared to Amazon RDS Multi-AZ with one standby, additional read capacity, and a choice of AWS Graviton2– or Intel–based instances for compute.

Amazon Aurora

Automatically failover in quickly as 5 seconds  Optimize performance with up to 15 read replicas Maximize durability

Achieve 99.99% availability 

Automatically failover as quickly as 5 seconds during an instance failure and avoid downtime Ensure peak performance and optimize read capacity by replicating data to one of up to 15 low-latency read replicas Secure data during failures or the loss of an AZ with an SSD-backed virtualized storage layer that replicates data six ways across three AZs  Safeguard your database availability with up to 99.99% uptime each monthly billing cycle

How it works

Amazon Aurora employs an SSD-backed virtualized storage layer that automatically replicas your storage six ways across three AZs, handling loss of up to two copies of data without affecting write availability and up to three copies without affecting read availability.
Introduction to Amazon RDS Multi-AZ (1:20)

Introduction to Amazon RDS Multi-AZ

Amazon RDS Multi-AZ deployments provide enhanced availability and durability for your Amazon RDS database (DB) instances, making them a natural fit for production database workloads. With two different deployment options, you can customize your workloads for the availability they need.
Introduction to Amazon RDS Multi-AZ
Amazon RDS Multi-AZ deployments provide enhanced availability and durability for your Amazon RDS database (DB) instances, making them a natural fit for production database workloads. With two different deployment options, you can customize your workloads for the availability they need.

Comparison Table

Amazon RDS Single-AZ or Amazon RDS Multi-AZ with one standby or Amazon RDS Multi-AZ with two readable standbys

Feature

Single-AZ

Multi-AZ with one standby

Multi-AZ with two readable standbys

Available engines

  • Amazon RDS for PostgreSQL
  • Amazon RDS for MySQL
  • Amazon RDS for MariaDB
  • Amazon RDS for SQL Server
  • Amazon RDS for Oracle
  • Amazon RDS for Db2
  • Amazon RDS for PostgreSQL
  • Amazon RDS for MySQL
  • Amazon RDS for MariaDB
  • Amazon RDS for SQL Server
  • Amazon RDS for Oracle
  • Amazon RDS for Db2
  • Amazon RDS for PostgreSQL
  • Amazon RDS for MySQL

Additional Read
capacity

  • None: the read capacity is limited to your primary
  • None: Your standby DB instance is only a passive failover target for high availability
  • Two standby DB instances act as failover targets and serve read traffic
  • Read capacity is determined by the overhead of write transactions from the primary

·        

Lower latency (higher throughput) for transaction commits

 

 

  • Up to 2x faster transaction commits compared to Amazon RDS Multi-AZ with one standby

Automatic failover duration

  • Not available: a user, a user-initiated point-in-time-restore operation will be required.
  • This operation can take several hours to complete
  • Any data updates that occurred after the latest restorable time (typically within the last 5 minutes) will not be available
  • A new primary is available to serve your new workload in as quickly as 60 seconds
  • Failover time is independent of write throughput
  • A new primary is available to serve your new workload in typically under 35 seconds
  • Failover time depends on length of replica lag
Minor version upgrades downtime
  • When using Automatic Minor Version Upgrades, minor version upgrade downtime occurs during the Amazon RDS 30-minute maintenance window
  • When using Automatic Minor Version Upgrades, minor version upgrade downtime occurs during the Amazon RDS 30-minute maintenance window
  • Typically under 1 second when customers add an open source or Amazon RDS Proxy to their deployment
  • Typically under 35 seconds with Multi-AZ with two readable standbys alone

Higher resiliency to AZ outage

  • None: in the event of an AZ failure, your risk data loss and hours of failover time
  • In the event of an AZ failure, your workload will automatically failover to the up-to-date standby
  • In the event of a failure, one of the two remaining standbys will takeover and serve the workload (writes) from the primary

Lower jitter for transaction commits

  • No optimization for jitter
  • Access to Dedicated Log Volumes
  • Uses local storage for transactional logs to reduce jitter

Customers

SysCloud creates automatic backups for critical software as a service (SaaS) applications, monitors for malicious files, and delivers powerful insights about your data and compliance —all from one dashboard. SysCloud uses Amazon RDS Multi-AZ with two readable standbys for its internal monitoring system: “The new Amazon RDS Multi-AZ deployment option offers us a cost-efficient way to achieve better performance, availability, and read scalability,” said Vikram Srinivasan, Director, Infrastructure at SysCloud. “With the new Amazon RDS Multi-AZ deployment option, we expect to create a better experience for our customers.”

Pricing

Amazon RDS Multi-AZ is available for RDS for PostgreSQL, RDS for MySQL, RDS for MariaDB, RDS for SQL Server, RDS for Oracle, and RDS for Db2. Amazon RDS Multi-AZ with two readable standbys is available for RDS for PostgreSQL and RDS for MySQL. To learn about how Amazon Aurora provides enhanced availability by automatically replicating storage six ways across three Availability Zones, see Amazon Aurora.

For Single-AZ deployments, Multi-AZ deployments with one standby instance, and Multi-AZ deployments with two readable standbys, pricing is per DB instance-hour consumed, from the time a DB instance is launched until it is stopped or deleted. Partial DB instance-hours are billed in one-second increments with a 10 minute minimum charge following a billable status change such as creating, starting, or modifying the DB instance class.

For more information on pricing for Amazon RDS Multi-AZ, see the Amazon RDS pricing pages. 

Resources

Getting Started

Use the following user guides and tutorials to quickly get started with Amazon RDS Multi-AZ.

DOCUMENTATION


Describes Amazon RDS Multi-AZ with one standby concepts and provides instructions on modifying your DB instance to be a Multi-AZ deployment and the failover process for Amazon RDS.

DOCUMENTATION


Describes Amazon RDS Multi-AZ with two readable standbys concepts and provides instructions on modifying, renaming, rebooting, and deleting a cluster; using read replicas; and using PostgreSQL logical replication with Multi-AZ DB clusters.

GETTING STARTED TUTORIAL


In this tutorial, create an Oracle database Standard Edition Two instance on Amazon RDS using the License Included model and how to enable features, such as Multi-AZ and Performance Insights.

Videos

Watch sessions, webinars, and other videos to deep dive into Amazon RDS Multi-AZ.

ONLINE TECH TALK


In this session, get a brief intro into Multi-AZ, its deployment options, the benefits of each option, and deep dive into the two readable standby option and its recent enhancements.

Blogs

Read about the latest improvements to Amazon RDS Multi-AZ and dive deep into how you can use it for your Amazon RDS use cases. 

FAQs

What does it mean to run a DB instance as a Multi-AZ deployment?

When you create or modify your DB instance to run as a Multi-AZ deployment, Amazon RDS automatically provisions and maintains a synchronous “standby” replica in a different Availability Zone. Updates to your DB Instance are synchronously replicated across Availability Zones to the standby in order to keep both in sync and protect your latest database updates against DB instance failure.

During certain types of planned maintenance, or in the unlikely event of DB instance failure or Availability Zone failure, Amazon RDS will automatically failover to the standby so that you can resume database writes and reads as soon as the standby is promoted. Since the name record for your DB instance remains the same, your application can resume database operation without the need for manual administrative intervention. With Multi-AZ deployments, replication is transparent. You do not interact directly with the standby, and it cannot be used to serve read traffic. More information about Multi-AZ deployments is in the Amazon RDS User Guide.

What is an Availability Zone?

Availability Zones are distinct locations within a Region that are engineered to be isolated from failures in other Availability Zones. Each Availability Zone runs on its own physically distinct, independent infrastructure, and is engineered to be highly reliable. Common points of failures like generators and cooling equipment are not shared across Availability Zones. Additionally, they are physically separate, such that even extremely uncommon disasters such as fires, tornados, or flooding would only affect a single Availability Zone. Availability Zones within the same Region benefit from low-latency network connectivity.

What do “primary” and “standby” mean in the context of a Multi-AZ deployment?

When you run a DB instance as a Multi-AZ deployment, the “primary” serves database writes and reads. In addition, Amazon RDS provisions and maintains a “standby” behind the scenes, which is an up-to-date replica of the primary. The standby is “promoted” in failover scenarios. After failover, the standby becomes the primary and accepts your database operations. You do not interact directly with the standby (e.g. for read operations) at any point prior to promotion. If you are interested in scaling read traffic beyond the capacity constraints of a single DB instance, please see the FAQs on Read Replicas.

What are the benefits of a Multi-AZ deployment?

The chief benefits of running your DB instance as a Multi-AZ deployment are enhanced database durability and availability. The increased availability and fault tolerance offered by Multi-AZ deployments make them a natural fit for production environments.

Running your DB instance as a Multi-AZ deployment safeguards your data in the unlikely event of a DB instance component failure or loss of availability in one Availability Zone. For example, if a storage volume on your primary fails, Amazon RDS automatically initiates a failover to the standby, where all of your database updates are intact. This provides additional data durability relative to standard deployments in a single AZ, where a user-initiated restore operation would be required and updates that occurred after the latest restorable time (typically within the last five minutes) would not be available.

You also benefit from enhanced database availability when running your DB instance as a Multi-AZ deployment. If an Availability Zone failure or DB instance failure occurs, your availability impact is limited to the time automatic failover takes to complete. The availability benefits of Multi-AZ also extend to planned maintenance.

For example, with automated backups, I/O activity is no longer suspended on your primary during your preferred backup window, since backups are taken from the standby. In the case of patching or DB instance class scaling, these operations occur first on the standby, prior to automatic failover. As a result, your availability impact is limited to the time required for automatic failover to complete.

Another implied benefit of running your DB instance as a Multi-AZ deployment is that DB instance failover is automatic and requires no administration. In an Amazon RDS context, this means you are not required to monitor DB instance events and initiate manual DB instance recovery (via the RestoreDBInstanceToPointInTime or RestoreDBInstanceFromSnapshot APIs) in the event of an Availability Zone failure or DB instance failure.
 

Are there any performance implications of running my DB instance as a Multi-AZ deployment?

You may observe elevated latencies relative to a standard DB instance deployment in a single Availability Zone as a result of the synchronous data replication performed on your behalf.

How do I set up a Multi-AZ DB instance deployment?

In order to create a Multi-AZ DB instance deployment, simply click the “Yes” option for “Multi-AZ Deployment” when launching a DB Instance with the AWS Management Console.

Alternatively, if you are using the Amazon RDS APIs, you would call the CreateDBInstance API and set the “Multi-AZ” parameter to the value “true.” To convert an existing standard (single-AZ) DB instance to Multi-AZ, modify the DB instance in the AWS Management Console or use the ModifyDBInstance API and set the Multi-AZ parameter to true.
 

What happens when I convert my Amazon RDS instance from Single-AZ to Multi-AZ?

For the RDS for PostgreSQL, RDS for MySQL, RDS for MariaDB, RDS for SQL Server, RDS for Oracle, and RDS for Db2 database engines, when you elect to convert your Amazon RDS instance from Single-AZ to Multi-AZ, the following happens:

  • A snapshot of your primary instance is taken.
  • A new standby instance is created in a different Availability Zone, from the snapshot.
  • Synchronous replication is configured between primary and standby instances.

As such, there should be no downtime incurred when an instance is converted from Single-AZ to Multi-AZ. However, you might see increased latency while the data on the standby is caught up to match to the primary.

What events would cause Amazon RDS to initiate a failover to the standby replica?

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 without administrative intervention. Amazon RDS automatically performs a failover in the event of any of the following:

  • Loss of availability in primary Availability Zone
  • Loss of network connectivity to primary
  • Compute unit failure on primary
  • Storage failure on primary

Note: When operations such as DB instance scaling or system upgrades, like OS patching, are initiated for Multi-AZ deployments, for enhanced availability they are applied first on the standby prior to automatic failover. As a result, your availability impact is limited only to the time required for automatic failover to complete. Note that Amazon RDS Multi-AZ deployments do not failover automatically in response to database operations, such as long running queries, deadlocks, or database corruption errors.

Will I be alerted when automatic failover occurs on Amazon RDS?

Yes, Amazon RDS will emit a DB instance event to inform you that automatic failover occurred. You can click the “Events” section of the Amazon RDS Console or use the DescribeEvents API to return information about events related to your DB instance. You can also use Amazon RDS Event Notifications to be notified when specific DB events occur.

What happens during Multi-AZ failover and how long does it take?

Failover is automatically handled by Amazon RDS so that you can resume database operations as quickly as possible without administrative intervention. When failing over, Amazon RDS simply flips the canonical name record (CNAME) for your DB instance to point at the standby, which is in turn promoted to become the new primary. We encourage you to follow best practices and implement database connection retry at the application layer.

Failovers, as defined by the interval between the detection of the failure on the primary and the resumption of transactions on the standby, typically complete within one to two minutes. Failover time can also be affected by whether large uncommitted transactions must be recovered; the use of adequately large instance types is recommended with Multi-AZ for best results. AWS also recommends the use of Provisioned IOPS with Multi-AZ instances, for fast, predictable, and consistent throughput performance.

Can I initiate a “forced failover” for my Multi-AZ DB instance deployment?

Amazon RDS will automatically failover without user intervention under a variety of failure conditions. In addition, Amazon RDS provides an option to initiate a failover when rebooting your instance. You can access this feature via the AWS Management Console or when using the RebootDBInstance API call.

How do I control/configure Multi-AZ synchronous replication?

With Multi-AZ deployments, you simply set the “Multi-AZ” parameter to true. The creation of the standby, synchronous replication, and failover are all handled automatically. This means you cannot select the Availability Zone your standby is deployed in or alter the number of standbys available (Amazon RDS provisions one dedicated standby per DB instance primary). The standby also cannot be configured to accept database read activity. Learn more about Multi-AZ configurations.

Will my standby be in the same Region as my primary?

Yes. Your standby is automatically provisioned in a different Availability Zone of the same Region as your DB instance primary.

Can I see which Availability Zone my primary is currently located in?

Yes, you can gain visibility into the location of the current primary by using the AWS Management Console or DescribeDBInstances API.

After failover, my primary is now located in a different Availability Zone than my other AWS resources (e.g. EC2 instances). Should I be concerned about latency?

Availability Zones are engineered to provide low latency network connectivity to other Availability Zones in the same Region. In addition, you may want to consider architecting your application and other AWS resources with redundancy across multiple Availability Zones so your application will be resilient in the event of an Availability Zone failure. Multi-AZ deployments address this need for the database tier without administration on your part.

How do DB Snapshots and automated backups work with my Multi-AZ deployment?

You interact with automated backup and DB Snapshot functionality in the same way whether you are running a standard deployment in a Single-AZ or Multi-AZ deployment. If you are running a Multi-AZ deployment, automated backups and DB Snapshots are simply taken from the standby to avoid I/O suspension on the primary. Please note that you may experience increased I/O latency (typically lasting a few minutes) during backups for both Single-AZ and Multi-AZ deployments.

Initiating a restore operation (point-in-time restore or restore from DB Snapshot) also works the same with Multi-AZ deployments as standard, Single-AZ deployments. New DB instance deployments can be created with either the RestoreDBInstanceFromSnapshot or RestoreDBInstanceToPointInTime APIs. These new DB instance deployments can be either standard or Multi-AZ, regardless of whether the source backup was initiated on a standard or Multi-AZ deployment.

Learn more about Amazon RDS features
Learn with 10-minute tutorials

Explore Amazon RDS with simple tutorials.

Explore hands-on training 
Sign up for an AWS account
Start building with Amazon RDS and Amazon Aurora

Dig into the Amazon RDS User Guide to get started.

Read the documentation 
Start building with Amazon RDS in the console
Dive Deep on Amazon RDS Multi-AZ

Dive deep into how Amazon RDS Multi-AZ works and the different deployment options.

Watch the session