Multi-AZ standbys running on dev, test and staging RDS instances

A standby you pay for but cannot query

In a Multi-AZ DB instance deployment, RDS keeps a synchronous standby replica in a second Availability Zone. AWS’s Multi-AZ documentation is clear that the standby cannot serve read traffic: it exists only to take over on failure or during maintenance. The RDS pricing pages list Multi-AZ deployments as their own price tier, separate from Single-AZ. On a production database that insurance is worth paying for. On a development or QA copy that can be rebuilt from a snapshot, it rarely is.

Finding Multi-AZ instances that are not production

aws rds describe-db-instances \
  --query 'DBInstances[?MultiAZ && DBClusterIdentifier==null].[DBInstanceIdentifier,DBInstanceClass,SecondaryAvailabilityZone]' \
  --output table

aws rds describe-reserved-db-instances \
  --query 'ReservedDBInstances[?State==`active`].[DBInstanceClass,DBInstanceCount,MultiAZ]'

Match the first list against your naming and tagging conventions, and the second against any reservations that already cover the instances.

Conditions for a finding

• The instance is available and RDS reports MultiAZ as true for it.
• It is classified as non-production by name (dev, test, qa, staging and similar) or by a dev or test environment tag. An explicit production environment tag always wins over the name.
• It is a standalone instance, not a member of a Multi-AZ DB cluster.
• It is billed on demand. Coverage by a Reserved Instance or Savings Plan suppresses the finding.

Cases ZopNight deliberately skips

Multi-AZ DB clusters use two readable standbys and are priced at the cluster level, so the half-the-instance model does not apply and cluster members are excluded. A reserved or Savings Plan instance keeps billing the commitment whether Multi-AZ is on or off, so turning it off saves nothing until the commitment ends. If ZopNight cannot price the instance, or cannot break its cost into the components Multi-AZ affects, there is no finding rather than a guess.

Half of the doubled components

standby basis = monthly compute + storage + provisioned IOPS + throughput
saving        = standby basis x 0.5
capped at monthly instance cost x 0.5

Backup storage and data transfer are left out because a second Availability Zone does not double them. The cap matters for organisations on discounted rates, where half the list-price basis could exceed half of what is actually billed.

Turning off Multi-AZ

1. Confirm with the owners that the database is non-production and that a failover test does not depend on the standby.
2. Apply the change. RDS lists it as causing no downtime, with a possible performance impact: aws rds modify-db-instance --db-instance-identifier staging-api-db --no-multi-az --apply-immediately
3. Check the next bill: the instance-hour and storage lines for the deployment should drop to the Single-AZ rates.