I am Lino
April 30, 2026

The cloud isn't cheap anymore: welcome to the FinOps era

Posted on April 30, 2026  •  12 minutes  • 2542 words
Table of contents

Move to the cloud. You’ll save money. We’ll figure out the details later.

After hearing it enough times, you stopped reading the fine print.

And honestly, not having to buy new hardware every three years is genuinely great. Being able to shut down test environments when nobody’s using them - also great.

“Later” has arrived in the form of monthly invoices with more digits than expected and politely-worded emails from Finance asking - smiling to your face and sharpening a knife behind your back - what exactly kinesis-analytics-something-us-east-1-prod is and why it costs that much .

What we’re living through now has a name: FinOps.

It’s not a magic tool or a new role that fixes everything. It’s the acknowledgment that the cloud stopped being “cheap by default” and became flexible by default.

And flexibility, without discipline, gets expensive .

From “the cloud saves you money” to “who left this thing running?”

When you first read the early cloud evangelism pieces, they all sounded the same: pay only for what you use, infinite scalability, no upfront investment, goodbye to dusty old data centers.

On the transparency front - impeccable. On the bank statement front, things shifted once usage started climbing… and nobody was looking too closely at what exactly was being used.

There’s a documented case of a company spending over $50 million a year on cloud - dashboards, alerts, negotiated contracts and all - and still burning through an obscene amount of waste: data kept around for no reason, massively overprovisioned services “just in case,” expensive managed solutions where something off-the-shelf would have done the job. It’s not an unusual story. It’s the usual story, with the names changed.

The figures floating around the industry - from the FinOps Foundation to consultancies like KPMG - hover around 25–30% waste on total cloud spend. Take it as an estimate, not a law of physics - but the direction is right: a whole lot of what you’re paying for isn’t doing anything useful.

And the most frustrating part? It’s not negligence. The cloud made it so easy to spin up resources with a click that classic financial controls simply couldn’t keep up. What used to require a ticket, a PO, and three approvals can now be done with a corporate credit card and fifteen minutes to kill.

“The problem isn’t Finance - it’s your systems”

The most natural reaction when invoices start climbing is to point at Finance and calmly say, “this is your problem.” And Finance does what it can: builds dashboards, runs reports, sends the “we’ve detected a spike in account X” email with the team lead CC’d. All well and good. The only catch is that Finance doesn’t design your systems - it just pays the bills that your architectural decisions generate.

The uncomfortable truth is that cloud costs usually aren’t a financial failure - they’re an architectural symptom .

Your application, your deployment approach, your decisions about where data lives - all of that determines how much gets spent.

If your system was designed assuming infrastructure is fixed and cheap, cloud elasticity isn’t going to fix anything. It’s going to amplify the problem, faster and more elegantly than before.

That’s why “cost optimization” efforts that rely purely on cutting things fail so often. Sure, you can kill an obvious zombie resource. But as long as your architecture keeps spinning up massive VMs for every microservice, shuffling data across regions without watching egress costs, or leaving processes running indefinitely because “nobody’s really sure if that thing still does anything useful,” costs will keep climbing - no matter how fancy your spreadsheet is.

When FinOps actually makes sense, it’s exactly this shift: cost stops being a number in a report that shows up three weeks late and becomes just another system metric.

The same way you track latency and error rates, you track dollars spent per product, per feature, per customer. Without waiting for the end-of-month summary to find out the party’s been going all night.

Why your bill keeps climbing even when you think you’re doing everything right

Browse any FinOps forum and you’ll see the same thread over and over:

“We’ve had FinOps for a year. Perfect tagging, reserved instances, alerts everywhere… and the bill keeps going up 10–15% every quarter. What are we doing wrong?”

The answer nobody wants to hear is that they’re probably not doing anything wrong - the system is just doing more things, and nobody stopped to ask whether those things add value at the same rate they add cost.

More features, more services, more regions, more data… not always paired with more paying users or more revenue. Just more bill.

The bulk of cloud spend doesn’t come from dramatic spikes or incidents. It comes from the boring stuff : workloads that have been running for months long after anyone actually needed them, APIs that move more data than any user will ever actually see, applications built for fixed infrastructure that scale in the cloud like a balloon with a hole in it.

It’s the equivalent of leaving every light in the office on all weekend because “we already paid for the electrical installation.”

And then there’s the “everything’s better with AI” effect: massive models for problems four if-else rules would solve, pipelines churning through terabytes to generate recommendations nobody looks at, training environments left running because “we might want to retrain next month” - spoiler: you won’t.

With AI workloads, storage, snapshots, and data transfer can blow the budget even faster than compute, precisely because nobody watches those line items as carefully.

The bottom line: you can have FinOps perfectly documented on paper, but if the architecture underneath is wired to waste - overprovisioning by default, duplicated data without a second thought, features nobody uses that looked great on the roadmap - your bill is going up like clockwork.

What your engineering team can actually do without becoming an accountant

The good news - and there is some - is that this doesn’t require any developer to open a spreadsheet and cry over formulas. What it does require is that costs show up where the decisions that generate them are being made - not three weeks later in an email from Finance.

Think about it this way: if your Terraform says nothing about what something is going to cost to run, you’re making architectural decisions blind, and it’s going to hurt later.

The idea behind “FinOps as Code ” is exactly that: annotate resources with cost expectations, set policies that block someone from deploying an RDS r6g.16xlarge “because that’s what the tutorial used,” make the pipeline complain about unexpected spend the same way it complains when tests fail. Not because you’re being cheap, but because making a $4,000/month decision without knowing it isn’t agility - it’s an accident waiting to happen.

The other front is making sure the product team can see what their product actually costs. Not the CTO in a quarterly report - the team that decides which features to build, what architecture to use, how many staging environments to keep alive.

Showback and chargeback are ugly words, but the idea behind them is simple: if the billing team finds out that their PDF generation service is eating 40% of compute spend, the conversation about whether they really need that cluster changes tone pretty fast. Without that shared visibility , optimization is always somebody else’s job - and that somebody never shows up.

Day-to-day, the fastest wins tend to be the most unglamorous: that Lambda that’s been running for nine months with a serverless bill that makes zero sense because it’s actually a batch process that runs constantly; the three staging environments nobody remembers requesting; storage replicated across four regions because someone read an article about resilience and applied it to sprint 3 test data.

And alerts. Not the global “monthly spend exceeds X” alert that shows up after the damage is done, but per-component alarms that fire in hours, not in the end-of-month summary.

None of this turns anyone into a CFO. It just requires accepting that cost is another system quality metric, like latency or error rate: if it spikes without anything to justify it, something in the design isn’t working.

The goal isn’t to spend less. It’s to stop wasting money.

FinOps has a PR problem. When someone brings it up in a meeting, half the room hears “we’re cutting things” and starts staring at the floor. And it’s not their fault - the early years of FinOps at a lot of companies were exactly that: someone from Finance with a spreadsheet, flagging line items like they were playing a game of spot-the-difference.

But the actual idea is different: it’s not about spending less - it’s about not paying for things that do absolutely nothing.

That sounds like a subtle difference. It isn’t.

Shutting down a staging environment nobody has touched in four months isn’t austerity - it’s basic hygiene. On the flip side, making the data-backed case that a pricier managed service is worth it because it saves you from hiring two people to run it - that’s also FinOps, and the right call there is to spend more.

The hardest part is confronting your own AI-washing. It’s easy to call out someone else’s - “that startup doesn’t have AI, they have an if statement in a trench coat” - but plenty of organizations are sitting on “intelligent” features that are burning GPU, storage, and bandwidth way out of proportion to what they actually deliver. Nobody uses them. Nobody measures them. They looked incredible at last year’s demo, and now they’re a fixed cost that nobody has the nerve to kill because “someone might need them eventually.” Spoiler: nobody needs them.

The organizations that have gotten sustained results from FinOps aren’t the ones with the most aggressive cost-cutting team. They’re the ones that treat cost as part of the design , the same way they treat resilience or security. Not because they’re tighter with money, but because they make decisions with complete information - and it turns out that when you know what something costs, you tend not to throw it away.

The price of flexibility

The cloud is still great. Genuinely. Spinning up infrastructure in seconds, scaling without calling anyone, never having to buy hardware again - all of that is real and hasn’t expired.

What has expired is the idea that it comes free by default. Flexibility has a price, and that price is set by every design decision you make, every service you launch, every environment you leave running “just in case.” Without FinOps - not as a department or a tool, but as the habit of asking how much what you’re building actually costs - the cloud is just a very convenient way to burn through company money at variable speed.

Nobody’s asking you to become a financial controller or spend your Friday afternoons crying over cost reports.

Just that, the next time someone proposes “let’s add AI here” or “let’s deploy to three more regions,” someone in the room asks the most boring and indispensable question in the world:

How much does this cost? And what do we get back for it?

If you have the answer, go for it.

If nobody in the room knows, it might be worth finding out before Finance does - politely, professionally, but with their knife already out.

Quick glossary

Because not everyone is born knowing what a chargeback is - and the ones who pretend they do are usually the biggest spenders.

Sources and references

Everything you didn’t want to know about cloud costs - but can’t unknow now.

Follow me

I write and share opinions about technology, software development and whatever crosses my mind.