Home › Decoder › Multi-AZUsage - RDS Multi-AZ costs twice the single-AZ hourly price

Multi-AZUsage - RDS Multi-AZ costs twice the single-AZ hourly price

Multi-AZUsage is the RDS charge for a Multi-AZ database instance: the primary plus a standby in a second Availability Zone, billed at twice the single-AZ hourly price for the same instance class.

In your bill the usage type reads: USE1-Multi-AZUsage:*, Multi-AZUsage:*

What it costs

ChargePriceUnit
db.m5.large PostgreSQL, Multi-AZ (Multi-AZUsage:db.m5.large)$0.356per instance-hour
db.m5.large PostgreSQL, Single-AZ (InstanceUsage:db.m5.large)$0.178per instance-hour
db.m5.large MySQL, Multi-AZ (Multi-AZUsage:db.m5.large)$0.342per instance-hour
db.m5.large MySQL, Single-AZ (InstanceUsage:db.m5.large)$0.171per instance-hour

US East (N. Virginia); other regions differ. Checked 2026-11-11. Sources: Amazon RDS pricing, AWS price list file, Amazon RDS offer, us-east-1.

Example with made-up numbers

3 db.m5.large PostgreSQL instances, all Multi-AZ, running the whole month (730 hours)

Each: 730 x $0.356 = $259.88; three: $779.64 on the Multi-AZUsage line. The same instance on Single-AZ: 730 x $0.178 = $129.94

Moving the two staging instances to Single-AZ saves 2 x ($259.88 - $129.94) = $259.88 per month

Typical causes

Created from the production template

The console's production template switches Multi-AZ on; copies of it for staging and test keep the standby they never needed.

Standby left on after a launch

A database made Multi-AZ for a launch or load test and never turned back.

Preview and per-branch databases

Every short-lived environment that clones the production settings pays double for its hours.

Oversized and doubled

A class chosen with headroom for production is paid twice when Multi-AZ is on; the standby also doubles storage and IOPS lines.

Find it in your bill

Have a CUR file queryable in Athena? Paste this and run it:

SELECT date_trunc('month', line_item_usage_start_date) AS month,
       line_item_product_code,
       line_item_usage_type,
       line_item_resource_id,
       SUM(line_item_usage_amount)  AS usage_amount,
       SUM(line_item_unblended_cost) AS cost
FROM your_cur_table
WHERE line_item_product_code = 'AmazonRDS'
  AND (line_item_usage_type LIKE '%Multi-AZUsage:%')
GROUP BY 1, 2, 3, 4
ORDER BY month DESC, cost DESC
LIMIT 50;

Columns used: line_item_usage_start_date, line_item_product_code, line_item_usage_type, line_item_resource_id, line_item_usage_amount, line_item_unblended_cost.

No CUR file? Use Cost Explorer

  1. Open Billing and Cost Management, then Cost Explorer, and set the date range to the last 3 months with Monthly granularity.
  2. Set Group by to Usage type.
  3. In the Filters panel choose Usage type and tick the entries ending in *Multi-AZUsage:db.<class> (the region prefix, such as USE1-, differs by region).
  4. Read the monthly cost per usage type. A line that grows faster than your traffic is the one to chase with the fix below.
  5. To see which resource drives it, query the CUR above; resource IDs appear only if your CUR was set up with resource IDs included, otherwise the resource column is empty.

Column names checked against: docs.aws.amazon.com/cur/latest/userguide/Lineitem-columns.html, docs.aws.amazon.com/cur/latest/userguide/cur-ate-run.html.

The fix, step by step

Verify first

Check these before you change anything: the steps below are suggestions, and only you can see your own configuration.

  • Multi-AZ is what gives automatic failover. Without it, a failed instance or Availability Zone means downtime until RDS restores or replaces it: keep Multi-AZ on anything customers use.
  • Check the instance's role from its tags and connections, not from its name; a database called staging sometimes serves a real customer demo.
  • Check whether a reservation covers the instance before changing it; a reservation sized for Multi-AZ usage may stop matching.
  • Aurora does not appear on this line; Aurora clusters keep replicas in other zones for a different reason and have their own pricing.
  • Do one non-critical instance first, watch the next bill day, then do the rest.

In the console

  1. RDS console > Databases; open an instance and read Multi-AZ on the Configuration tab (Yes or No).
  2. List the Multi-AZ instances next to their environment tag or name: staging, test, dev, demo, preview.
  3. Select an instance that can tolerate a failure and a restore, choose Modify, and under Availability and durability pick the single-instance option.
  4. Apply it in the next maintenance window, or immediately for a throwaway environment.
  5. After the change, check the instance again: Multi-AZ should read No and the next day's Multi-AZUsage hours for it stop.

With the CLI

aws rds describe-db-instances --query 'DBInstances[].[DBInstanceIdentifier,DBInstanceClass,Engine,MultiAZ]' --output table
aws rds describe-db-instances --db-instance-identifier EXAMPLE --query "DBInstances[0].TagList"
aws rds modify-db-instance --db-instance-identifier EXAMPLE --no-multi-az --apply-immediately
aws rds modify-db-instance --db-instance-identifier EXAMPLE --multi-az --apply-immediately

Rollback

Modify the instance back with --multi-az. RDS builds a new standby, which can take time and may slow I/O while it syncs; the database stays available.

Find your RDS Multi-AZ lines in your own bill

Drop in your Cost Explorer or CUR CSV. Billtrim reads it in your browser, finds the Multi-AZUsage lines and shows what the standbys cost per month.

See a sample result

Paste your export: how to export a Cost Explorer CSV or CUR file in two minutes.

Questions people ask

Is Multi-AZ always twice the price?

For the same instance class and engine in the price list, yes: $0.356 against $0.178 for db.m5.large PostgreSQL, $0.342 against $0.171 for MySQL. Storage and IOPS double as well.

Do I lose backups if I turn Multi-AZ off?

No. Automated backups and snapshots are unaffected. You lose the automatic failover to a standby.

Does this line include Aurora?

No. Aurora is billed under its own usage types.

Related

Part of the guide: Reduce your AWS bill as a startup: a checklist for teams with no FinOps person