EBS snapshot storage: the hidden multiplier on the backup line

EBS snapshots are the backup line item teams forget to budget. The source volume might be 500 GB on gp3 at $0.08 per GB-month, about $40. The snapshot chain behind it can quietly hold 2 TB of unique blocks at $0.05 per GB-month, about $100, with no running instance attached and no obvious owner in the console.

AWS bills snapshots incrementally at the block level, which sounds efficient until you realize every retained point-in-time copy keeps its delta blocks alive. A daily snapshot policy on a 1 TB database volume does not cost one snapshot. It costs the sum of every block that changed since the oldest retained snapshot, multiplied by how long those blocks stay referenced.

The baseline math

Standard EBS snapshot storage in US regions is $0.05 per GB-month. That is half the gp2 storage rate and 62 percent of gp3, which makes snapshots feel cheap compared to the live volume. The trap is volume of retained history, not the unit price.

Take a 2 TB production volume with 5 percent daily churn and a 30-day retention policy. Roughly 3 TB of unique snapshot data accumulates over the month: about $150 on snapshots alone, on top of the $160 live volume. Extend retention to 90 days without changing churn and the snapshot line can pass the volume line.

The four patterns behind the spike

1. DLM and AWS Backup policies nobody inherited

Data Lifecycle Manager and AWS Backup make it easy to schedule daily snapshots across every tagged volume. The policy was written by someone who left three years ago. Retention says 30 daily, 12 monthly, 7 yearly. Nobody asked whether the yearly tier was still required after the compliance review moved to cross-region replication.

2. Orphaned snapshots after volume termination

Deleting an EBS volume does not delete its snapshots. The volume line disappears from EC2. The snapshot line stays in EBS under Amazon EBS Snapshots. We routinely find terabytes of snapshots whose source volume ID no longer exists, still billing at full rate.

3. AMI chains that outlive the launch template

Every registered AMI holds a snapshot. Golden-image pipelines that bake weekly AMIs and never deregister the old ones stack snapshot storage silently. The EC2 AMI list looks manageable. The snapshot inventory does not.

4. Cross-region and cross-account copies

Snapshot copy for DR is correct architecture. It is also a second full storage bill at the destination rate, plus data transfer if you copy on a schedule rather than incrementally. Teams budget the transfer once and miss the recurring destination storage.

The audit query

aws ec2 describe-snapshots \
  --owner-ids self \
  --query 'Snapshots[].{id:SnapshotId,vol:VolumeId,gb:VolumeSize,start:StartTime,desc:Description}' \
  --output table

Sort by start date and group by volume ID. Any snapshot whose volume ID returns empty on describe-volumes is a deletion candidate pending compliance sign-off. In Cost Explorer, filter Usage type contains EBS:SnapshotUsage and group by linked account and region. The line rarely appears under EC2, which is why it hides.

The fix sequence

  1. Cap DLM retention to what compliance actually requires. Yearly tiers are the usual overshoot.
  2. Delete orphaned snapshots after confirming no AMI or AWS Backup recovery point references them.
  3. Deregister stale AMIs and let the underlying snapshots age out of the retention window.
  4. Move long-archive data to S3 Glacier if the recovery SLA allows hours, not minutes.

Use the calculator before the lifecycle change

The free EBS snapshot cost calculator models retained GB, retention days, and daily churn so you can see what a policy change saves before you touch DLM. If the snapshot line is flat but large, start with orphans and AMI cleanup. If it grows month over month, the retention window is the lever.

AWS documents snapshot pricing on the Amazon EBS pricing page. The calculator uses editable defaults because private pricing agreements and opt-in archive tiers change the effective rate.