AWSCostAWS cost · RDS Multi-AZ
Multi-AZ is doubling your RDS bill - do you need it?
Multi-AZ is the checkbox that feels responsible to tick. It promises automatic failover, and turning it on takes one click, so it gets turned on - often across every environment, including the ones that will never need it. What that click actually does is start a second full instance running around the clock, doubling the bill for that database. On production, that is a fair price for staying up. On a staging database that three people touch during office hours, it is paying twice for a guarantee nobody will ever collect on.
Multi-AZ runs a standby replica in a second AZ around the clock, so it roughly doubles the instance cost. It buys automatic failover - essential for production, wasted on dev and staging. Switch non-production databases to Single-AZ and you halve their instance cost with no impact on the data.
Where is Multi-AZ worth it, and where is it waste?
Match the availability you pay for to what the environment actually needs:
| Environment | Verdict | Why |
|---|---|---|
| Production, customer-facing | Keep Multi-AZ | failover is worth the second instance |
| Staging / QA | Single-AZ | an hour of downtime is not a crisis |
| Dev / demo | Single-AZ | nobody is paged if it blips |
| Internal tooling | Usually Single-AZ | unless it is genuinely critical |
Why does Multi-AZ end up everywhere?
Because it is a single reassuring checkbox, and the cost of ticking it is invisible at the moment you tick it. A template gets copied from production to staging, Multi-AZ and all. Nobody sets out to run a highly-available demo database; the setting just carried over and nobody revisited it. It is the same pattern behind most AWS waste - a sensible default in one place, quietly billing double in another.
How do I find and fix it?
List every database with its Multi-AZ flag, then look for the non-production ones set to true - those are the double charges to unwind. Switching a non-production database back to Single-AZ removes the standby and halves its instance cost:
# every database and whether Multi-AZ is on
aws rds describe-db-instances \
--query 'DBInstances[].{DB:DBInstanceIdentifier,Class:DBInstanceClass,MultiAZ:MultiAZ}' \
--output table
# switch a non-production database to Single-AZ (halves the instance cost)
aws rds modify-db-instance \
--db-instance-identifier my-staging-db --no-multi-az --apply-immediatelySingle-AZ pairs with the other non-production levers: scheduling the database off after hours and right-sizing the instance it runs on.
Want to know which of your databases are paying double for failover they do not need? Connect your account read-only and see what it is wasting, in real dollars.
The role can only read - Get, Describe, List, nothing else. Read the exact permissions before you deploy it, and delete the stack whenever you want.
Frequently asked questions
Why does Multi-AZ double my RDS cost?+
Multi-AZ runs a full standby replica in a second Availability Zone, kept in sync and ready to take over. That standby is a second instance running around the clock, so you pay roughly twice the instance cost of a Single-AZ database - for the same usable database.
What does RDS Multi-AZ actually give me?+
Automatic failover. If the primary instance or its AZ fails, RDS promotes the standby with no manual intervention, usually within a minute or two. It is a high-availability feature, not a performance or backup feature - the standby does not serve reads in the classic Multi-AZ setup.
Do I need Multi-AZ for dev and staging?+
Almost never. Multi-AZ protects against an AZ outage taking your database down. For dev, staging, QA, and demo environments, a short outage is an inconvenience, not an incident - so paying double for automatic failover is waste. Single-AZ is the right default for non-production.
How do I switch a database from Multi-AZ to Single-AZ?+
Modify the instance and set it to Single-AZ. On a non-production database you can apply it immediately. The change removes the standby replica and halves the instance cost, with no impact on the data or the connection endpoint.
Is switching to Single-AZ risky?+
For production, yes - you lose automatic failover, so only do it if you have another HA strategy. For non-production it is low risk: the trade is that an AZ failure could mean a short manual recovery, which dev and staging can absorb. Match the availability you pay for to how much the environment actually needs.
Does Multi-AZ improve performance?+
No, not in the standard configuration - the standby is passive and does not serve traffic, so it adds no read capacity. If you need read scaling, that is read replicas, which are a different feature. Paying for Multi-AZ expecting a speed boost is paying double for nothing.
Related cost breakdowns
Why Athena is expensive: $5 per TB scanned
Athena charges $5 per terabyte scanned, so an unpartitioned CSV table can cost 10 to 100 times more than the same data as partitioned Parquet. Here is where the scan cost comes from and how to cut it.
Why RDS looks expensive - and how to right-size the instance
A low-traffic MySQL database runs fine on db.t4g.small (~$23/month), not the $100+ tier an AI often quotes. Size RDS to your working set, not your row count.
Your dev and staging RDS databases are billing 24/7
A dev database used 8 hours a day still bills for 24. Scheduling stop/start on non-production RDS saves 50 to 80%. Here is how to stop paying for databases nobody is using at night.
The RDS costs hiding in storage and backups
RDS storage and backups bill separately from the instance - over-provisioned gp2 disk and backups beyond 100% of your DB size add up quietly. Here is how to find and trim them.