Prune ancient EBS snapshots

EBS snapshots are billed at roughly $0.05 per GB-month of unique data stored. Because they're incremental, a single snapshot is cheap — but a four-year unmanaged nightly run against one volume can silently accumulate hundreds of gigabytes of unique data. The per-snapshot cost in the inbox looks small ($0.01–$11.54/mo each), but the tail of a few hundred stale snapshots easily compounds to $24k or more per year on backups that nobody has ever restored from.

The core issue is the absence of a retention policy. Where spending on compute or databases tends to be intentional and reviewed, snapshot storage accretes invisibly — each individual charge is below the attention threshold, but the aggregate is material. This is a classic unit-economics problem: the marginal cost of snapshot N looks trivial, but the cumulative cost of 1,742 snapshot Ns is a real budget line nobody approved.

For finance, the right frame is a one-time cleanup to eliminate the backlog followed by a standing retention policy that enforces a fixed cost ceiling per volume going forward. A well-set DLM policy converts snapshot cost from open-ended accumulation into a predictable, capped line item — so the next four years don't reproduce the last four.

Marcus is the FinOps lead for a mid-size SaaS company. At the quarterly cost review he notices EBS snapshot spend has been climbing by roughly $800/mo for the last six quarters — now $14,200/mo — with no corresponding growth in active volumes. He pulls the snapshot inventory: 47 volumes have more than 100 snapshots each, and the oldest snapshots per volume average 1,100 days.

Rather than approve a blanket delete, Marcus frames it as a tiering exercise. He asks engineering to classify each volume against the data retention schedule in their SOC 2 agreement: 90 days for production customer data. Everything beyond 90 days that isn't archived for a documented compliance reason is waste. The volumes without a production tag — dev, test, build artifacts — have no retention requirement at all; he marks those for full cleanup.

He models the saving: 47 volumes, estimated 600 GB of stale unique data beyond 90 days, at $0.05/GB-month is $360/mo in direct savings from deletion. A further 180 GB of compliance-hold data moved to the Archive tier saves another $4.50/GB-month × 180 ≈ $810/mo versus keeping it in standard. Combined cleanup: ~$1,170/mo ongoing, plus elimination of the $800/mo drift if DLM is set with a 90-day ceiling. Total annual impact: roughly $24k — a real budget line to close against.

The direct cost impact of unmanaged snapshot growth is both real and forecastable: at $0.05/GB-month, 600 GB of stale unique snapshot data above your retention requirement costs $360/mo — $4,320/yr — before any Archive optimization. More importantly, if the pattern is consistent, that cost compounds year-on-year because each new undeleted snapshot adds to the base. Snapshot spend that grows 10% a month doubles in under a year. That's the cost side of this finding, and it's easy to model.

The compliance cost is harder to quantify but potentially more expensive. If your stated data retention schedule says 90 days and your snapshots go back four years, you have a documented discrepancy between policy and practice. A customer security review, a SOC 2 audit, or a GDPR Subject Access Request that surfaces this is not a bill line — it's a finding against your governance posture. Correcting it reactively is costlier than building it into your operating model proactively.

For budget owners, the right ask is: put a retention ceiling per volume type on the roadmap and fund the one-time cleanup. Once DLM enforces a fixed retention count, the snapshot line stops compounding and becomes a predictable, defensible cost. The difference between 'snapshot cost grows indefinitely' and 'snapshot cost is capped per volume' is the value of this control expressed in budget certainty.

Cloud backup costs are easy to ignore because they accumulate slowly and no individual charge triggers an alert. Years of undeleted daily snapshots can quietly become one of the largest line items in EBS billing — spending on backups no one has ever used and no one has approved to keep. Security findings flag this as a cost risk, but it's also a compliance risk: holding data beyond the retention schedule you've committed to in your data governance policy is a liability, not an asset.

The leadership question is whether the organization manages backup data the same way it manages other data: with a defined retention period, a clear owner, and evidence that the policy is followed. Right now the answer for most accounts is no — data is kept indefinitely because deletion was never automated. The fix isn't technical complexity; it's a standing policy decision — how long do we need this, and who decides — enforced by automation rather than left to chance.

At a financial services company, the CISO, Ravi, got a question from a customer audit team: "Show us that you delete data according to your stated 90-day backup retention schedule." The honest answer was that they couldn't — nobody had ever automated deletions, and the evidence would have shown data going back four years. That's when snapshot hygiene became a leadership priority rather than an engineering to-do.

Ravi didn't need to understand incremental storage mechanics. He needed to answer two questions: which snapshots exist beyond our stated policy period, and what's the process that ensures they get deleted on time going forward? The engineering team showed him a DLM policy enforcing 90-day retention across all production volumes, and a Recycle Bin configured for a 30-day recovery window. Those two controls, applied and evidenced, were what closed the audit finding.

His takeaway for the leadership report: backup data governance is not a hygiene detail — it's a compliance commitment. Every quarter the organization should be able to show that backup data is retained for exactly as long as the policy says, no longer. A growing snapshot bill with no retention policy is evidence to the contrary.

Unmanaged EBS snapshots are a cost, a compliance, and an operational risk bundled together. On cost: backup storage grows without bound when nobody automates deletion, and the aggregate line item becomes material before any individual charge triggers a review. On compliance: keeping data beyond the retention period your own policy specifies is an audit finding waiting to happen, not a benefit.

On operations: a volume with 1,742 snapshots is not better protected than one with 30 — it's harder to recover from, because no one knows which point in time to restore. More is worse once you've exceeded the window you'd actually use. The fix is a standing retention policy enforced by automation — not a one-time cleanup, but a standing answer to the question: how long do we keep backup data, and how do we prove it?

The leadership signal to ask for is not the number of snapshots deleted but the presence of a lifecycle policy on every active volume. That's evidence of governed backup practice rather than inherited snapshot debt.