High Availability with AWS RDS Multi-AZ
Tags: aws, database, cloud, cloudskills
Published: 2023-02-07 14:00:00

> **Note:** ✋ This post was originally published on my blog [wiki-cloud.co](https://wiki-cloud.co/en/2022/10/high-availability-with-amazon-rds-multi-az/) 

AWS presents high availability schemes for Amazon RDS called Multi-AZ where you can have one or two standby database instances, taking advantage of the AWS Global Infrastructure that has Availability Zones, where customers can deploy their workloads in several availability zones within a region and thus increase fault tolerance. When the deployment has one standby DB instance, it is called a **_Multi-AZ DB instance deployment_**. When the deployment has two standby DB instances, it is called a **_Multi-AZ DB cluster deployment_**.

Next, we will detail each of these implementations.

**<u>Multi-AZ DB Instance Deployments</u>**

A Multi-AZ DB instance deployment automatically creates a primary and a replica database (DB) instance in a different AZ, where it synchronously keeps the data in both instances up to date. When an error is detected, Amazon RDS automatically failover to a standby instance without the need for manual intervention. This replica is not for read traffic.

![Multi-AZ DB Instance Deployment Architecture](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/kplies2dzk5ysum9v45u.png) Image 1 – Multi-AZ DB Instance Deployment Architecture

How would be an appropriate architecture for an RDS High Availability scheme?

In the following example there is a high availability zone a and b, where an application server is deployed in each one and there is an RDS database, for this an auto-scaling group must be created that is capable of growing or shrinking In order to have requests according to the demand, a load balancer must also be added to distribute the requests according to the traffic and the processing of the application servers. In the case of failure of an application server, a new one is immediately created and the application continues to be available, but if the RDS database fails, the application will no longer be available. See Image 2.

![Multi-AZ DB Instance Deployment](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/g6ye31o5pjfnuj7uc0rb.png) Image 2 – Multi-AZ DB Instance Deployment

To solve this situation with the database, AWS has incorporated a high availability option that can be enabled from the management console by activating the multi AZ deployment or in different availability zones, you can also use the AWS CLI or the Amazon RDS API, this option creates a secondary DB instance exactly like the primary with the same instance type and EBS volume configuration in another Availability Zone, then configures synchronous replication keeping an exact duplicate of the data on the replica on standby. See Figure 3.

![Multi-AZ DB Instance Deployment](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/2vxwkf11281v07wbk9lw.png) Image 3 – Multi-AZ DB Instance Deployment

If the primary RDS instance fails, the Amazon RDS monitor will assign the standby instance as the primary until the original primary recovers, and requests from the application servers will be redirected to the new primary DB instance. See Figure 4.

![Multi-AZ DB Instance Deployment](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/djhz5jk27jfb2io2d12e.png) Image 4 – Multi-AZ DB Instance Deployment

**<u>Multi-AZ DB Cluster Deployments</u>**

A Multi-AZ DB cluster deployment is a highly available Amazon RDS deployment mode with two readable standby DB instances. A Multi-AZ DB cluster has one writer DB instance and two reader DB instances in three separate Availability Zones in the same AWS Region. Multi-AZ DB clusters provide high availability, increased capacity for read workloads, and lower write latency compared to Multi-AZ DB instance deployments.

![Multi-AZ Database Cluster Architecture](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/8ndg3aj2at3rqb9psmh7.png) Image 5 – Multi-AZ Database Cluster Architecture

With a Multi-AZ DB cluster, Amazon RDS replicates data from the writer's DB instance to both reader DB instances using the native replication capabilities of the DB engine. When a change is made to the writer DB instance, it is pushed to every reader DB instance. The acknowledgment of at least one reader database instance is required for a change to be committed.

Reader DB instances act as automatic failover targets and also serve read traffic to increase applications read performance. If an outage occurs on the writer DB instance, RDS manages the failover to one of the reader DB instances. RDS does this based on which reader's database instance has the most recent change log.

Multi-AZ DB clusters typically have lower write latency compared to Multi-AZ DB instance deployments. They also allow read-only workloads to run on reader DB instances. The RDS console displays the Availability Zone of the writer's DB instance and the Availability Zones of the reader's DB instances. Multi-AZ DB clusters are currently only available in certain AWS Regions.

To take into account some considerations, see the following comparative table.

**<u>Comparison Table</u>**

| **Feature**                                               | **Single-AZ**                                                                                                                                                                                                                                                                  | **Multi-AZ with one standby**                                                                                                            | **Multi-AZ with two readable standbys**                                                                                                                          |
|-----------------------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| **Available engines** | **-** AWS RDS for MariaDB **-** AWS RDS for MySQL **-** AWS RDS for PostgreSQL **-** AWS RDS for Oracle **-** AWS RDS for SQL Server | **-** AWS RDS for MariaDb **-** AWS RDS for MySQL **-** AWS RDS for PostgreSQL **-** AWS RDS for Oracle **-** AWS RDS for SQL Server | **-** AWS RDS for MySQL **-** AWS RDS for PostgreSQL |
| **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. |
| **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. |

<u>**AWS Databases free tier**</u>

> 💡 The AWS Free Tier offers users an opportunity to explore products for free, with offers including products that are always free, free for 12 months, and short-term free trials. AWS offers the widest selection of purpose-built databases, allowing you to save, grow, and innovate faster.

> 💡 Build database solutions using [these product offerings](https://aws.amazon.com/es/free/database/) of the AWS Free Tier.

> 💡 To obtain updated information on AWS database services, I invite you to follow their page “[AWS Databases & Analytics](https://www.linkedin.com/showcase/aws-databases/)” on Linkedin.

I hope this information is useful.

**Follow me:**

> 👉[Wiki Cloud](http://wiki-cloud.co/) | 👉[Twitter](https://twitter.com/johnbulla) | 👉[LinkedIn](https://www.linkedin.com/in/johnbulla) | 👉[Youtube](https://www.youtube.com/user/johnbulla)