Services Work Pricing Blog About Book a free call →
Blog

RDS per-snapshot billing: what changes in your AWS bill

AWS now bills each Amazon RDS snapshot on its own line. Here is what changed, which cost reports can break, and how to tag snapshots this week.

6 min readCloudCloud cost

On November 2, 2026, AWS announced per-snapshot billing for Amazon RDS: snapshot storage charges now show up per snapshot instead of being rolled up per database instance. Prices do not change, and the feature is on by default. What can change is your reporting. Any budget, cost category or chargeback script that matched a DB instance in the ResourceId field of the Cost and Usage Report (CUR) no longer matches snapshot charges, according to the RDS User Guide. This post covers what changed, who should care, and what to check first.

What did AWS announce?

According to the announcement, RDS snapshot charges used to be "aggregated at the database instance level" in the Cost and Usage Report and Cost Explorer. You could not see what one snapshot cost. Now you can, and you can put cost allocation tags on snapshots to group them.

The announcement and the User Guide give these facts (as of November 2026):

  • It is enabled by default on all RDS snapshots, at no additional charge.
  • It covers all RDS engines, in all commercial AWS Regions and the AWS GovCloud (US) Regions.
  • The AWS backup documentation says that "your snapshot pricing and overall charges remain the same; only how the charges are attributed and presented changes."

What actually changed compared with before?

Before, a snapshot's storage cost was folded into a line for its source instance. Now each snapshot appears as its own line item. In the CUR, the ResourceId field holds the snapshot's ARN (its Amazon Resource Name, the unique ID of the resource). Charges for snapshots whose source instance was deleted are attributed to the snapshot ARN too, so there are no lines with a blank ResourceId. Charges for cross-Region or cross-account snapshots go to the snapshot ARN in the destination. The same applies to DB cluster snapshots, which appear under the cluster snapshot ARN.

The documentation also carries an important warning: any rule that attributes snapshot charges by matching a DB instance ARN in ResourceId no longer matches those charges. It names AWS Cost Categories, AWS Budgets filters and chargeback jobs that read the CUR. AWS says to update them to match RDS snapshot ARNs, or to apply cost allocation tags to your snapshots.

Who should care, and who can ignore it?

Pay attention if you:

  • Run chargeback or showback by product, tenant or team, built on CUR ResourceId.
  • Use AWS Budgets or Cost Categories that filter on DB instance ARNs.
  • Keep many manual snapshots, copies in other Regions, or snapshots of deleted databases.
  • Are preparing for an audit or a FinOps review and need to explain what each backup costs.

You can mostly ignore it if your cost reporting works at the account or service level and nobody slices RDS cost by instance. Your total bill is the same. The per-instance numbers you see in a tag-based view can still differ from the old ones, as explained below.

Why do per-instance totals look different?

AWS gives you free backup storage equal to 100 percent of the total provisioned database storage in your account, for each Region. The documentation explains that this allowance is applied as the same percentage discount to every snapshot in that account and Region, not subtracted from one snapshot.

Here is the documentation's own 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 10 GB and 15 GB, for 25 GB in total.

So a tag-based breakdown per instance will not match what you used to see per instance, even though the account total is unchanged. Tell your finance partner before the first month-end comparison, not after.

How do you tag snapshots so reports keep working?

The RDS tagging guide describes two ways to attribute snapshot charges:

  1. Add tags directly to each snapshot.
  2. Turn on the copy-tags-to-snapshot option on a DB instance, so snapshots it creates inherit its tags. This applies only to snapshots created after you enable it, so existing ones need tags added directly.

Two limits matter. Cost allocation tags are not applied retroactively: usage before a tag is assigned stays unattributed. And copying tags across accounts is not supported.

On the billing side, the AWS Billing guide says user-defined tags must be activated before they appear in Cost Explorer or cost allocation reports, and that tags can take up to 24 hours to appear in the Billing console. Only the management account of an organization (or a standalone account) can use the cost allocation tags manager.

How would a team try this safely this week?

  1. Find what depends on ResourceId. Search your Budgets, Cost Categories, Athena queries on the CUR and chargeback scripts for DB instance ARNs.
  2. Pick tag keys. Reuse the keys you already use for instances, such as product, team and environment. Add one that names the source instance, as AWS suggests, because it still works after the instance is deleted.
  3. Activate the keys in the Billing console and tag existing snapshots now, because tags are not applied retroactively. If a snapshot already carried a tag before you activated it, the management account can request a backfill of the tag's activation for up to twelve months; it only works if the tag was historically on the resource, and it does not create per-snapshot lines for months before the change.
  4. Turn on copy-tags-to-snapshot on instances, so new snapshots are tagged automatically.
  5. Compare one billing period side by side, using the 100 percent allowance example above to explain the differences.
  6. Clean up. Per-snapshot lines make forgotten manual snapshots visible. As of November 2026, the documentation notes that manual snapshots are not deleted when an instance is deleted, and that you can have up to 100 manual snapshots per Region.

What we would check first

We start with the readers of your cost data, not the data: who looks at RDS cost, in which tool, and which filter would break silently. Because AWS says such rules no longer match, we would expect a budget to show a smaller number rather than an error, so we test it. Then we check tag coverage on snapshots, the age of manual snapshots, and whether cross-Region copies are still needed. If you want a second pair of eyes on a cloud cost model, see our services.

General information, not financial advice. AWS announcements, billing behaviour and limits change: confirm them in the current AWS documentation before you change your reporting.