Multi-AZ DB Instance

AWS RDS Multi-AZ – DB Instance vs DB Cluster Deployment

RDS Multi-AZ DB Instance vs DB Cluster
~ Last updated on : ~ jayendrapatil

RDS Multi-AZ DB Instance vs DB Cluster

  • 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.

RDS Multi-AZ DB Instance vs DB Cluster

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 2x faster transaction commit latency 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 is typically under 35 seconds.
  • Using RDS Proxy with Multi-AZ DB cluster can further reduce failover time by bypassing DNS propagation delays.

Maintenance & Upgrades

  • Multi-AZ DB instance deployment requires longer downtime for minor version upgrades as the primary instance must be upgraded.
  • Multi-AZ DB cluster deployment supports minor version upgrades and system maintenance updates with typically 35 seconds or less of write downtime.
  • When combined with RDS Proxy, Multi-AZ DB cluster can achieve minor version upgrades with typically 1 second or less of downtime.

Storage Options

  • Single AZ and Multi-AZ DB instance deployments support General Purpose SSD (gp2, gp3), Provisioned IOPS (io1, io2), and magnetic storage (deprecated April 2026).
  • Multi-AZ DB clusters now support three storage types:
    • General Purpose gp3 (added Feb 2024) – Cost-effective option with up to 64,000 IOPS, suitable for a broad range of workloads.
    • Provisioned IOPS io1 – Up to 256,000 IOPS with consistent single-digit millisecond latency.
    • Provisioned IOPS io2 Block Express (added Mar 2024) – Sub-millisecond latency, 99.999% durability, up to 256,000 IOPS. Best for latency-sensitive mission-critical workloads.

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.

Performance Optimizations (Multi-AZ DB Cluster)

  • RDS Optimized Writes – Delivers up to 2x improvement in write transaction throughput by writing only once to the database (bypasses the double-write buffer).
  • RDS Optimized Reads – Provides up to 2x faster complex query processing by using local NVMe-based instance storage for temporary tables.
  • These optimizations are available for Multi-AZ DB cluster deployments with supported instance classes.

Additional Features (Multi-AZ DB Cluster)

  • IAM Database Authentication (Oct 2024) – Centrally manage database access using AWS IAM instead of password-based credentials.
  • Security Certificate Rotation (Mar 2024) – Supports rotation of database security certificates for enhanced security.
  • Stop and Start (Aug 2024) – Multi-AZ DB clusters can be stopped and started, useful for reducing costs in non-production environments.
  • RDS Proxy Support – Enables connection pooling, faster failover, and reduced downtime during maintenance.

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 creates 3 instances. However, with the addition of gp3 storage support (Feb 2024), it is now more cost-effective for workloads that previously required io1 volumes.
  • Multi-AZ DB Cluster can replace a Multi-AZ DB instance plus a separate read replica, potentially reducing total cost while improving performance.

Use Cases

  • Single AZ deployments are suitable for non-critical dev, test environments.
  • Multi-AZ DB instance deployments are suitable for production workloads requiring high availability with simple failover.
  • Multi-AZ DB cluster deployments are suitable for critical production environments requiring high availability, low write latency, read scalability, fast failover (under 35 seconds), and minimal maintenance downtime.

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. A company runs a critical production database on Amazon RDS for MySQL. They need high availability with the fastest possible failover time and also require read scalability. Which deployment option best meets these requirements?
    1. Single-AZ DB instance with Read Replicas
    2. Multi-AZ DB instance deployment
    3. Multi-AZ DB cluster deployment
    4. Amazon Aurora with Read Replicas
    Show Answer

    Answer: c – Multi-AZ DB cluster provides failover typically under 35 seconds and readable standby instances for read scaling.

  2. A company uses an RDS Multi-AZ DB cluster and wants to minimize downtime during minor version upgrades. What should they do to achieve less than 1 second of downtime?
    1. Convert to Aurora
    2. Use RDS Proxy in front of the Multi-AZ DB cluster
    3. Use Blue/Green deployments
    4. Take a manual snapshot before upgrade
    Show Answer

    Answer: b – RDS Proxy with Multi-AZ DB cluster reduces minor version upgrade downtime to typically 1 second or less.

  3. Which storage types are supported for RDS Multi-AZ DB cluster deployments? (Select THREE)
    1. General Purpose SSD (gp2)
    2. General Purpose SSD (gp3)
    3. Provisioned IOPS (io1)
    4. Provisioned IOPS (io2 Block Express)
    5. Magnetic storage
    Show Answer

    Answer: b, c, d – Multi-AZ DB clusters support gp3, io1, and io2 Block Express storage volumes.

  4. What is the typical failover time for an RDS Multi-AZ DB cluster deployment?
    1. Under 120 seconds
    2. Under 75 seconds
    3. Under 35 seconds
    4. Under 10 seconds
    Show Answer

    Answer: c – Multi-AZ DB cluster failover is typically under 35 seconds.

References

AWS RDS Multi-AZ DB Instance

RDS Multi-AZ Instance Deployment
~ Last updated on : ~ jayendrapatil ~ 2 Comments

RDS Multi-AZ DB Instance Deployment

  • 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 or consider Multi-AZ DB Cluster deployment which provides readable standbys.
  • Multi-AZ deployments for MariaDB, MySQL, Oracle, PostgreSQL, and RDS Custom for SQL Server DB instances use Amazon failover technology. SQL Server DB instances use SQL Server Database Mirroring (DBM) or Always On Availability Groups (AGs). SQL Server 2022 Web Edition supports Multi-AZ through block-level replication.

RDS Multi-AZ Instance Deployment

  • 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 optimized for Provisioned IOPS (e.g., current-generation M5, M6g, M6i, R5, R6g, R6i, or newer Graviton-based instances) 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.

ENA Express for Multi-AZ Replication (2026)

  • As of May 2026, Amazon RDS Multi-AZ instances use ENA Express for replication traffic between Availability Zones.
  • ENA Express uses AWS’s Scalable Reliable Datagram (SRD) protocol to optimize network performance.
  • Delivers up to 25 Gbps single-flow bandwidth for cross-AZ replication traffic with advanced congestion control and multi-pathing capabilities.
  • Reduces latency variability for Multi-AZ deployments and delivers increased write throughput and lower write latencies for write-intensive workloads.
  • SRD improves replication by dynamically distributing traffic across multiple network paths and adapting to congestion in real time.
  • Available at no additional charge for RDS for MariaDB, MySQL, PostgreSQL, Db2, and Oracle.
  • To enable on existing instances, perform a start-stop or scale compute action.

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.
    • DNS propagation can take up to 35 seconds to complete during failover.
    • 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.

RDS Proxy for Faster Failover

  • Amazon RDS Proxy can significantly reduce failover downtime for Multi-AZ DB instance deployments.
  • RDS Proxy eliminates the 35-second DNS propagation delay by continuously monitoring both primary and standby instances, allowing it to bypass DNS propagation entirely.
  • As of Dec 2024, AWS has optimized the planned failover process with RDS Proxy:
    • Modify instance class — downtime reduced by up to 4.9x (MariaDB), 4.3x (MySQL), 3.3x (PostgreSQL)
    • OS upgrades — downtime reduced by up to 4.8x (MySQL), 4x (MariaDB), 3.4x (PostgreSQL)
    • Reboot with force failover — downtime reduced by up to 3x (MariaDB), 2.5x (MySQL), 1.5x (PostgreSQL)
  • During maintenance operations, RDS performs maintenance on the standby first, then does a planned failover, then completes maintenance on the old primary — minimizing overall downtime.
  • These improvements are available for RDS for MySQL, MariaDB, and PostgreSQL with no changes needed to workloads.

Multi-AZ DB Instance vs Multi-AZ DB Cluster

RDS Multi-AZ DB Instance vs DB Cluster

  • Multi-AZ DB Instance: One primary + one standby (standby NOT readable). Failover typically 60-120 seconds.
  • Multi-AZ DB Cluster: One writer + two reader instances in three AZs. Readers can serve read traffic. Failover typically under 35 seconds. Supports MySQL and PostgreSQL only.
  • Multi-AZ DB Cluster provides improved commit latency, faster failover, readable standby instances, and lower write latency compared to Multi-AZ DB Instance deployment.
  • Choose Multi-AZ DB Cluster when you need both read scaling and fast failover in a single managed deployment.

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.

References