Right-sizing is not FinOps
When a FinOps engagement starts, the first thing most teams do is run a right-sizing analysis. They identify over-provisioned EC2 instances, idle RDS databases, and orphaned EBS volumes. They switch on Reserved Instance coverage. They eliminate waste. In a large AWS footprint, this typically produces savings of 20–40% — often millions of dollars annually.
Then the programme ends. Six months later, cloud spend has crept back toward where it was. New workloads have been provisioned without any size discipline. Reserved Instance coverage has drifted. Nobody knows which team owns the $80,000-per-month data warehouse cluster that appeared in the billing console last quarter.
The three layers of cloud cost governance
Right-sizing is a point-in-time intervention. It saves money once. The governance layer — the policies, processes, and tooling that prevent overspend from returning — is what most FinOps programmes never build.
Cloud cost governance has three distinct layers. The first is visibility: you need to know what you are spending, on what, and who owns it. This requires a mandatory tagging standard applied consistently across all resources, a billing data pipeline that links spend to teams and products, and a showback or chargeback mechanism that makes cost visible to the people making provisioning decisions.
The second layer is accountability: the teams who provision resources need to own the cost of those resources. This means embedding cost metrics into engineering team OKRs, requiring cost estimates as part of architecture review, and running monthly cost reviews at the team level — not just in a central cloud centre of excellence that nobody else reads.
The third layer is commitment management: as the footprint matures, Savings Plans and Reserved Instances need to be managed actively, not purchased once and forgotten. Coverage analysis, utilisation monitoring, and a quarterly commitment review process are the mechanics. Without them, commitment coverage drifts down as workloads change and the discount benefit erodes.
Why teams stop at layer one
Most teams build layer one and stop. Visibility dashboards get created. Tagging standards get documented. Then the programme ends, the consultant leaves, and the dashboards sit unread because nobody is accountable for acting on them.
The reason teams stop at layer one is usually organisational, not technical. Building layer two requires changing engineering culture — getting developers to care about the cost of the infrastructure they provision. That is a harder conversation than deploying a cost management platform. Layer three requires active management of financial instruments, which most engineering teams are not set up to do.
Both layers require the FinOps function to have ongoing organisational authority — the ability to push back on provisioning decisions, require architecture reviews for high-cost workloads, and escalate when teams ignore cost alerts. Without that authority, FinOps becomes a reporting function rather than a governance function.
Building the governance layer
Building the governance layer starts with making cost visible at the point of decision. The most effective intervention we have seen is requiring engineers to see a cost estimate before they provision any resource above a threshold — in the same tool they use to provision infrastructure. When the cost of a choice is visible at the moment of choice, the choice changes.
The second step is running showback at the team level, not the account level. A team that sees 'cloud spend: $47,000 this month, up 23% from last month, driven by three new RDS instances in the analytics environment' will act. A team that sees a cross-account billing report will not.
The third step is building commitment management into a recurring process rather than an annual project. Quarterly Savings Plan reviews, a defined owner for RI coverage targets, and a documented escalation path when coverage falls below threshold. This is unglamorous work — but it is the difference between a FinOps programme that saves money once and one that compounds savings over time.