Every FinOps team has sat through some version of the same meeting. Someone pulls up the monthly cloud bill, points at a spike, and asks who spun up the oversized instance that's been running since March. Nobody in the room quite knows. The instance gets killed. Three months later, a nearly identical instance shows up somewhere else, and the meeting repeats itself.
That's not a FinOps failure. That's FinOps working exactly as designed, which is the problem.
Traditional FinOps runs on billing data, and billing data is a police report, not a security camera. It tells you what already happened, days or weeks after the fact, once the damage is fully priced and non-refundable. You can build gorgeous dashboards on top of that data. You still can't stop next month's spike with it, because by the time you're looking at the number, the resource that caused it might already be gone, replaced by an equally unmonitored one.
Isn't that just the cost of decentralization, you might ask? You gave every team self-service access to the cloud specifically so they wouldn't have to file a ticket and wait a week. Some drift is the price of that speed.
Sure, but "some drift" isn't the same as "no visibility into the drift until the invoice arrives." And that's exactly the gap platform engineering closes, almost as a side effect of doing its actual job.
Here's why. A platform that provisions environments from git-defined configs sees every deployment before it happens, not after. That single fact changes what's possible in four concrete ways.
First, cost visibility stops being retroactive. Since the platform is the thing doing the deploying, it can attribute cost to a team or environment in near real time, not thirty days later when the bill lands.
Second, rightsizing stops being a one-time cleanup project. Today, most rightsizing work gets undone by drift within a quarter, because nothing stops the oversized instance from coming back. A platform can make rightsizing a deploy-time requirement instead of a policy nobody enforces. Try to deploy an instance size above the approved list, and the platform simply says no.
Third, idle spend stops depending on someone remembering to turn things off. A test environment that only needs to run business hours can be scheduled to spin down every night and every weekend, automatically, without anyone filing a request or setting a calendar reminder they'll ignore.
Fourth, and this is the one everybody underrates: tagging finally stops being aspirational. A tagging strategy is only as good as the person applying it by hand, which is to say it's usually terrible. Make the tag a required field at the point of self-service deployment instead of a best practice in a wiki nobody reads, and suddenly your cost reports have the team-level attribution you always wanted and never actually had.
None of this replaces FinOps. It just moves FinOps upstream, from "here's what you did wrong last month" to "here's what you're not allowed to do right now." I'd argue that's the only version of FinOps that was ever going to survive contact with a self-service cloud. A finance team emailing a spreadsheet once a quarter never stood a chance against a platform enforcing policy on every single deploy.
So if your FinOps program still lives entirely in a dashboard and a Slack channel that fires off after the bill closes, you already know what the next quarterly meeting looks like. Might be time to let the platform take the first swing, before the meeting happens instead of after.
Source: The New Stack, "How Platform Engineering Is Disrupting FinOps," by David Williams.
