Production RDS instances running without Multi-AZ

Engines where the flag means something

The per-instance Multi-AZ setting this rule reads belongs to standard RDS engines: MySQL, MariaDB, PostgreSQL, SQL Server and Oracle. Aurora is deliberately excluded: its availability story lives at the cluster and storage layer, and a per-instance Multi-AZ flag on an Aurora member is meaningless. DocumentDB and Neptune are excluded for the same reason. The engine check fails closed: an absent or unrecognized engine produces no finding, because a resilience recommendation aimed at the wrong engine family is worse than none.

Why dev and test databases are filtered out

Multi-AZ runs a synchronized standby in a second availability zone, which roughly doubles the hourly instance rate. Recommending that for a throwaway database is recommending waste. In one audited fleet, 37 of 50 raw findings from this check were uat, sit or qa instances. The rule now suppresses instances that are dev/test by name or by environment tag, unless a production environment tag explicitly overrides the name. A production tag always wins; a prod-looking name with no contradicting signal still fires.

What actually triggers a finding

A running (available) RDS instance, on a standard engine, whose discovered Multi-AZ flag is false, and which passes the production gate. The flag is provider state captured from the RDS DescribeDBInstances API. When it is present and true, the instance is already protected and the rule is silent. Note the asymmetry: an absent flag fails to suppress (the instance may genuinely be Single-AZ), but the evidence shown with the finding only asserts “Multi-AZ: disabled” when the flag was actually observed as false.

What this finding is worth

Nothing, in dollars. This is a compliance finding, and the fix adds spend rather than removing it. What you buy with the roughly 2x instance cost is surviving an availability-zone failure with an automatic failover instead of an outage, plus maintenance events that become failovers rather than downtime.

Enumerate your Single-AZ estate

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

Cross off anything genuinely non-production; what remains is the exposure list.

Enabling it

Modify the instance in the RDS console and enable Multi-AZ deployment, applying during the next maintenance window (or immediately if the exposure justifies it). Budget for the cost delta first. The production gate exists because this control is only worth 2x on databases whose downtime costs more than the standby does.