Three years ago, our board approved a FinOps initiative with a clear mandate: get cloud spend under control. We hired a FinOps engineer, subscribed to a cost visibility platform, and held quarterly reviews with engineering leads. By every internal metric, the program was a success — dashboards looked great, tagging compliance hit 94%, and we had beautiful Sankey diagrams showing cost attribution by team.
Then our cloud bill went up 34% year-over-year anyway.
This is not an unusual story. Across the Series B and C companies I talk to, I keep seeing the same pattern: FinOps programs that generate tremendous visibility without generating proportionate reduction. Understanding why requires being honest about what most FinOps programs actually optimize for — and what they systematically ignore.
The Showback vs. Chargeback Gap
Most companies implement showback: teams can see what they are spending, but the cost hits a central budget. Chargeback — where each team’s P&L or departmental budget is directly debited — is politically harder and operationally messier, so it gets deferred indefinitely.
The problem is that showback without financial consequence has roughly the same effect on behavior as a calorie counter app with no impact on what food is available in your house. Engineers look at the dashboard, feel vaguely guilty, and move on. In my experience, teams on showback models reduce discretionary waste by about 8-12%. Teams on chargeback models — where their manager’s budget is on the line — reduce waste by 25-40%. The delta is entirely behavioral, not technical.
The transition is painful. You need cross-functional buy-in, clear cost allocation rules (what happens to shared infrastructure?), and finance systems that can actually handle the chargebacks. Most companies never get there. We are still negotiating ours after 18 months.
The Hidden Cost Layers Nobody Talks About
FinOps tooling has gotten very good at compute visibility. EC2, GKE node pools, RDS instances — these are well-instrumented and well-understood. But two categories consistently escape scrutiny:
Data egress is the cockroach of cloud costs. It hides everywhere, it is almost never tagged properly, and it scales non-linearly with product growth. We had a data pipeline that was moving 40TB/month across regions “for redundancy” — a decision made in 2022 that nobody had revisited. That single unreviewed architectural decision cost us $47,000 in 2025. Egress is often 12-18% of total cloud spend at data-heavy companies, and it rarely shows up in the top-10 cost driver lists because it is fragmented across dozens of services.
AI inference is now the dominant shock vector for 2025-2026 bills. The unit economics of LLM calls are genuinely hard to forecast — token counts vary by user input, model versions change pricing, and “we will add AI features” translates to costs that scale faster than revenue in the early stages. We budget for AI inference as a separate line item now, with a hard monthly cap and an alerting threshold at 70% of cap. Without that, a single feature launch can blow a monthly budget in a week.
Reserved Instances, Savings Plans, and the Commitment Trap
The RI/SP decision is genuinely difficult, and the cloud providers do not make it simpler. At any given time we are evaluating:
- 1-year vs. 3-year RIs (30% vs. 55% discount, but 3-year commitments are terrifying when your architecture is in flux)
- Compute Savings Plans vs. EC2 Instance Savings Plans (flexibility vs. discount depth)
- Spot instances for fault-tolerant workloads (up to 90% discount, but you need mature interruption handling)
The decision fatigue is real. We have a spreadsheet that is 14 tabs long and requires a finance person and an infrastructure engineer to update together. Most quarters, we make suboptimal decisions simply because nobody had the bandwidth to do the full analysis. The tooling vendors promise to automate this, but in practice their recommendations require significant human judgment to validate.
What Mature FinOps Actually Looks Like
The companies I have seen do this well share a few characteristics:
-
Unit economics, not absolute spend. They track cost per API call, cost per active user, cost per transaction — not just total cloud bill. A rising cloud bill is fine if unit costs are flat or declining and revenue is growing. A flat cloud bill is a disaster if unit costs are rising because of inefficiency.
-
Engineering ownership with financial visibility in the developer workflow. Not a separate dashboard that engineers check monthly — costs visible in the same tools engineers use daily.
-
Architectural cost reviews as a first-class process. New features go through a cost estimation step before approval, not after launch.
-
Committed spend managed like a treasury function. RI and SP commitments are managed with the same discipline as debt — tracked, reviewed, and optimized on a fixed schedule.
We are probably at maturity level 2 of 4 on this scale. The gap between “we have FinOps” and “FinOps is actually changing our spend trajectory” is wider than most CFOs realize when they approve the initiative. The tools are necessary but not sufficient. The hard part is organizational, not technical — and that part takes years, not quarters.