EBS Snapshot Sprawl: Why Deleting or Archiving Old Snapshots Often Saves Less

Welcome to today's deep dive. We are pulling from a stack of AWS engineering blogs and cloud architecture notes today to tackle something pretty much every developer faces. Oh yeah, mastering the cloud bill. It's a constant battle. Right.

So let's unpack this. You look at your AWS bill, you see, you know, your EBS snapshot costs creeping up, and you do the logical thing. Which is deleting things. Exactly. You find an old snapshot, hit delete, and you just wait for the storage costs to drop.

But here's where it gets really interesting. Deleting an Amazon EBS snapshot doesn't actually always free up space. No it doesn't. And it definitely doesn't always reduce your bill. Which trips up a lot of teams because, well, standard snapshots are incremental.

So deleting one only frees the specific data blocks that no later snapshot in the chain actually needs. Right. I mean, it's exactly like a Jenga tower. That's a great way to look at it. You pull out an older block from the bottom, but you aren't knocking down the whole tower.

If a newer snapshot needs those blocks, AWS just keeps them. Yeah, you're only freeing up the completely unreferenced blocks. Exactly. And when you look at the unit math there, standard snapshots bill out about five cents per gigabyte month. But deleting a hundred gigabyte snapshot rarely actually removes a hundred gigabytes of billed storage because of that shared block structure.

My immediate instinct here, I mean, if deleting is that inefficient, is to just shovel all those old snapshots into the EBS snapshots archive tier. A lot of engineers think that. Right. Like, just get them out of the standard tier entirely and take the cheaper rate. Well, the archive tier is cheaper up front.

It's about 0.0125 per gigabyte month. Which sounds way better. It does, but the catch is that AWS converts that incremental data into a full copy. Oh wow, so it expands. Yeah, it inflates to include every single block written to the volume at the time.

Plus, you know, the archive tier enforces a strict 90-day minimum retention period, and they actually charge a fee to restore the data. So archiving junk is not a fix at all, it just locks in the waste. Pretty much. It kind of blows my mind that we're paying for inflated full copy archives just to hide the fact that our CI pipelines are like incredibly messy. Yeah, the CI pipeline is usually the biggest organizational culprit here.

Because we spin up these AMIs for deployments and just ghost them when the teardown fails. Right, the automation constantly creates AMIs, but it routinely drops the ball on de-registering them when tearing down, which leaves behind these orphan snapshots. And nobody owns them. Exactly, nobody owns them, they don't trigger any alarms, and they are completely invisible on a per-service bill. So if you wanted to track down these ghosts today without buying any third-party tools, what do you do?

I mean, my instinct would be to just write a script that deletes any snapshot older than 30 days. Which will definitely break something. Yeah, I figured. The specific signal you actually want to query your AWS environment for is a snapshot where the source volume no longer exists. Okay, so the source volume is gone.

Right, and then you have to cross-reference that list to ensure no currently registered AMI is using it. If you find a snapshot with no source volume and no attached AMI, that is your target. But let's be real about engineering for a second here. Even with that exact intersection, you can never call a resource provably or guaranteed unused. Oh, absolutely not.

Like a rollback script, an auto-scaling group, or some infrastructure as code template might still depend on that exact snapshot ID. Yeah, and because deleting a snapshot is a permanent action, getting it wrong is bad. Whatever depended on it breaks immediately. Because there's no preview check that makes deleting it risk-free. Right.

So the safe fix requires setting up an AWS recycle bin retention rule beforehand. Ah, so that acts as your rollback mechanism. Exactly. You always have to manually cross-check your AMIs and backups before hitting delete. But if something slips through, the recycle bin holds it so you can actually restore it.

Just to wrap this up, if you want some help here, you can use a free source available scanner by running pip install cloudcostwise. It runs read-only on your own machine, flags this specific orphan pattern, and sends absolutely nothing to CloudWise. Getting that kind of visibility into these mechanics really changes how you look at your infrastructure. It really does. And, you know, think back to that Jenga tower of snapshots we talked about earlier.

If your deployment scripts are leaving these behind, what else are they missing? What other invisible infrastructure dependencies are your CI pipelines quietly abandoning right now, silently driving up your AWS bill?