Available RDS instances running in a single Availability Zone

What a single-AZ database is exposed to

A single-AZ RDS instance lives on one host in one Availability Zone. If that host or zone has a problem, the database is down until RDS recovers it or you restore from backup. A Multi-AZ DB instance deployment keeps a synchronous standby replica in a different zone and fails over to it automatically, which also shortens the disruption during planned maintenance.

For MariaDB, MySQL, Oracle and PostgreSQL this uses Amazon’s own failover technology; SQL Server uses Database Mirroring or Always On Availability Groups.

Finding single-AZ instances

aws rds describe-db-instances \
  --query 'DBInstances[?MultiAZ==`false`].[DBInstanceIdentifier,Engine,DBInstanceClass,DBInstanceStatus]' \
  --output table

Aurora clusters show up in this list too, but their availability is configured at the cluster level, so ignore rows whose Engine starts with aurora.

Conditions an instance must meet

1. Its status is available.
2. The Multi-AZ flag ZopNight recorded from RDS is not true.
3. The engine is a standard RDS engine: MySQL, MariaDB, PostgreSQL, SQL Server or Oracle.
4. It is not identified as a dev or test database. An environment tag of prod always keeps an instance in scope; otherwise a dev or test environment tag, or a dev or test pattern in the instance name, takes it out.

Databases the check skips

Aurora, Neptune and DocumentDB instances are skipped, as is any instance whose engine is unknown, because Multi-AZ works differently for them. Instances already running Multi-AZ are never flagged; the check reads the live flag rather than a tag. Development and test databases are left alone on purpose, since doubling up their infrastructure is rarely worth it.

A resilience finding that raises the bill

This rule reports $0 in savings because the fix costs money. Engine pricing pages such as RDS for MySQL pricing list Multi-AZ instance and storage rates separately from Single-AZ ones. The RDS pricing page states that RDS does not charge for the data transferred between zones to replicate a Multi-AZ deployment. Weigh that increase against what an hour of downtime on this database costs you.

Converting to Multi-AZ

1. Confirm the database is production and that its recovery objective justifies a standby.
2. Pick a time. RDS snapshots the primary volumes, builds the standby from them and turns on synchronous replication; AWS warns this can raise write latency while the standby’s volumes initialize.
3. Apply the change:

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

4. For write-sensitive production databases, AWS suggests a read-replica path instead: convert a read replica to Multi-AZ, let it hydrate, then promote it.