RDS Multi-AZ deployments provide high availability and automatic failover support for DB instances
Multi-AZ helps improve the durability and availability of a critical system, enhancing availability during planned system maintenance, DB instance failure, and Availability Zone disruption.
A Multi-AZ DB instance deployment has one standby DB instance that provides failover support but doesn’t serve read traffic.
A Multi-AZ DB cluster deployment has two standby DB instances that provide failover support and can also serve read traffic.
Instances & Availability Zones
A Single AZ instance creates a single DB instance in any specified AZ.
A Multi-AZ DB Instance deployment creates a Primary and a Standby instance in two different AZs
A Multi-AZ DB Cluster deployment creates a Primary Writer and two Readable Standby instances in three different AZs
Replication Mode
Multi-AZ DB instance deployment synchronously replicates the data from the primary DB instance to a standby instance in a different AZ.
Multi-AZ DB cluster deployment semi-synchronously replicates data from the writer DB instance to both reader DB instances using the DB engine’s native replication capabilities.
Standby Instance can Accept Reads
Multi-AZ DB instance deployment is a high-availability solution and the standby instance does not support requests.
Multi-AZ DB cluster deployment provides readable standby instances to increase application read-throughput.
Commit Latency
Single AZ instance has the lowest commit latency.
Multi-AZ DB instance deployment has a high commit latency as compared to the Single AZ instance as the data needs to be synchronously replicated to the standby instance.
Multi-AZ DB cluster deployment provides up to two thirds faster commits for commits compared to Multi-AZ DB instance as it performs semi-synchronous replication.
Automatic Failover & Failover Time
Single AZ instances do not support automatic failover and failure would result in data loss. Use point-in-time recovery with backups to restore the database.
Multi-AZ DB instance deployment performs an automatic failover to the standby instance, and the failover time can be up to 120 seconds based on the crash recovery.
Multi-AZ DB cluster deployment performs an automatic failover to a reader DB instance in a different AZ, and the failover time can be up to 75 seconds depending on the replica lag.
Supported Engines
Single AZ and Multi-AZ DB instance deployments support all DB engines
Multi-AZ DB clusters are supported only for the MySQL and PostgreSQL DB engines.
Cost
Single AZ is the most cost-effective option.
Multi-AZ DB Instance deployment costs more than a Single AZ as it maintains a synchronous standby instance.
Multi-AZ DB Cluster would be an expensive option as it creates 3 instances, supports specific instance classes that do not include burstable classes, and does not support general-purpose SSD volumes.
Use Cases
Single AZ deployments are suitable for non-critical dev, test environments.
Multi-AZ deployments are suitable for critical, production-based environments requiring high availability, data redundancy, and scalability for read workloads.
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.
RDS automatically creates a primary DB Instance and synchronously replicates the data to a standby instance in a different AZ.
RDS performs an automatic failover to the standby, so that database operations can be resumed as soon as the failover is complete.
RDS Multi-AZ deployment 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.
Multi-AZ is a High Availability feature and NOT a scaling solution for read-only scenarios; a standby replica can’t be used to serve read traffic. To service read-only traffic, use a Read Replica.
Multi-AZ deployments for Oracle, PostgreSQL, MySQL, and MariaDB DB instances use Amazon technology, while SQL Server DB instances use SQL Server Mirroring.
In a Multi-AZ deployment,
RDS automatically provisions and maintains a synchronous standby replica in a different Availability Zone.
Copies of data are stored in different AZs for greater levels of data durability.
Primary DB instance is synchronously replicated across Availability Zones to a standby replica to provide
data redundancy,
eliminate I/O freezes during snapshots and backups
and minimize latency spikes during system backups.
DB instances may have increased write and commit latency compared to a Single AZ deployment, due to the synchronous data replication
Transaction success is returned only if the commit is successful both on the primary and the standby DB
There might be a change in latency if the deployment fails over to the standby replica, although AWS is engineered with low-latency network connectivity between Availability Zones.
When using the BYOL licensing model, a license for both the primary instance and the standby replica is required
For production workloads, it is recommended to use Multi-AZ deployment with Provisioned IOPS and DB instance classes (m1.large and larger), optimized for Provisioned IOPS for fast, consistent performance.
When Single-AZ deployment is modified to a Multi-AZ deployment (for engines other than SQL Server or Amazon Aurora)
RDS takes a snapshot of the primary DB instance from the deployment and restores the snapshot into another Availability Zone.
RDS then sets up synchronous replication between the primary DB instance and the new instance.
This avoids downtime during conversion from Single AZ to Multi-AZ.
An existing Single AZ instance can be converted into a Multi-AZ instance by modifying the DB instance without any downtime.
RDS Multi-AZ Failover Process
In the event of a planned or unplanned outage of the DB instance,
RDS automatically switches to a standby replica in another AZ, if enabled for Multi-AZ.
The time taken for the failover to complete depends on the database activity and other conditions at the time the primary DB instance became unavailable.
Failover times are typically 60-120 secs. However, large transactions or a lengthy recovery process can increase failover time.
Failover mechanism automatically changes the DNS record of the DB instance to point to the standby DB instance.
Multi-AZ switch is seamless to the applications as there is no change in the endpoint URLs but just needs to re-establish any existing connections to the DB instance.
RDS handles failover automatically so that database operations can be resumed as quickly as possible without administrative intervention.
Primary DB instance switches over automatically to the standby replica if any of the following conditions occur:
Primary Availability Zone outage
Loss of network connectivity to primary
Primary DB instance fails
DB instance’s server type is changed
Operating system of the DB instance is undergoing software patching
Compute unit failure on the primary
Storage failure on the primary
A manual failover of the DB instance was initiated using Reboot with failover (also referred to as Forced Failover)
If the Multi-AZ DB instance has failed over, can be determined by
DB event subscriptions can be set up to notify you via email or SMS that a failover has been initiated.
DB events can be viewed via the Amazon RDS console or APIs.
The current state of the Multi-AZ deployment can be viewed via the RDS console and APIs.
Multi-AZ DB Instance vs Multi-AZ DB Cluster
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.
