Remember when cloud was going to save money? The pitch was seductive. Stop buying infrastructure. Stop guessing capacity. Just pay by the drink! A little compute here, some storage there, a round of managed services for the table. No commitments. No waste. Just pure, consumption-based efficiency.
It turns out that pay-by-the-drink works great when someone’s watching the tab. Lately, we’re asked to help budget review meetings where the mood has shifted. Two years ago, cloud conversations were about agility, speed, innovation. Now they’re about the invoice. Which can be quite sobering.
A public service client migrated aggressively to AWS during the pandemic. Smart move at the time. They needed to scale digital channels fast, and the cloud delivered. Better yet, it meant OpEx over CapEx. However, the cloud also delivered, eighteen months later, a monthly bill that far exceeded expectations. In the CFO’s exact words: “I thought we were renting. This feels like we bought the building.”
The Open Tab Problem
The cloud pricing model is elegant in theory. You pay for what you use. No capital expenditure. No over-provisioning. Scale up when you need it, scale down when you don’t. But in practice, it’s like handing every team in the organization a corporate card at an open bar. The drinks are small, but they add up.
On-premise infrastructure had a brutal clarity to it. You bought servers. You knew what they cost. The number was big and visible and argued over in annual budget cycles. Cloud spending is different. It’s distributed across teams, services, and accounts. It accrues daily in increments that seem small until they don’t. It’s death by a thousand API calls.
It might look like this:
- Dev teams spin up environments for testing and forget to tear them down. That “temporary” staging environment from last March? Still running. Still billing.
- Architecture decisions have cost implications that nobody modeled. Choosing a managed database service over self-hosted seems obvious until you realize the pricing scales with storage, I/O operations, and backup retention in ways that weren’t in the original estimate.
- Reserved capacity goes unused. Organizations buy commitments to get discounts, then don’t use them because workload patterns changed.
- Data transfer costs blindside everyone. Moving data between regions, services, or even other clouds, all adds up in ways that the architecture team didn’t anticipate because, honestly, data egress pricing is difficult to estimate.
The FinOps Moment
FinOps (Financial Operations) is a relatively new discipline for many organizations to help bring financial accountability to cloud spending by creating a partnership between engineering, finance, and business teams. It sounds obvious. Of course you should understand what you’re spending and why. But in practice, this is a cultural shift as much as a technical one.
In the old model, infrastructure was a capital expense managed by IT. Finance approved the budget once a year, IT spent it, and everyone moved on. In the cloud model, spending decisions are made by engineers every day, in real time, through the services they choose, the architectures they design, and the resources they provision. An engineer choosing between two database options is making a financial decision, whether they think of it that way or not. Spoiler alert: most don’t. And why would they? Nobody trained them to. Nobody gave them visibility into costs. Nobody made it part of their responsibility. We told engineers to move fast and build great things, and they did. We just forgot to mention the barkeep tracked consumption.
A Classic Cocktail
Clients that get a better handle on cloud costs aren’t doing anything revolutionary. They’re doing the basics, consistently. Which, as usual, turns out to be the hard part.
- Make costs visible to the people who create them. This is step one and it’s remarkable how few organizations do this. Give engineering teams a dashboard that shows their cloud spend in real time. Don’t just share a monthly report from finance that arrives three weeks after the fact. Real-time visibility. When a team can see that their dev environment costs $4K a month, behavior changes. When that number is buried in a consolidated invoice that nobody outside finance ever sees, it doesn’t.
- Assign cost ownership. Every cloud resource should have an owner. Every owner should know what their resources cost. Tag everything. If you can’t attribute a cost to a team, you can’t manage it. One client found that 30% of their cloud spend couldn’t be attributed to any team or project. Thirty percent. Seems more like a management problem than a cloud problem.
- Build cost into architecture decisions. The cheapest architecture isn’t always the best. Cost should be one of the variables in the design conversation, instead of a panicky afterthought six months later. Engineering teams tend to be smart and creative, making cost just another design constraint. I’ve seen teams redesign a data pipeline and cut costs by half without sacrificing performance just by being aware of cost impact.
- Right-size relentlessly. Most cloud resources are over-provisioned because it’s easier to start big than to tune later. Except “later” never comes. Right-sizing reviews, looking at actual utilization against provisioned capacity, are tedious and unglamorous yet highly effective. And you can always automate a good chunk of the work.
The Bigger Takeaway
Maybe the most interesting part about the cloud cost conversation is that it’s not really about cloud. It’s really about what happens when you distribute decision-making without distributing accountability. Cloud gave teams the power to provision infrastructure instantly. That’s transformative. At the same time, it shifted many small financial decisions from a centralized function that understood costs to distributed teams that understood technology. The capability moved. The financial literacy didn’t move with it.
So the drinks were never free. They were just small enough that nobody noticed. Maybe, I know this sounds like a questionable idea, but just hear me out: we should hire a good barkeep to manage the tab.
