RDS per-snapshot billing: the line item is a share, not a price tag

Published November 7, 2026

RDS snapshots each carrying their own billing line under a shared free allowance

RDS snapshots now get their own line on your bill, and the number on each line is not what that snapshot costs you. In the example below, a snapshot billed at $7.92 a month saves $23.75 when you delete it. The rate didn’t change. What changed is where the charge lands, and the arithmetic AWS uses to split it.

On November 2, AWS moved RDS snapshot charges off the database instance and onto each snapshot’s own ARN, the resource ID AWS gives every snapshot. Cost Explorer and the Cost and Usage Report (CUR) now show one line per snapshot. If you clean up backups by sorting that list, or run a budget against a database’s ARN, this is worth an hour of your week.

The rate is the same $0.095; only the label moved

Nothing on the price list changed. Backup storage beyond the free allowance (the dataset’s RDS:ChargedBackupUsage rows) costs the same per GB-month it did in October, and it still varies by region. A sample, from data/processed/rds_pricing.csv:

RegionCharged backup, $/GB‑month
Asia Pacific (Taipei) (ap-east-2)$0.086
EU (Stockholm) (eu-north-1)$0.09
US East (N. Virginia) (us-east-1)$0.095
EU (London) (eu-west-2)$0.10
EU (Frankfurt) (eu-central-1)$0.103
Canada (Central) (ca-central-1)$0.105
Africa (Cape Town) (af-south-1)$0.113
Europe (Zurich) (eu-central-2)$0.1133

Nineteen of the 36 priced regions sit at $0.095, including all four commercial US regions. The rate is the same for MySQL, PostgreSQL, MariaDB, Oracle, SQL Server and Db2. Only the region moves it.

The free allowance is a coupon split across every snapshot

Every account gets free backup storage equal to its total provisioned RDS storage, per region. The RDS docs say that allowance is not subtracted from one snapshot. It’s applied as the same percentage discount on all of them.

Picture a table at a restaurant with a $50 gift card. The server doesn’t put the card on one plate. Every receipt gets the same percentage off, so each diner sees a smaller number. But when one diner stays home, the table saves that diner’s full menu price, not the discounted share printed on their receipt.

Here’s a single us-east-1 account with 500 GB of provisioned storage across its databases, so 500 GB of backup is free:

SnapshotSizeShare after 66.7% allowanceLine item at $0.095
prod-db automated backups300 GB100 GB$9.50
prod-db manual, pre-upgrade200 GB66.7 GB$6.33
analytics-db final snapshot (instance deleted)250 GB83.3 GB$7.92
Total750 GB250 GB$23.75

The math, once: 750 GB stored, 500 GB free, so 500 ÷ 750 = 66.7% comes off every snapshot. What’s left on each is billed at $0.095.

Now delete the analytics-db snapshot. Storage drops to 500 GB, exactly the allowance, and the bill goes to $0. The line said $7.92. Deleting it saved $23.75, three times the printed figure.

The rule underneath: while you’re over the allowance, deleting a snapshot saves its full size times the rate, up to the amount you’re over. The line item shows the snapshot’s share after the discount, which is always smaller. Sort by the line item and you’ll rank your cleanup wrong.

It cuts the other way, too. Drop the pre-upgrade snapshot instead and the bill falls from $23.75 to $4.75, a $19.00 saving from a $6.33 line. Once the account is under the allowance, the next snapshot you delete saves nothing at all, whatever its line said last month.

Your budget for prod-db just got cheaper, and nothing happened

The second change is quieter and more likely to cause a meeting. Before November 2, snapshot charges were rolled up under the database instance. Now they carry the snapshot’s ARN in the CUR’s ResourceId field.

Any rule that matched the instance ARN has stopped matching snapshot spend. The RDS docs name the usual suspects: AWS Cost Categories, AWS Budgets filters, and chargeback jobs that read ResourceId. In the example, the prod-db budget loses $15.83 a month of snapshot charges overnight. Nobody tuned anything.

The money moved to two new resource IDs your rules don’t know about. If a team’s database spend dipped in early November, check this before you send congratulations.

The fix AWS points to is tags. The announcement points to cost allocation tags on snapshots: tag each one with its source instance, then group by tag instead of ARN. Expect the per-instance totals to differ from the old ones even then. The allowance is spread across every snapshot in the region, so a tag-based breakdown hands each database a different slice of the discount than the old instance-level rollup did. The account total is unchanged.

The orphaned snapshot finally has a name

The analytics-db row is the one this launch is really for. Its instance was deleted, but its final snapshot kept costing money. Under the new scheme, charges for snapshots whose source instance is gone are billed to the snapshot’s own ARN, and the docs make a point of saying there are no longer any line items with a blank ResourceId. Our read: that’s where those charges used to sit, on a row nobody owned.

A deleted database is the easiest money in this whole list to find. It now shows up with a name attached, so search for it first.

Edge cases worth a line in your runbook

What to do

  1. Audit rules that match instance ARNs. Cost Categories, Budgets filters and any chargeback query that reads ResourceId now miss snapshot spend.
  2. Tag snapshots with their source instance, and activate the tag as a cost allocation tag, so per-database reporting survives the instance being deleted.
  3. Rank cleanup by size, not by line item. While you’re over the allowance, each deleted GB saves the full regional rate. Once you’re under it, more deletion saves nothing.
  4. Look for snapshots whose instance is gone. They’re the ones with no owner, no retention period and, until this month, no name on the bill.