PacketSensei

Old EBS snapshots: How to Find Them and What They Cost

PacketSensei

Old EBS snapshots are incremental backups that accumulate forever because nothing deletes them, including ones behind deregistered AMIs. They are one of the most reliable sources of pure waste in an AWS account, because nothing in the console flags them and nothing fails when they exist — the bill simply stays higher than it needs to be.

This page covers what they cost, the command that lists yours, and — importantly — what to check before deleting anything.

What they are and why they linger

EBS snapshots are incremental: the first captures every allocated block, and subsequent ones store only changed blocks. That makes them cheap individually and expensive collectively, because a daily snapshot schedule with no expiry accumulates indefinitely.

The incremental structure also makes the billing counter-intuitive. Deleting one snapshot from the middle of a chain frees only the blocks no other snapshot references, so removing half your snapshots can free far less than half the storage. There is no way to predict the saving from the console — but there is a way to measure it.

What they cost

At roughly $0.05 per GB-month, a terabyte of accumulated snapshot data is about $50 a month. Organisations that have run automated daily backups for several years without a retention policy routinely find several terabytes.

The category people miss entirely is snapshots behind deregistered AMIs. Deregistering an AMI does not delete its underlying snapshot, so years of superseded golden images leave their storage behind with nothing pointing at it.

Finding yours

# Your own snapshots, oldest first.
aws ec2 describe-snapshots --owner-ids self \
  --query 'sort_by(Snapshots,&StartTime)[*].{Id:SnapshotId,GB:VolumeSize,Started:StartTime,Vol:VolumeId,Desc:Description}' \
  --output table | head -40

# Snapshots not referenced by any registered AMI — the forgotten category.
comm -23 \
  <(aws ec2 describe-snapshots --owner-ids self --query 'Snapshots[].SnapshotId' --output text | tr '\t' '\n' | sort) \
  <(aws ec2 describe-images --owners self \
      --query 'Images[].BlockDeviceMappings[].Ebs.SnapshotId' --output text | tr '\t' '\n' | sort -u)

For the actual storage each one is responsible for, rather than its nominal volume size, use the list-changed-blocks API or enable AWS Backup reporting — VolumeSize is the size of the source volume, not the incremental data stored.

Before you delete

Check that the snapshot is not the last line of defence. Compliance regimes often require a retention period that is longer than anyone remembers agreeing to. Confirm the retention requirement before bulk deletion, not after.

Snapshots referenced by an AMI that is still registered cannot be deleted while the AMI exists — AWS blocks that, which is a useful safety net. Snapshots referenced by an AMI shared with another account are also load-bearing for that account.

Never bulk-delete by age alone. Delete by age and absence of an AMI reference and confirmed retention policy.

Stopping them coming back

Use Data Lifecycle Manager or AWS Backup with an explicit retention policy rather than a cron job calling create-snapshot. Both delete on schedule; a cron job does not.

Adopt a tagging convention that records why a snapshot exists — Retention=30d, Retention=compliance-7y — so a future cleanup can act on intent rather than guesswork.

Prices quoted are us-east-1 list rates, last checked on 2026-08-22, and are shown with the arithmetic so you can substitute the rates for your own region. Always confirm against the AWS pricing page before acting on a number.