The framing is wrong. It has been wrong from the start, and it matters more than it might appear, because the frame you use determines the fix you reach for.
“Cloud waste” puts the problem in the category of accidents and carelessness — something that crept in unnoticed, spilled over, accumulated like dust. The implication is that you need to find it and remove it. That is not what most cloud cost problems actually are.
What organisations are looking at when they look at oversized VMs, idle environments, and workloads running in expensive regions is architecture debt. It is the accumulated cost of decisions made — deliberately, under time pressure, with other priorities — that were never revisited.
The “Later Never Comes” Trap: Technical debt is the most common form of debt in these projects, and it almost always gets left behind in the rush for new features. We tell ourselves we’ll optimize that SKU or automate that shutdown “later,” but in the cloud, later never comes. Every day that debt sits on the books, you are paying a high interest rate on a decision you made months ago.
The reframe changes accountability. “We have architecture debt” is something the organisation created, which means the organisation has the capability to address it. You cannot accidentally stumble into repaying architecture debt. You have to make the decisions that were deferred: rightsize the workloads, commit to reservations, and enforce the tagging that traces cost back to its source.
From the practitioner’s view: This is where most organisations fail structurally. See How Cloud Cost Becomes Someone Else’s Problem to understand the accountability gap that prevents debt repayment.
Framing the ROI: The reason this debt accumulates is that engineers struggle to frame it in a way the business understands. You don’t get budget for “optimization”; you get budget for Return on Investment. When I talk to stakeholders, I don’t just talk about saving money. I tell them: “If we clear this architecture debt, the savings will be enough to fund an entire additional team.” Suddenly, you aren’t talking about infrastructure—you’re talking about being more agile and increasing the time-to-market for the next big feature.
The fix changes too. The architecture debt answer is to track it, prioritise it, and repay it systematically. You build it into the design process so that new debt is created deliberately, with eyes open, rather than by default. You review it on a cadence rather than declaring it a crisis when the monthly bill surprises someone.
I think about cloud cost the way I think about any other structural quality attribute: it is an architecture concern, it is an engineering discipline, and it belongs in the design conversation from the beginning. The goal is not to reduce waste. The goal is to build systems that cost what they should cost to run, and to make the decisions that were deferred before they compound any further.
This is the final post in the Cost-Optimised Cloud series.