FinOps Beyond the Bill

“Turn off the instances you’re not using.” If that were all it took to optimize cloud costs, there wouldn’t be an entire discipline dedicated to the topic. The reality is that most enterprises don’t have a spending problem — they have a visibility problem.

They don’t know what they have, who uses it, what it actually costs and whether it’s still needed. And without that visibility, any optimization attempt is a temporary patch.

The FinOps framework that works

A mature FinOps program has five pillars, and “reduce the bill” is just the outcome — not the objective.

1. Discovery: what you actually have

Before optimizing, you need to know what you have. And we’re not talking about running an aws ec2 describe-instances. We’re talking about a real inventory that answers:

• How many resources exist? VMs, containers, databases, storage, networking.
• How much of that is actually used? Average CPU at 5% is not “using” a resource.
• Who created it and why? If nobody knows who the owner is, probably nobody needs it.
• Does it have correct tags? Without tags, there’s no accountability.

The result of this phase is usually revealing. In our experience, between 20% and 35% of an enterprise’s cloud resources are oversized or outright orphaned.

2. Efficiency KPIs aligned to business

Technical metrics (CPU utilization, memory usage) are necessary but insufficient. FinOps KPIs must connect infrastructure consumption with business value:

• Cost per transaction: How much does it cost to process each operation?
• Cost per active customer: Does cost scale linearly with users or are there inefficiencies?
• Effective utilization ratio: Not just whether the CPU is busy, but whether it’s doing useful work.
• Over-provisioning cost: The difference between what you have and what you need, in dollars.

These KPIs enable business conversations, not technical ones. “We’re spending $50,000 on instances using 8% CPU” is more powerful than “we have low utilization.”

3. Systematic usage questioning

Once you have visibility, comes the uncomfortable part: questioning every resource.

• Why does this resource exist? If the answer is “it’s always been there,” it’s a candidate for removal.
• Who uses it? If it has no clear owner, you need to find one or decommission it.
• Is it still needed? Finished projects, abandoned test environments, data replicas nobody queries.
• Is it correctly sized? The instance was created two years ago for a load that’s already changed.

This process isn’t a one-time event. It’s a continuous practice that must be integrated into the team’s review cycles.

4. Allocation and reservation governance

Without governance, every team provisions whatever they want without accountability. Implementing governance doesn’t mean bureaucracy — it means clear rules:

• Per-team/project budgets with automatic alerts when exceeded.
• Approval policies for resources above a certain cost threshold.
• Mandatory tags on every resource: owner, project, environment, cost-center.
• Monthly reviews where each team justifies their consumption.

Tools like Kubecost (for Kubernetes) and each cloud’s native modules (AWS Cost Explorer, Azure Cost Management) make it possible to implement this without excessive friction.

5. Capacity Planning based on real data

Traditional capacity planning relies on optimistic projections that rarely hit the mark. FinOps-based capacity planning uses real data:

• Consumption trends from the last 3-6 months, not estimates.
• Seasonal patterns: Black Friday, fiscal year-end, peak season.
• New requirements: Sizing based on real benchmarks before provisioning.
• Growth scenarios: What happens if traffic grows 2x, 5x, 10x.

The goal isn’t to spend less — it’s to spend well. Sometimes capacity planning reveals you need more infrastructure, not less. But at least the decision is data-driven.

Prospecting support: sizing before provisioning

One of the most valuable aspects of a mature FinOps program is the ability to size new requirements before provisioning. Instead of “request 10 m5.xlarge instances because the last project used that,” the process is:

1. Define the SLAs and performance requirements of the new service.
2. Benchmark against similar existing workloads on the platform.
3. Conservative initial sizing with auto-scaling configured.
4. 30-day review to adjust based on actual usage.

This eliminates the preventive over-provisioning that is the main source of cloud waste.

The result: 40% less spend, not 40% less capacity

When we implemented this complete framework for a financial group, the result was a 40% reduction in annual cloud spending. Not because we eliminated capacity — but because we eliminated waste, optimized sizing and established governance that prevents re-accumulation.

The key is that the 40% savings were sustainable. It wasn’t a one-time cut that reverts in six months. The FinOps framework keeps operating, KPIs are reviewed monthly and every new requirement goes through the sizing process.

---

Want to know how much you could optimize? Request a free FinOps assessment and we’ll show you the concrete savings opportunities in your infrastructure.