Every EBS snapshot is a promise. You create it because you want to be able to restore a volume to its state at that moment. The problem is that most organizations never revisit the question of whether that promise is still worth keeping — and AWS charges you every month until you explicitly cancel it.
At $0.05 per GB per month, a single snapshot of a 500 GB volume costs $25/month. An organization running daily snapshots across 50 production volumes without a retention policy is adding $25,000 in annual snapshot costs per year, compounding with every new volume. Over five years, this compounds into a significant and nearly invisible line item.
The EBS snapshot tax is one of the most consistent findings in cloud cost audits — not because it’s hard to fix, but because it’s hard to see until it’s already large.
How snapshots work and why they accumulate
EBS snapshots are incremental after the first one — only changed blocks are stored with each subsequent snapshot. This makes them efficient from a data transfer perspective. From a cost perspective, however, every snapshot has a storage cost that persists until the snapshot is deleted, regardless of how much data has changed.
When you create a snapshot of a 500 GB volume on day one, you pay for 500 GB. A week later, if 10 GB has changed, the new snapshot costs you for approximately 10 GB of new blocks — but the original 500 GB snapshot still costs 500 GB/month. The total cost of both snapshots is approximately 510 GB/month, not 10 GB/month. Multiply this across hundreds of volumes and years of history, and the costs are substantial.
The incremental nature of snapshots is frequently misunderstood as “recent snapshots are cheap.” They are cheap to create. They are not cheap to keep indefinitely.
The three failure modes
No lifecycle policy. The default behavior in AWS is to retain snapshots forever. Without an explicit Data Lifecycle Manager (DLM) policy or automated cleanup, every snapshot ever created still exists and is being charged for. Organizations that have been running in AWS for several years without addressing this are almost certainly paying for snapshots from workloads that no longer exist.
Lifecycle policy with no coverage. Many organizations have DLM policies for some volumes but not all. Volumes created after the policy was established, volumes in different regions, or volumes created by applications rather than infrastructure-as-code tools often fall outside the policy’s scope. A partial policy creates a false sense of control.
Manual snapshot creation outside of DLM. One-off snapshots created manually — “I’ll take a snapshot before this migration” — are never managed by DLM unless explicitly tagged to be included. These manual snapshots are the most likely to become permanent residents.
Building a retention policy that works
A defensible snapshot retention policy balances recovery needs against cost. For most production environments, something like the following is appropriate:
Daily snapshots — retain 14. This provides two weeks of daily restore points, covering most “I deleted something by mistake” scenarios.
Weekly snapshots — retain 8. This covers two months of weekly restore points, useful for recovery from corruption that went unnoticed for weeks.
Monthly snapshots — retain 12. This provides one year of monthly points, appropriate for compliance and year-end requirements.
Annual snapshots — retain 7 (for regulated environments). Only necessary if audit or compliance requirements demand long-term retention.
Everything outside these retention windows should be deleted automatically. The total snapshot count stabilizes rather than growing indefinitely, and costs plateau.
For compliance-sensitive environments, document the retention policy as part of your disaster recovery plan. Regulators and auditors generally care about whether you have a coherent recovery capability — not about whether you can restore from 847 accumulated snapshots.
The cost of getting it right
Implementing DLM lifecycle policies across an AWS account takes a few hours of infrastructure work. The policies are free — AWS charges only for the storage, not for the management of that storage.
For an organization with significant snapshot accumulation, a one-time cleanup after implementing policies can produce immediate cost savings. Deleting a five-year-old snapshot from a decommissioned workload doesn’t require a change management process — it requires a quick confirmation that the snapshot is no longer needed and a single API call.
The harder part is organizational: someone needs to own snapshot hygiene. Without a designated owner, the policy gets implemented and then not audited. New volumes don’t get included. Regions get missed. The accumulation starts again.
Assign snapshot cost management to whoever owns EBS costs in your cloud cost accountability structure. Include snapshot count and cost as a metric in your regular infrastructure reviews. Set a budget alert when EBS snapshot spend exceeds a threshold — not to respond to it in the moment, but to notice when the trend line changes direction.
CostDefender surfaces EBS snapshot age and cost as a distinct finding category, showing the oldest snapshots, total accumulated storage, and estimated monthly savings from a cleanup — without any write access to your account.