Storage Is Not Cheap. It Is Just Easy to Ignore.

Yesterday’s post was about a billing detail so small most teams never see it (the same machine, two different bills). Today’s is about the opposite failure: resources so large and so visible on the invoice that nobody ever actually looks at them, because nobody thinks they have to.

It surprises me every time it happens, and it keeps happening. A team builds something. Later the team moves on, or leaves the company, or the oversight arrangements change, and the tracking quietly stops. The people who remain assume someone else is keeping an eye on it. Someone else assumes the same about them. Then one day somebody runs an inventory and discovers a couple hundred S3 buckets or EBS volumes that nothing is using, some of them untouched for years. There was no decision to keep them. There was just no decision to remove them, and those are different things.

Storage is the easiest place for this to happen, and the reason is a sentence I have heard many times: storage, whatever, it is cheap. It is cheap per gigabyte. Amazon lists S3 Standard at $0.023 per GB-month for the first 50 TB in us-east-1.¹ But cheap per gigabyte and cheap in total are different claims, and the second one is false the moment the gigabytes pile up. Storage accrues like almost nothing else in the bill. Compute that is not needed gets shut off, because someone notices an idle machine. Storage that is not needed just stays, because there is no machine to notice. It has no fan noise, no login history, no dashboard. The money leaves quietly, month after month.

AWS’s own guidance says the quiet part out loud. Unattached EBS volumes, the documentation notes, “incur the same charges as attached volumes based on the provisioned storage size and storage type,” and it walks through fifty abandoned 100 GB volumes at about $0.10 per GB-month: roughly $500 a month, $6,000 a year, for disks attached to nothing.² Scale that arithmetic up and the numbers stop being embarrassing footnote money. A few hundred forgotten buckets and volumes across an account can carry a real salary of waste. The book’s arithmetic in chapter 10 separates installed, schedulable, and usable capacity, and the gap it is really about is the one between what you pay for and what does any work (chapter 10). Unused storage is that gap with no clock on it.

Here is the part that turns cleanup from a weekend task into a program: proving you do not need the storage is hard, and it is hard for reasons that have nothing to do with technology. Some of that data is archive. Some of it is subject to regulation. If the data is covered by any sort of compliance rule, there is a real chance you are required to hold onto it for a certain number of years, and establishing whether that applies is not straightforward. The teams who built the systems often were not compliance people; they were following the rules they knew, doing their best with the requirements in front of them. Then people moved around, and the reason a bucket exists walked out the door with them. AWS’s deletion guidance is honest about this too. It recommends verifying compliance requirements, checking dependencies, backing data up before deletion, and performing “due diligence” before removing anything unattached.³ The vendor that would love to sell you an automated cleanup script is telling you the script is the easy half.

So what do you actually do when the inventory says you are paying for storage nobody uses? You treat it as a program, because there is no way around the conversations. For each pool of storage you have to go talk to the people who use it, or used it, or inherited it, and ask two questions: are we legally required to keep this, and is there any business use case that requires us to store this. The first question has an answer in a policy document somewhere, if the document still exists and still matches reality. The second question has an answer in somebody’s head, if that somebody still works there. A script can produce the list. Only people can clear the list, and they clear it slowly, one verified decision at a time.

Let’s say you find a million dollars of waste in storage. Cleaning it up is not an overnight job. It is a whole program. The discovery takes an afternoon. The cleanup takes quarters, because every terabyte has to be traced to a requirement or released by one, and the requirement lives in an organization that has changed shape since the data arrived. Storage is so easy to forget about. It is so easy to waste money on it. The teams that avoid the waste are not the ones with the cleverest deletion scripts. They are the ones who never let “someone is keeping an eye on it” go unverified in the first place.

Sources