RDS Multi-AZ for High Availability

Amazon RDS (Relational Database Service) runs managed databases like PostgreSQL, MySQL, and SQL Server for you. By default, a database instance lives in a single Availability Zone (an AZ is an isolated data center within an AWS Region). If that one AZ has a hardware failure or a power outage, your database goes down. Multi-AZ fixes this by keeping a hot standby copy in a second AZ and switching over to it automatically when something breaks. This page explains how it works, the common trap people fall into, and exactly how to turn it on.

What Multi-AZ actually does

When you enable Multi-AZ, RDS provisions a primary instance in one AZ and a standby instance in a different AZ inside the same Region. Every write to the primary is copied to the standby synchronously — meaning the write is not confirmed to your app until both copies have it. This guarantees the standby is always an exact, up-to-date mirror.

Your application never talks to the standby directly. It connects to a single DNS endpoint (a hostname like mydb.abc123.us-east-1.rds.amazonaws.com). If the primary fails — hardware fault, AZ outage, or even routine patching — RDS automatically points that DNS endpoint at the standby, promotes it to primary, and spins up a new standby. This is called automatic failover.

Failover typically takes 60 to 120 seconds (often faster). During that window the database is unreachable, and your application must reconnect once DNS resolves to the new instance.

Gotcha — Multi-AZ does NOT give you read scaling. This is the single most common misunderstanding. In the classic Multi-AZ setup the standby is not readable — you cannot send queries to it, and it does nothing to improve performance. It exists purely for availability. If you want to spread read traffic across extra copies, that is what read replicas are for. People enable Multi-AZ expecting their database to suddenly handle more reads, and get zero benefit.

Multi-AZ instance vs Multi-AZ cluster

In 2022 AWS introduced a second flavor. Knowing the difference matters for both cost and capability.

Feature	Single-AZ	Multi-AZ instance (classic)	Multi-AZ cluster
Standby copies	None	1 standby	2 standbys
Standby readable?	N/A	No	Yes (read-only endpoint)
Failover time	Manual / longer	~60-120s	~35s typically
Replication	N/A	Synchronous	Semi-synchronous (writes ack after 1 of 2 standbys)
Engines	All	All	MySQL, PostgreSQL only
Roughly costs	1x	~2x	~2.5-3x

When to use Multi-AZ instance: the default choice for any production database. You want resilience to an AZ failure and you are fine reading only from the primary.

When to use Multi-AZ cluster: you want faster failover and you can route some read traffic to the two standbys via the cluster’s reader endpoint. Only available on MySQL and PostgreSQL.

When NOT to use Multi-AZ at all: dev/test databases, throwaway environments, or anything where a short outage is acceptable. You pay for the standby compute even though it serves no traffic, so it roughly doubles your instance cost.

Enabling Multi-AZ — Console

You can switch an existing Single-AZ instance to Multi-AZ with no need to recreate it.

Open the RDS console and choose Databases in the left menu.
Select your database instance, then click Modify.
Scroll to the Availability & durability section.
Choose Create a standby instance (recommended for production usage) for a classic Multi-AZ instance, or Multi-AZ DB cluster if you want two readable standbys.
Click Continue, choose Apply immediately (or schedule for the next maintenance window), and confirm with Modify DB instance.

Converting takes several minutes and is done online — RDS creates the standby and synchronizes it in the background. There may be a brief performance dip during the initial sync.

Enabling Multi-AZ — AWS CLI

To convert an existing instance to a classic Multi-AZ instance:

aws rds modify-db-instance \
  --db-instance-identifier mydb \
  --multi-az \
  --apply-immediately

Output:

{
    "DBInstance": {
        "DBInstanceIdentifier": "mydb",
        "DBInstanceStatus": "modifying",
        "Engine": "postgres",
        "MultiAZ": false,
        "AvailabilityZone": "us-east-1a",
        "PendingModifiedValues": {
            "MultiAZ": true
        }
    }
}

MultiAZ flips to true once the standby finishes provisioning. To create a brand-new Multi-AZ DB cluster instead, use a different command:

aws rds create-db-cluster \
  --db-cluster-identifier myapp-cluster \
  --engine postgres \
  --engine-version 16.4 \
  --db-cluster-instance-class db.r6gd.large \
  --master-username appadmin \
  --master-user-password 'Ch4ngeMe!2026' \
  --allocated-storage 100 \
  --storage-type io1 \
  --iops 3000 \
  --db-subnet-group-name my-db-subnets \
  --vpc-security-group-ids sg-0a1b2c3d

You can force a failover at any time to test your app’s reconnect logic:

aws rds reboot-db-instance \
  --db-instance-identifier mydb \
  --force-failover

Infrastructure as Code

Multi-AZ is a single property in CloudFormation, which makes it easy to enforce across all production stacks.

Resources:
  AppDatabase:
    Type: AWS::RDS::DBInstance
    Properties:
      DBInstanceIdentifier: mydb
      Engine: postgres
      EngineVersion: "16.4"
      DBInstanceClass: db.t3.medium
      AllocatedStorage: "100"
      MultiAZ: true
      MasterUsername: appadmin
      ManageMasterUserPassword: true
      DBSubnetGroupName: my-db-subnets
      VPCSecurityGroups:
        - sg-0a1b2c3d

Handling failover in your application

Because the endpoint hostname stays the same but its IP changes during failover, your app must not cache the resolved IP forever. RDS endpoints use a short DNS TTL (time to live, ~5 seconds). Make sure your connection pool detects dropped connections and retries instead of holding stale ones.

Tip: Test failover before you need it. Run reboot-db-instance --force-failover in staging and confirm your service recovers within a few seconds. A surprising number of outages are caused by apps that never reconnect after a planned failover.

Cost note

A Multi-AZ instance roughly doubles the instance cost of the equivalent Single-AZ database because you pay for the standby’s compute and storage even though it serves no traffic. A Multi-AZ DB cluster costs more still (two standbys). Storage and backup costs scale similarly. For a db.t3.medium in us-east-1, expect to go from around $50/month Single-AZ to roughly $100/month Multi-AZ.

Best Practices

Enable Multi-AZ on every production database; leave it off for dev/test to save money.
Do not expect Multi-AZ to improve read performance — add read replicas for that.
Build automatic reconnect and connection-pool health checks into your application so failovers are invisible to users.
Test failover regularly with --force-failover so you trust the recovery path.
Use Multi-AZ DB cluster (MySQL/PostgreSQL) when you need both faster failover and readable standbys.
Keep automated backups enabled — Multi-AZ protects against AZ failure, not against accidental data deletion or corruption.