AWS snapshot cost across RDS, Aurora, Redshift and EBS

TL;DR. AWS snapshot cost is four list prices in US East (RDS $0.095 per GB-month, Aurora $0.021, Redshift $0.023, EBS $0.05) and two ways of counting bytes: RDS and EBS snapshots are incremental, Aurora bills each manual snapshot at full volume size. The waste sits in snapshots whose database is gone. On RDS, deleting an instance shrinks the free backup allowance, so its snapshots can go from free to billed overnight, and the bill then puts less on them than deleting them saves. A hypothetical estate with five retired databases pays $287.66 a month for their leftovers. Below: the rates, the mechanisms, the CLI checks that find orphans by source ID, and the Cost and Usage Report query that prices them.

AWS snapshot cost is easy to look up per service and hard to see across an account: every data service bills its backups under its own rules and usage type. Price pages answer "how much per GB", not the question a cost review needs: which snapshots belong to a database that no longer exists, and who owns them.

Below: AWS's list rates (read October 28, 2026), one worked month for a hypothetical estate, and how to list and price the orphans. It is a worked model; no AWS account was measured.

Four services, four rates, two ways of counting bytes

Sources: the AWS Price List API offer files for Amazon RDS (RDS and Aurora, effective October 1, 2026) and Amazon Redshift, and the EBS guide to archive pricing, which lists "the standard rate for snapshots of $0.05 per GB-month".

Per GB, RDS backup costs 1.9 times EBS and 4.5 times Aurora. Aurora has the lowest rate outside the EBS archive tier and is often not the cheapest per snapshot, for a reason covered below. For the rest of an RDS bill, see RDS pricing.

Deleting a database makes its snapshots cost more

RDS gives "a free amount of backup storage equal to 100 percent of the total provisioned database storage in your AWS account for each Region". The allowance belongs to the live instances. When you delete one, "RDS doesn't delete manual DB snapshots", and its final snapshot stays too. The storage stays; its allowance leaves.

Consider an account with five instances and 1,800 GB provisioned. Their backups take 1,500 GB, all free. Three instances are retired with final snapshots kept, 800 GB between them. The allowance drops to 1,000 GB, total backup storage is still 1,500 GB, and 500 GB is now billed: $47.50 a month for snapshots that cost nothing the day before.

The bill then hides how much the orphans cost. RDS applies the allowance "as a percentage discount that is spread across all of your snapshots", here 1,000 / 1,500 = 66.7% off every snapshot. The three orphans show $25.33 in the Cost and Usage Report, and the live backups show $22.17 that would be free on their own. Deleting the orphans saves the full $47.50, almost twice what the bill attributes to them. Sorting snapshot ARNs by cost understates the waste whenever the allowance is in play.

Aurora bills every manual snapshot at full volume size

Aurora's continuous backup is incremental. Its manual snapshots are not: "Snapshots are full backups, not incremental", and "The size of each snapshot is the size of the cluster volume at the time you take the snapshot." Snapshots inside the backup retention period are free; AWS meters "all other backups and snapshots (including those from deleted clusters)".

Three monthly snapshots of a 400 GB cluster, once past the retention period or after the cluster is deleted, bill 1,200 GB, $25.20 a month at $0.021, even if almost nothing changed between them. On RDS the same three would bill the first full copy plus the changed blocks. Aurora's low rate pays for itself when you keep few snapshots; a weekly manual snapshot kept for a year is about 47 full copies outside a 35-day retention period.

Deleting an EBS snapshot can free less than its size

EBS snapshots store changed blocks, and later snapshots reference earlier ones. AWS's deletion guide: "When you delete a snapshot, only the data that is referenced exclusively by that snapshot is removed." If a later snapshot uses its blocks, "costs associated with the referenced data are allocated to the later snapshot".

Deleting the oldest snapshot of a live volume often saves little; deleting every snapshot of a terminated volume saves all of it. The unit of cleanup is the chain of a dead source, not the single old snapshot. Two EBS details keep deleted data billed: snapshots in the Recycle Bin "are billed at the same rate as regular snapshots", and the root device snapshot of a registered AMI cannot be deleted until the AMI is deregistered.

Five ways the snapshot line grows without anyone deciding

1. Manual and final snapshots outlive their database on RDS and Aurora. On Redshift, "manual snapshots are retained indefinitely, even after you delete your cluster", unless someone set a retention period.
2. Retained automated backups. If you keep them at deletion, RDS stores them for the full retention period, and "Retained automated backups and manual snapshots incur billing charges until they're deleted". Backups replicated to another Region are kept even if you did not ask.
3. Cross-Region copies. A copied RDS snapshot becomes "a manual DB snapshot that is retained in that AWS Region", and the first EBS copy into a Region is a "full (non-incremental) copy". The DR copy is billed in a Region nobody reviews.
4. Copies across accounts lose their tags. RDS "can't copy tags when copying a DB snapshot across accounts", and on EBS "User-defined tags are not copied from the source snapshot to the snapshot copy" at all.
5. Retention set once. A backup plan written for a launch outlives the system's owner, and nothing on the bill flags it.

A worked month: $287.66 for databases that no longer exist

Consider a hypothetical account in US East that retired five databases over two years, at list price:

That is $3,451.92 a year, and none of these snapshots expires. The Redshift row assumes manual snapshots kept at the default indefinite retention (a ManualSnapshotRetentionPeriod of -1, which means "retained indefinitely"). Redshift's pricing page says RA3 manual snapshots "are billed as backup storage at standard Amazon S3 rates" and "Snapshots are billed until they expire or are deleted, including when the cluster is paused or deleted."

Find orphaned snapshots by source resource ID, not by name

An orphan is a snapshot whose source no longer exists. Match on the immutable resource ID where the service has one: a new instance reusing an old name gets a new ID, so a name match would hide the orphan.

RDS and Aurora

DbiResourceId is "The identifier for the source DB instance, which can't be changed and which is unique to an AWS Region". Run this in each Region (AWS CLI v2):

# Live instances in this Region
aws rds describe-db-instances \
  --query 'DBInstances[].DbiResourceId' --output text | tr '\t' '\n' | sort > live.txt

# Manual snapshots and the instance they came from
aws rds describe-db-snapshots --snapshot-type manual \
  --query 'DBSnapshots[].[DbiResourceId,DBSnapshotArn,AllocatedStorage,SnapshotCreateTime]' \
  --output text | sort > snaps.txt

# Snapshots whose source instance is gone
join -v1 snaps.txt live.txt

# Automated backups kept after their instance was deleted
aws rds describe-db-instance-automated-backups \
  --query "DBInstanceAutomatedBackups[?Status=='retained'].[DBInstanceIdentifier,DbiResourceId,AllocatedStorage]" \
  --output table

For Aurora, the same join uses DbClusterResourceId from describe-db-clusters and describe-db-cluster-snapshots --snapshot-type manual. AllocatedStorage is the source's size in GiB, not the billed size; the bill comes from the query below.

Redshift

Redshift snapshots carry ClusterIdentifier and ClusterCreateTime, not a resource ID. The join below catches clusters whose name is gone:

aws redshift describe-clusters \
  --query 'Clusters[].ClusterIdentifier' --output text | tr '\t' '\n' | sort > live_rs.txt
aws redshift describe-cluster-snapshots --snapshot-type manual \
  --query 'Snapshots[].[ClusterIdentifier,SnapshotIdentifier,TotalBackupSizeInMegaBytes,ManualSnapshotRetentionPeriod,ClusterCreateTime]' \
  --output text | sort > snaps_rs.txt
join -v1 snaps_rs.txt live_rs.txt

For a name in both lists, compare the snapshot's ClusterCreateTime with the live cluster's (describe-clusters --query 'Clusters[].[ClusterIdentifier,ClusterCreateTime]'): a different time means the cluster was recreated and the snapshot belongs to the old one.

EBS

aws ec2 describe-volumes --query 'Volumes[].VolumeId' --output text | tr '\t' '\n' | sort > live_vol.txt
aws ec2 describe-snapshots --owner-ids self \
  --query 'Snapshots[].[VolumeId,SnapshotId,VolumeSize,StartTime,StorageTier]' \
  --output text | sort > snaps_ebs.txt
join -v1 snaps_ebs.txt live_vol.txt

Two exclusions before you call an EBS snapshot orphaned. Copies carry "an arbitrary volume ID that you should not use for any purpose", such as vol-ffffffff; trace them through their description or tags instead. And snapshots used by your AMIs (aws ec2 describe-images --owners self) belong to the image, not the volume.

Price each orphan, then tag what you keep

RDS states that snapshot storage "charges are attributed to each snapshot individually", where "the ResourceId field shows the snapshot ARN instead of the DB instance ARN". With resource IDs turned on in a CUR 2.0 export, one Athena query prices every snapshot in the account (cur2 stands for your export's table):

SELECT line_item_resource_id,
       line_item_usage_type,
       SUM(line_item_usage_amount)   AS gb_months,
       SUM(line_item_unblended_cost) AS cost
FROM cur2
WHERE date_trunc('month', line_item_usage_start_date) = TIMESTAMP '2026-09-01 00:00:00'
  AND (line_item_usage_type LIKE '%Backup%'
       OR line_item_usage_type LIKE '%Snapshot%')
GROUP BY 1, 2
ORDER BY cost DESC;

Usage type names differ by service and Region, which is why the filter is loose; check the distinct values in your own export first. Join the result to the orphan lists above on the ARN or snapshot ID. For RDS, remember the previous section: the per-snapshot cost understates the saving while the allowance is shared.

For ownership, turn on CopyTagsToSnapshot on every instance and Aurora cluster (on Aurora it "is managed by the DB cluster"), pass --copy-tags when you copy, and tag existing snapshots directly. RDS warns that cost allocation tags "aren't applied retroactively", so a tag added today does not explain last month's bill. The RDS cost optimization guide covers activating the tag keys.

Archive EBS snapshots only when a quarter of their data is unique

Archive costs a quarter of standard ($0.0125 against $0.05), but it stores "full copies of your block data", while the standard tier only charges a snapshot for its unique blocks. Archiving saves money only when the unique share is above 25% (our arithmetic: 0.0125 / 0.05).

• A 500 GB snapshot with 100 GB unique costs $5.00 a month in standard and $6.25 archived. Archiving loses money.
• The last snapshot of a terminated volume, 500 GB all unique, costs $25.00 in standard and $6.25 archived. Archiving saves $18.75 a month.

Archive only what you will keep 90 days or more: an early deletion is billed "a pro-rated charge equal to the archive tier storage charge for the remaining days", and a restore costs $0.03 per GB.

The objection: snapshots are cheap and deleting backups is risky

The strongest case against a cleanup: $287.66 a month is noise next to compute, and a deleted backup cannot come back. For a small estate where one person remembers every database, a yearly review and a lifecycle policy in AWS Backup or Data Lifecycle Manager are enough.

The risk argument cuts the other way once nobody owns the snapshot. A backup no one can name is a backup no one will restore, and it may hold personal data past its retention date. Deleting is a decision about a database, and it needs the database's owner, which is why the method above ends with tags and owners rather than a script that deletes. Where a legal hold applies, archive or set a retention period instead of keeping it forever.

What this does not cover

• List prices, US East, read October 28, 2026. Other Regions differ, and private pricing changes every row.
• The sizes are assumptions. No AWS account was measured, and real snapshot sizes depend on change rates.
• Not covered: AWS Backup vault charges beyond the snapshot storage, RDS snapshot export to S3, DynamoDB, ElastiCache, DocumentDB and Neptune backups, and Redshift Serverless recovery points.

Resources that outlive their owner also fill warehouses, dashboards and dev environments; see cloud waste in data infrastructure.

Where Datapace fits

Snapshots bill under their own IDs, in four services and every Region, and the fact that decides whether to keep one (does its database still exist, and who owned it) is on none of those lines. Datapace is building one map of your data estate (databases, warehouses, pipelines and what consumes them) with usage and cost attached, and agents that propose changes as pull requests your team reviews and merges. If your RDS backup line is the one growing, start with RDS pricing to see where it sits in the whole bill.

Sources

1. AWS, Price List API offer file for Amazon RDS, US East, published October 26, 2026, read October 28, 2026 (RDS and Aurora backup storage rates).
2. AWS, Price List API offer file for Amazon Redshift, US East, read October 28, 2026, and Amazon Redshift pricing.
3. AWS, Amazon EBS pricing, Pricing and billing for archiving EBS snapshots, Delete an Amazon EBS snapshot, Copy an Amazon EBS snapshot and Recycle Bin.
4. AWS, Introduction to backups, Deleting a DB instance, Copying a DB snapshot, Tagging Amazon RDS resources and DB instance billing.
5. AWS, Understanding Amazon Aurora backup storage usage and Amazon Aurora pricing.
6. AWS, Working with snapshots in Amazon Redshift.
7. AWS API references: DBSnapshot, CreateDBInstance, Redshift Snapshot and EC2 Snapshot.
8. AWS, CUR 2.0 line item columns.