Multi-AZ RDS Failover Readiness: An Evidence Checklist

Multi-AZ is an availability configuration, not proof that an application recovers cleanly. The practical decision is narrower: does the team have enough evidence to schedule a controlled failover exercise, or are there unresolved prerequisites?

Amazon RDS offers two Multi-AZ deployment forms. A Multi-AZ DB instance has one standby that supports failover but does not serve read traffic. A Multi-AZ DB cluster has a writer and two readable standby instances in three Availability Zones. Identify the form before applying a runbook; their endpoints and operations are not interchangeable.

Failover-readiness evidence checklist

Copy this table into the change ticket. Mark an item ready only when the evidence link or command output is attached. The commands below are read-only except for the separately identified failover exercise.

1. Identify the deployment form

For a DB instance, inspect the Multi-AZ flag:

aws rds describe-db-instances \
  --db-instance-identifier my-db \
  --query 'DBInstances[0].{MultiAZ:MultiAZ,AvailabilityZone:AvailabilityZone,DBSubnetGroup:DBSubnetGroup.DBSubnetGroupName,Endpoint:Endpoint.Address}'

For a Multi-AZ DB cluster, inspect the cluster and its members instead:

aws rds describe-db-clusters \
  --db-cluster-identifier my-cluster \
  --query 'DBClusters[0].{MultiAZ:MultiAZ,Members:DBClusterMembers[*].{Identifier:DBInstanceIdentifier,Writer:IsClusterWriter},Endpoint:Endpoint,ReaderEndpoint:ReaderEndpoint}'

Do not infer the deployment form from a tag or naming convention.

2. Record subnet-group coverage

aws rds describe-db-subnet-groups \
  --db-subnet-group-name my-subnet-group \
  --query 'DBSubnetGroups[0].Subnets[*].{Subnet:SubnetIdentifier,AZ:SubnetAvailabilityZone.Name,Status:SubnetStatus}'

Attach the distinct AZs and subnet status to the ticket. This confirms configuration evidence; it does not prove that every application dependency can recover during a failover.

3. Review client reconnection behavior

RDS changes the DNS record during a Multi-AZ DB instance failover, and existing database connections must be re-established. Before a drill, document:

• where the application resolves the database endpoint;
• how its connection pool removes broken or stale connections;
• which errors are retried, at what layer, and with what bound; and
• which application signal demonstrates successful recovery.

For JVM clients, compare the deployed DNS cache settings with AWS's current TTL guidance in the failover documentation. For other runtimes, verify the actual driver and resolver behavior rather than copying JVM settings.

4. Separate availability evidence from backup evidence

aws rds describe-db-instances \
  --db-instance-identifier my-db \
  --query 'DBInstances[0].{BackupRetentionDays:BackupRetentionPeriod,LatestRestorableTime:LatestRestorableTime}'

AWS documents that setting a DB instance backup retention period to 0 disables automated backups. A nonzero value still does not prove that the application can restore within its recovery objectives. Link a separate restore-test record if the readiness decision depends on recoverability from deletion or corruption.

5. Define observable exercise evidence

Use RDS events and application telemetry to define the exercise timeline. At minimum, record:

• the approved start time and initiating operator;
• the RDS event sequence;
• the first failed application operation, if any;
• the first confirmed successful application operation after recovery; and
• whether any manual restart or connection-pool intervention was required.

Avoid promising a universal recovery duration. AWS states that failover duration depends on database activity, recovery work, and other conditions. Your measured result applies to that exercise and workload, not every future event.

6. Treat the forced failover as a controlled change

For a Multi-AZ DB instance, AWS supports a reboot with failover:

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

This command is intentionally not part of the read-only evidence collection. It interrupts the database and can require crash recovery. Run it only inside an approved change window after reviewing current AWS guidance, transaction safety, application impact, and stop conditions. Multi-AZ DB clusters have different operational procedures; use the documentation for the deployment form you actually run.

Decision record

Choose one outcome and put it in the ticket:

• Ready for a controlled exercise: every gate has attached evidence, owners, signals, and stop conditions.
• Not ready: one or more prerequisites are missing; name the owner and next review date.
• Configuration only: Multi-AZ is enabled, but recovery behavior has not been exercised. Do not describe this state as tested failover readiness.

After the exercise, preserve the command parameters, RDS events, application recovery signal, manual interventions, and follow-up actions as the evidence packet. That artifact is more useful than a screenshot showing only MultiAZ: true.

Sources

Sources reviewed 2026-07-18:

• Configuring and managing a Multi-AZ deployment for Amazon RDS
• Failing over a Multi-AZ DB instance for Amazon RDS
• Rebooting a DB instance
• Backup retention period