🚀 Ready to transform your cloud infrastructure? Get Started →

Amazon RDS per snapshot billing guide showing individual database snapshot costs broken out with cost allocation tags

Amazon RDS Per Snapshot Billing: Find and Cut Hidden Backup Storage Costs

On 2 November 2026, AWS announced that Amazon RDS now supports per snapshot billing. Until now, RDS snapshot charges were rolled up at the DB instance level in the AWS Cost and Usage Report (CUR) and Cost Explorer. You could see that a database’s backups were expensive, but not which snapshot was driving the cost.

Amazon RDS per snapshot billing changes that. Every snapshot now gets its own line item, and you can use cost allocation tags to see exactly what each one costs. It is turned on by default for all RDS snapshots at no extra charge, in all commercial AWS Regions and the AWS GovCloud (US) Regions. This guide covers what changed, what it can break, and how to use it to cut backup spend.

What Changed With Amazon RDS Per Snapshot Billing?

The pricing itself has not changed. Only the way charges are attributed and presented is different. According to the RDS backup storage documentation:

  • Snapshot storage charges appear at the individual snapshot level in Cost Explorer and the CUR.
  • In the CUR ResourceId field, each DB snapshot shows its RDS snapshot ARN, and each DB cluster snapshot shows its cluster snapshot ARN.
  • Snapshots whose source DB instance or Multi-AZ DB cluster has been deleted are billed to their own snapshot ARN. There are no line items with a blank ResourceId.
  • Cross-Region and cross-account snapshot copies are billed to the snapshot ARN in the destination account or Region.

The RDS billing documentation confirms that backup storage covers both automated backups and manual snapshots, is billed per GiB-month, and grows when you lengthen the retention period or take more snapshots.

Why the New Detail Matters

Snapshot sprawl is one of the quietest sources of waste on AWS. Manual snapshots are not deleted when you delete a DB instance, and final snapshots stay too. A “just in case” snapshot taken before an upgrade can sit on the bill for months.

Now each of those snapshots shows up by ARN, so finance can charge costs back correctly and engineers can see which snapshots are worth keeping.

How the free backup allowance works now

RDS gives you free backup storage equal to 100 percent of the total provisioned database storage in your account, for each Region. AWS applies that allowance as a percentage discount across all snapshots, not as a fixed amount taken off one snapshot. The documentation gives this example: with 100 GB of provisioned storage and two snapshots of 50 GB and 75 GB (125 GB in total), 80 percent of each snapshot is free. You are billed for 10 GB on the first and 15 GB on the second, or 25 GB in total.

The account total is the same as before. However, AWS notes that per-instance totals in a tag-based breakdown will not match the per-instance numbers you saw before, so warn your finance team before the first month-end comparison.

Check What This Breaks in Your Cost Reports

This is the step most teams will miss. AWS warns that any rule matching a DB instance ARN in the ResourceId field no longer matches snapshot charges. That includes:

  • AWS Cost Categories rules
  • AWS Budgets filters
  • Chargeback or showback jobs that read the CUR ResourceId field

If you used these to assign RDS backup costs, those charges may now go uncategorised. Update the rules to match RDS snapshot ARNs, or move to cost allocation tags on the snapshots themselves, which is the more durable option.

How to Set Up Snapshot Cost Allocation

1. Turn on copy tags to snapshots

The RDS tagging guide gives two ways to attribute snapshot charges: tag each snapshot directly, or enable the copy-tags-to-snapshot option on the DB instance so its tags flow to new snapshots. Enable it on every instance:

aws rds modify-db-instance \
  --db-instance-identifier orders-prod \
  --copy-tags-to-snapshot \
  --apply-immediately

This only applies to snapshots created after you turn it on. There are two more catches. If you pass any tags with create-db-snapshot, RDS does not copy the instance’s tags to that snapshot. And tags cannot be copied when you copy a snapshot across accounts.

2. Tag your existing snapshots

Existing snapshots need tags added directly. List your manual snapshots, then tag each one with its source instance and owner:

aws rds describe-db-snapshots --snapshot-type manual \
  --query "DBSnapshots[].[DBSnapshotArn,DBInstanceIdentifier,SnapshotCreateTime]" \
  --output table

aws rds add-tags-to-resource \
  --resource-name arn:aws:rds:ap-south-1:123456789012:snapshot:orders-pre-upgrade \
  --tags Key=source-db,Value=orders-prod Key=cost-center,Value=payments

Do this soon. Cost allocation tags are not applied retroactively, so any storage used before you tag a snapshot stays unattributed on your bill. The good news is that tags keep working on a snapshot even after its source DB instance is deleted. For automated backups, RDS also supports tagging the automated backup resource with --tag-specifications using ResourceType=auto-backup.

3. Activate the tag keys in Billing

Tags only appear in billing reports after you activate them. Per the AWS Billing guide, open the Billing and Cost Management console, choose Cost allocation tags, select keys such as source-db and cost-center, and choose Activate. New tag keys can take up to 24 hours to appear on that page and up to 24 more hours to activate. In AWS Organizations, only the management account can manage cost allocation tags, as noted in the cost allocation tags overview.

4. Find the expensive snapshots

Once data flows, group RDS costs by your source-db tag in Cost Explorer, or query the CUR in Amazon Athena for line items whose ResourceId is a snapshot ARN, sorted by cost. Look for three patterns:

  • Orphans: snapshots whose source database no longer exists.
  • Stale copies: cross-Region or cross-account copies kept long after a migration or DR test.
  • Duplicates: several manual snapshots of the same database taken days apart.

Because the free allowance is spread as a percentage, the cost shown against an orphan understates what you save by deleting it, as long as your snapshot storage stays above the allowance. The billed amount is simply total snapshot storage minus total provisioned storage, so every gigabyte you remove comes straight off that figure.

5. Set a retention policy

Before deleting anything, confirm with the owner and with your compliance needs. Then replace ad-hoc manual snapshots with a policy, such as AWS Backup plans with defined retention, so the problem does not return. If you want help building that kind of policy across accounts, our AWS cost optimization services team runs exactly these reviews, and our cloud consulting and architecture practice can design tagging standards that hold up at scale.

FAQ

Does Amazon RDS per snapshot billing cost extra?

No. It is enabled by default on all RDS snapshots at no additional charge. Only how charges are attributed changes.

Do I need to turn it on?

No. It is already on. To group snapshot charges by team, project or source database, you still need to tag your snapshots and activate those tag keys as cost allocation tags.

Why do my per-database RDS costs look different this month?

The free backup allowance is now applied as the same percentage discount across every snapshot in the account and Region. Per-instance totals in a tag-based view therefore won’t match the old per-instance view, even though the account total is unchanged.

Will old snapshot charges be assigned to my new tags?

No. Cost allocation tags are not retroactive. Usage from before you tag a snapshot stays unattributed.

Turn Snapshot Visibility Into Real Savings

Shanav Technologies helps startups and growing businesses reduce their AWS bills, from tagging strategy to backup retention. If you want a clear view of what your RDS snapshots cost and which ones you can safely remove, talk to our team and we will help you put Amazon RDS per snapshot billing to work.