Cloud cost optimization for CFOs has an uncomfortable pattern behind it: nearly every engagement produces a saving, and most of the saving is gone within two quarters.
The reason is not that the technical recommendations were wrong. It is that the behaviour producing the cost was never addressed, so the environment drifts back to where it started while everyone congratulates themselves on the percentage.
The structural problem behind cloud cost optimization for CFOs
Cloud spend is one of the few large expense lines in a modern company where finance has no visibility into the driver, no ability to forecast it, and no mechanism to attribute it to whoever caused it.
Engineering commits the spend through architectural decisions. Finance receives the invoice thirty days later. Nobody owns the variance. The conversation that follows is unproductive because neither party has what the other needs, finance cannot evaluate whether the spend was reasonable, and engineering cannot see the financial consequence of a design choice at the point of making it.
This is a governance gap wearing a technical costume, which is why tooling alone never fixes it.
Allocation before reduction
The instinct is to cut immediately, buy commitments, resize instances, delete unattached volumes. Some of that is worthwhile. It is not where the value is.
The value is in making the cost attributable. Until spend can be assigned to a product, a team, a customer segment or an environment, nobody can determine whether it is reasonable.
Consider two bills that both grew 40%. In the first, revenue grew 60% and the increase sits entirely in production compute for the fastest-growing product. In the second, the increase sits in a non-production environment nobody has logged into for four months. These require opposite responses and look identical without allocation.
Allocation work means: a tagging strategy reflecting how the business is actually managed; enforcement so untagged resources cannot be created; a defensible approach to shared costs that cannot be tagged; and mapping into the accounting structure so cloud cost appears in management reporting alongside everything else rather than as one opaque line.
Where the savings actually are
In approximate order of value per unit of effort:
Waste elimination. Non-production environments running overnight and at weekends, orphaned storage volumes, unattached IP addresses, forgotten test workloads, over-retained snapshots. Unglamorous, immediate, and frequently 10 to 20% of the bill on its own.
Rightsizing. Instances provisioned against a peak that never materialised. Needs sustained utilisation data over a meaningful period, not a point-in-time reading.
Commitment strategy. Reserved instances, savings plans and committed use discounts produce substantial reductions, and lock you in. Size them against a baseline you are genuinely confident in, not against current usage. An over-purchased three-year reservation for capacity you stop needing is a liability recognised over three years, and resellers have no incentive to raise that risk.
Storage tiering. Data on expensive storage untouched for a year, where lifecycle policies would move it automatically.
Architectural change. The largest savings and the largest effort. Worth pursuing only after the above, and only where the engineering cost is justified by a sustained reduction.
For an environment never actively managed, 20 to 35% is a common combined result. Be sceptical of anyone promising a specific percentage before seeing your bill.
Unit economics is the point
Total spend tells you almost nothing. Cost per customer, per transaction, per active user or per unit of output tells you whether the business scales.
Getting there needs the allocation work plus agreement on a denominator the business already recognises. Once it exists the questions become productive: is cost per customer improving as we grow, does the enterprise tier actually carry better unit economics than self-serve, and does this particular customer cost more to serve than they pay.
That last question occasionally produces uncomfortable answers about the largest accounts, which is precisely why it is worth asking.
A dashboard that serves both audiences
Most cloud cost dashboards are built for engineers and are unreadable to a CFO. Most finance dashboards aggregate cloud spend to one line and are useless to engineering. A working dashboard carries:
- Current spend against budget, with a forecast to period end
- Variance decomposed into rate, volume and new-workload components
- Allocation by team, product and environment
- Unit economics against the agreed denominator
- Commitment coverage and utilisation, an unused commitment is worse than no commitment
- A small number of anomaly alerts, tuned to catch a runaway resource within a day rather than at invoice time
Practically this is built on native provider tooling with an allocation layer and a reporting view aligned to the management accounts. A dedicated FinOps platform earns its licence above roughly $50,000 a month in spend and is unnecessary below it, and buying one before doing the tagging work simply produces the same unattributable numbers more attractively.
Making it durable
This is the part that determines whether the saving survives, and it is the part most cost optimisation vendors skip, because it produces no billable savings percentage.
The cost has to be visible to the people who create it, at the point they create it, with an owner accountable for it. In practice: showback or chargeback to teams; cost estimation as part of architectural review rather than after deployment; budget alerts routed to the team rather than to finance; and a standing forum where engineering and finance look at the same numbers.
Engineers are sometimes assumed to be indifferent to cost. In practice they make sensible decisions almost immediately once they can see it; the problem has rarely been unwillingness, it has been that the information was never available to them.
One overlap worth exploiting
A cloud cost engagement and a cloud security assessment begin with exactly the same task: building an accurate inventory of accounts, subscriptions and workloads. Both routinely find infrastructure nobody knew existed.
An untracked workload is simultaneously an unmanaged cost and an unmanaged attack surface. Running the two engagements together shares the discovery phase, costs meaningfully less than running them separately, and (usefully) makes the case to management more persuasive as one issue than as two. The FinOps service page sets out how this is scoped.
Javed Peeran
Licensed by the California Board of Accountancy and the author of every article published here. Thirty years of practice covering external audit of banks, insurers and mortgage companies, fifteen years as CFO and Corporate Controller inside technology companies, and IT governance and security compliance work spanning SOX 404, SOC 1 and SOC 2, ISO 27001, FISMA, FedRAMP, PCI DSS, HIPAA/HITECH, CCPA and GDPR, plus Oracle ERP migrations and, more recently, generative-AI audit automation.
