# RDS Instance Not Using Multi-AZ

> ZopNight raises this finding only for running, standard-engine RDS instances (MySQL, MariaDB, PostgreSQL, SQL Server, Oracle) whose discovered Multi-AZ flag is false and which look like production. Aurora, DocumentDB and Neptune are excluded because their HA lives at the cluster layer, and dev/test databases are suppressed because Multi-AZ costs roughly 2x.

Source: https://zop.dev/integrations/aws/recommendations/rds-instance-not-using-multi-az
Updated: 2026-08-19

---

## 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](https://aws.amazon.com/rds/pricing/). 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

```bash
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.