Cloud waste went up this year, and storage is where it hides
September 2026 · 7 min read · Mayur
Flexera surveys around 750 organisations every year about how they use the cloud. One question asks respondents to estimate how much of their own cloud spend is wasted.
For five straight years the answer went down. Companies got better at this. FinOps became a job title. Tools got built.
In 2026 the answer went up, to 29%.
That is roughly three dollars in every ten, self-reported by the people who own the budget. And self-reported waste is almost always an underestimate, because you cannot report the waste you have not found yet.
I want to argue that a disproportionate share of it is sitting in object storage, and that it is there for a reason that has nothing to do with laziness.
Why the number went back up
The same Flexera survey found 73% of organisations now run hybrid estates, up three points year on year, with multi-cloud adoption up two points.
Those two findings are not independent. Waste went up in the same year that estates got more fragmented, and I do not think that is a coincidence.
Here is the mechanism. Cost control requires visibility. Visibility requires one place to look. Every additional provider adds a console, a billing format, a set of terminology, and a separate mental model. At one provider you can hold the picture in your head. At two you need a spreadsheet. At four, nobody is holding the picture at all, and the spreadsheet is eleven months out of date.
Meanwhile the AI workload boom is pushing enormous volumes of data into storage that nobody has a lifecycle policy for. Backblaze reported AI customers up 76% year on year. Training data accumulates, experiments finish, and the buckets stay.
Fragmentation went up. Visibility went down. Waste followed.
Why storage specifically
Compute waste is loud. An idle instance shows up on a dashboard, someone gets paged about utilisation, and eventually it gets killed. Compute has a culture of rightsizing.
Storage waste is silent, and it is silent for four structural reasons.
It never breaks. A forgotten bucket does not page anyone. It has no CPU graph. It never falls over. It simply appears on the invoice, in a line item that reads the same every month, slightly larger.
It only grows. Nobody deletes data. Deleting is scary, because the one time it matters you will want the thing you deleted. So the default is keep, forever, and the default is expensive.
The cost is not where you look for it. Storage cost is spread across storage rate, requests, egress, early-deletion charges, and cross-region transfer. Most people only look at the first one.
Nobody owns it. Compute has an owner because it runs something. A bucket from a project that shipped in 2023 belongs to nobody, and the person who created it left.
The five places the money actually is
In rough order of how much you will find.
1. Cold data on hot storage
The biggest one, every time. Archive material, old project deliverables, finished video, backups of backups, sitting on S3 Standard because that is where it landed.
The arithmetic: 8 TB of cold data costs roughly $184 a month on S3 Standard and roughly $40 on Backblaze B2. $144 a month, $1,728 a year, on data nobody has opened in a year. Both figures are from public price lists.
The reason this is missed is that it does not look like waste. The data is genuinely wanted. It is just on the wrong shelf.
2. Duplicates
Uploaded twice by a retried script. Copied into a second bucket "temporarily" during a migration in 2024. A backup process that never dedupes. In practice, checking for duplicate content on any storage estate over a terabyte finds something, and often finds a lot.
3. Incomplete multipart uploads
This one is nearly invisible and it is my favourite, because almost nobody knows about it.
When a large upload fails partway, the parts that were already uploaded stay in the bucket, and you are billed for them. They do not appear in a normal object listing. They accumulate silently for years.
If you have never run a lifecycle rule to abort incomplete multipart uploads after seven days, do it today. It takes two minutes and it is free money for a meaningful number of estates.
4. Old versions
Versioning is a good idea and you should have it on. But every overwrite keeps the previous version, and you pay for all of them. A bucket with versioning enabled and no lifecycle rule to expire noncurrent versions can be several times the size you think it is.
5. Egress you did not budget for
The line called Data Transfer Out. It is not waste exactly, but it is very often unexamined, and the exercise of examining it usually leads somewhere.
What to actually do, in an hour
- List your buckets, everywhere. All providers. If this takes more than ten minutes, that difficulty is itself the finding.
- Sort by size, and find the largest bucket nobody has mentioned this year.
- Check last-accessed dates on your top five buckets. Anything untouched for six months is a lifecycle candidate.
- Set an abort-incomplete-multipart-upload rule at seven days on every bucket. Two minutes, zero risk.
- Expire noncurrent versions after whatever your real recovery window is. Ninety days is a sensible default that people rarely regret.
- Price your cold pile elsewhere. Size times the rate difference times twelve.
- Set a budget alert, so the next surprise arrives as a notification rather than an invoice.
That is one hour, and for most estates over a few terabytes it finds four figures a year.
The honest bit
Twenty-nine percent is a self-reported estimate, not a measurement. It comes from a vendor survey where people guess at their own waste. It is directionally useful and it should not be quoted as a precise fact. What makes it interesting is not the number, it is the reversal after five years of decline.
Not all of this is storage. Idle compute, oversized instances, and unattached volumes are all real and probably larger in aggregate. My argument is that storage is the most neglected share, not the largest.
Some waste is rational. Keeping data you probably will not need is cheap insurance against the one time you do. The goal is not zero waste, it is knowing which waste you chose. There is a real difference between "we keep seven years of this deliberately" and "nobody knows what that bucket is."
A tool does not fix this by itself. It makes the problem visible, which is the hard part. Someone still has to decide what to delete and what to move, and that decision needs a human who knows the business.
Questions people actually ask
Where does the 29% figure come from? Flexera's 2026 State of the Cloud report, based on a survey of around 753 respondents. It is self-reported estimated waste as a share of IaaS and PaaS spend.
What is a realistic saving on storage? For an estate of a few terabytes with no lifecycle discipline, 30 to 60% of the storage line is common, mostly from moving cold data and expiring old versions. The larger and older the estate, the larger the share.
Does intelligent tiering solve this? Partly. AWS Intelligent-Tiering moves objects between access tiers automatically and is genuinely useful for unpredictable access patterns. It does not move data to a cheaper provider, and it does not delete anything, so it addresses one of the five items above.
How do I find incomplete multipart uploads?
aws s3api list-multipart-uploads --bucket your-bucket. Then set a lifecycle rule so you never have to check again.
Is it worth moving providers to save this? Depends on volume. Under a terabyte, probably not, your time is worth more. Over ten terabytes of cold data, almost always yes, and the exit fee pays for itself within months.
Storafleet shows what each bucket costs across every provider you use, compares it against what the same data would cost elsewhere, and flags duplicates and size hotspots. Your data stays in your own accounts. Connect a bucket, free, no card.