Amazon RDS Adds Per-Snapshot Billing: Charges Move From Instance Totals to Snapshot ARNs, So Rules Matching Instance ARNs Need Updating

On November 2, 2026, AWS announced that Amazon RDS now supports per-snapshot billing. Until now, snapshot charges were rolled up at the database instance level in the Cost and Usage Report and Cost Explorer, so a team could see what an instance's snapshots cost in total but not what each snapshot cost. AWS says the change is on by default for all RDS snapshots at no additional charge, and that it is available for all RDS engines in all commercial AWS Regions and the AWS GovCloud (US) Regions. The announcement also says teams can use cost allocation tags on snapshots to see exactly how much each one costs.

The announcement is short, and the RDS user guide adds the parts that decide whether this is good news or a broken report. The guide states that snapshot storage charges now appear at the individual snapshot level. In the ResourceId field of the Cost and Usage Report, a DB snapshot shows its RDS snapshot ARN and a DB cluster snapshot shows its cluster snapshot ARN, and each snapshot is its own line item. The guide is explicit that pricing and overall charges stay the same. Only the attribution and presentation change.

The first warning in the guide is about existing rules. Any rule that attributes snapshot charges by matching a DB instance ARN in ResourceId no longer matches those charges. The guide names AWS Cost Categories, AWS Budgets filters and chargeback jobs that read ResourceId. Teams are told to update them to match RDS snapshot ARNs or to apply cost allocation tags to their snapshots. This is the practical point of the change: a dashboard that used to show an instance's backup cost can quietly show less, and a chargeback job can quietly under-bill a team, with no error message.

The second point is how the free allowance works. RDS gives free backup storage equal to 100 percent of the total provisioned database storage in the account for each Region, covering DB snapshots and DB cluster snapshots. The allowance is applied as one percentage discount across all snapshots in that account and Region, not subtracted from any single snapshot. The guide gives an example: with 100 GB of provisioned storage and two snapshots of 50 GB and 75 GB, 80 percent of snapshot storage is free, so each snapshot is billed for 20 percent, which is 10 GB and 15 GB, 25 GB in total. Because of this method, the guide warns that per-instance totals in a tag-based breakdown will not match the per-instance totals seen before, even though the overall charges in the account and Region are unchanged.

Two other attribution rules are worth noting. Charges for snapshots whose source DB instance or Multi-AZ DB cluster has been deleted are attributed to the snapshot or cluster snapshot ARN that incurs them, and there are no line items with a blank ResourceId. Charges for cross-Region or cross-account snapshots are attributed to the snapshot ARN in the destination account or Region. To group snapshot charges by instance, the guide suggests tagging each snapshot with the name of its source instance, and says cost allocation tags keep working after the source instance is deleted.

A sensible response is a short audit. List every Cost Category, Budget filter, report query and chargeback job that reads ResourceId for RDS snapshot spend. Decide on a tagging rule, such as a source-instance tag on every snapshot, and check that new and copied snapshots receive it. Then compare one month of totals by account and Region, not by instance, to confirm that the overall bill did not change. The announcement does not say how tags reach snapshots that already exist or whether a billing-side setting must be switched on, so confirm both in the linked documentation before relying on a report. Nothing in the post claims lower cost: it improves visibility, and it can break existing attribution.