EBS snapshot cost creep: the storage bill that never stops growing

Quick answer

EBS snapshots are billed per GB of stored data per month and are incremental (each stores only changed blocks since the last), so a single snapshot is cheap. The cost creep comes from volume: automated daily or hourly snapshots retained forever, forgotten manual snapshots, and orphaned snapshots whose source volumes are long gone, all accumulating until snapshot storage rivals or exceeds live EBS cost. The fix is lifecycle policies that expire old snapshots automatically, plus periodic audits to delete orphaned and redundant snapshots. Retention discipline is the main lever.

Any single EBS snapshot looks trivially cheap, so nobody worries about them. That is exactly why snapshot storage becomes one of the quietest budget leaks in AWS. Automated backups run every day, manual snapshots get taken and forgotten, and snapshots outlive the volumes they came from. Multiply cheap by thousands and retained forever, and snapshot storage can quietly grow to rival or exceed your live volume bill.

How snapshots are billed

Property	Behavior
Pricing	Per GB of stored snapshot data per month
Incremental	Each snapshot stores only blocks changed since the last
Deletion	Removing one snapshot only frees blocks no other snapshot needs
Archive tier	Cheaper storage for rarely-accessed snapshots, with retrieval cost

Snapshots are incremental, which is good (you are not storing a full copy each time) but also confusing: deleting an old snapshot may free very little if later snapshots still reference the same blocks. Cost tracks the total unique blocks stored across the whole snapshot chain, so the real driver is how many snapshots you keep and for how long, not how often you take them.

Where the creep comes from

Three sources dominate. Automated backup policies (Data Lifecycle Manager, AWS Backup, or third-party tools) that create frequent snapshots but never expire them, so retention grows without bound. Manual snapshots taken before a risky change and never cleaned up. And orphaned snapshots whose source volume was deleted but whose backups linger, pure waste with no purpose. These are the same class of forgotten resource covered in hidden AWS costs to watch.

Stopping the creep

Set lifecycle policies that automatically expire snapshots after a defined retention window (for example keep daily for a week, weekly for a month, monthly for a year, then delete), so old backups age out without manual effort. Audit periodically for orphaned snapshots (source volume gone) and redundant ones, and delete them. Move rarely-accessed snapshots you must keep for compliance to the cheaper archive tier. And tag snapshots with an owner so they are attributable rather than anonymous, the same discipline that kills other silent AWS waste.

Right-size the backup policy itself

Beyond cleanup, question the policy. Do you need hourly snapshots of a volume that changes little? Does every dev and test volume need the same retention as production? Matching snapshot frequency and retention to the actual recovery requirement, rather than applying one aggressive default everywhere, is what prevents the creep from returning. Combined with expiring lifecycle policies and periodic audits, it keeps snapshot storage a small, predictable line rather than an ever-growing one. Pair this with a gp2 to gp3 migration on the live volumes if you have not already, and review overall EBS spend against EFS vs EBS cost for shared-storage workloads.

FAQ

Why do EBS snapshot costs keep growing?

Because snapshots accumulate. Automated backup policies create frequent snapshots but often never expire them, manual snapshots get taken and forgotten, and orphaned snapshots outlive their deleted source volumes. Each snapshot is cheap, but retained forever and multiplied across a fleet, total snapshot storage can grow to rival or exceed your live EBS cost. Retention discipline is the fix.

How are EBS snapshots billed?

Per GB of stored snapshot data per month. Snapshots are incremental, so each stores only the blocks changed since the previous snapshot, and cost tracks the total unique blocks across the whole snapshot chain. This means the main cost driver is how many snapshots you keep and for how long, not how frequently you take them. An archive tier offers cheaper storage with a retrieval cost.

Why does deleting a snapshot free so little space?

Because snapshots are incremental and share blocks. Deleting one snapshot only frees blocks that no other snapshot in the chain still references. If later snapshots depend on the same blocks, removing an early snapshot reclaims little. To meaningfully reduce cost you often need to expire whole ranges of old snapshots via lifecycle policy rather than deleting individual ones.

How do I reduce EBS snapshot costs?

Set lifecycle policies that automatically expire snapshots after a defined retention window (for example daily for a week, weekly for a month, monthly for a year, then delete). Audit periodically for orphaned snapshots whose source volume is gone and delete them, move compliance-only snapshots to the cheaper archive tier, and tag snapshots with an owner so they are attributable rather than anonymous waste.

What are orphaned EBS snapshots?

Snapshots whose source volume has been deleted but which were never cleaned up themselves. They serve no restore purpose for a volume that no longer exists, yet continue to accrue storage charges every month. Orphaned snapshots are pure waste and a prime audit target: find them by cross-referencing snapshots against existing volumes, confirm they are not needed, and delete them.

Should dev and production have the same snapshot retention?

Usually not. Applying one aggressive retention default everywhere is a major source of cost creep. Match snapshot frequency and retention to each volume's real recovery requirement: production may need frequent, longer-retained backups, while dev and test volumes often need far fewer or none. Right-sizing the backup policy itself, not just cleaning up afterward, is what stops the creep from returning.

What to do next

Catch backup and storage cost before it accumulates. C3X reads your Terraform and prices your resources against a live catalog. Start with the quickstart.