A cleanup deletes 2000 orphaned volume snapshots whose reported sizes total 60 TB. On the next full invoice the snapshot line falls by about 5%. The snapshots really are gone and billing has caught up. Where is the saving?

What is being tested

Whether you can tell a deleted object from a freed byte. Cleanup programmes are reported in objects removed because that is what the tooling counts, and the invoice only ever moves on bytes.

The diagnosis

Volume snapshots are incremental. The first snapshot stores every allocated block; each later one stores only blocks changed since the previous one, and references the rest. The EBS documentation states the billing consequence directly: deleting a snapshot removes only the data referenced exclusively by that snapshot, and data a later snapshot still references has its cost reallocated to that later snapshot.

So the 60 TB figure was never stored bytes. It was the sum of the source volumes each snapshot can restore. Deleting 2000 middle-of-chain snapshots removed the blocks that only they held, which for a daily-snapshot schedule on quiet volumes is the daily delta, perhaps 1–3% of volume size each. The 5% fall is the correct and expected result.

Why the other options fail

• A 90-day minimum retention. Minimum storage durations are real, and they apply to archive storage classes, not to block snapshots in the standard tier. Importing that rule here predicts no saving at all for three months, which is not what happened.
• Pre-compression sizes. Snapshots are stored compressed, so the figure is inflated, but compression would scale the whole line down rather than make deletions ineffective. It explains the absolute number, not the missing delta.
• Provider approval. Nothing throttles deletion at this scale. This is the kind of answer that sends a team to open a support case instead of reading the data model.

What to change, in order

1. Measure the campaign in freed GB-months from the billing export, not in objects deleted. This single change would have caught the problem on day one.
2. Delete whole chains, oldest first. Removing every snapshot of a decommissioned volume frees all of its blocks; removing one in ten frees almost nothing.
3. Fix the policy that creates the chain. A 90-day daily schedule on 400 volumes is the cost driver. A weekly cadence with monthly long-term copies holds the same recovery points for a fraction of the bytes.
4. Move long-retention copies to an archive snapshot tier, which at 2026 US list prices is $0.0125 per GB-month against $0.05 standard, in exchange for a restore delay and a retrieval charge near $0.03 per GB.

When this is the wrong answer

If the snapshots were full copies rather than incremental ones, which is how some backup products and most cross-account copies behave, deleting them does free their full size and the missing saving really would be a billing lag or a tagging error. Confirm the storage model before you reason about the invoice, because the same cleanup produces completely different arithmetic under the two models.