The Multi-Cloud Blind Spot
This energy company was running workloads across three cloud providers simultaneously, AWS for compute, Azure for data services, and GCP for machine learning pipelines. Each provider had its own billing console, its own cost model, and its own definition of what a "resource" was. The finance team received three separate invoices each month and had no reliable way to reconcile them into a single view of how much the company was actually spending on cloud.
The underlying problem wasn't the cost itself, it was the absence of any causal link between spending and outcomes. Cloud costs were growing 40% year-on-year, but no single team could be held accountable because no single team could see their own spend. Developers provisioned resources without understanding the cost implications. Environments were left running over weekends. Oversized instances were never downsized because there was no workflow to prompt the question.
"We had a rough sense that cloud costs were too high, but we genuinely couldn't tell you which team was responsible for which part of the bill. The data just wasn't there."
, VP of Infrastructure (anonymised)
Our Approach: Make Cost a First-Class Signal
Most cloud cost projects start with rightsizing recommendations, find the wasteful instances and shrink them. We started somewhere different: making costs visible before trying to reduce them. The instinct to optimise without first establishing a baseline is one of the most common reasons FinOps programmes fail. Teams won't change behaviour around costs they can't see.
Our FinOps Governance implementation began with a unified cost visibility layer that ingested billing data from all three providers into a single schema. Every workload was tagged by team, environment, and service. Showback dashboards gave every engineering team a live view of their own spend, not an invoice, but a near-real-time breakdown of what was running and what it was costing.
Tagging Discipline as Infrastructure
Unified visibility is only as good as the tagging underneath it. We found that less than 40% of resources were correctly tagged when we started. The first month was largely spent building tagging enforcement: policy-as-code rules that blocked deployment of untagged resources and automatically raised issues for anything that slipped through.
Once tagging discipline was established, the showback dashboards became actionable. Teams could see that a staging environment left running over a three-day weekend cost more than a week of production traffic. That kind of visibility changes behaviour without any top-down mandate, engineers optimised voluntarily once they understood the numbers.
Rightsizing and Anomaly Detection
With visibility established, we moved to active optimisation. Rightsizing recommendations were generated weekly based on actual utilisation metrics, not estimates, but 30-day P95 CPU and memory profiles for every workload. The recommendations were surfaced in the showback dashboards with a one-click approval workflow: engineers could accept a recommendation and the resize happened automatically via infrastructure-as-code.
Anomaly alerting was added in month two. When a team's spend deviated more than 20% from its 30-day rolling average, an alert fired in Slack with a breakdown of which resources had changed. This caught three significant cost incidents before they reached the monthly invoice, including a misconfigured autoscaler that had silently provisioned 40 additional nodes over a weekend.
Reserved instances and savings plans were the third lever. For workloads with stable, predictable utilisation, we modelled the break-even point and generated purchasing recommendations. The finance team approved them against a clear cost-benefit model rather than a vague recommendation to "buy more reserved capacity."
The FinOps Culture Shift
The technical implementation was the easier half. The harder work was creating a FinOps culture where cost visibility was a shared responsibility rather than a finance team concern. We ran FinOps office hours in the first six weeks, not training sessions, but open forums where engineering teams could bring their dashboards and ask questions about specific line items.
Within three months, teams were raising cost efficiency improvements proactively. One team identified that their batch processing workloads could be moved to spot instances with minimal code changes, a saving that had nothing to do with our recommendations. That's what FinOps culture looks like when it actually works: engineers thinking about cost as naturally as they think about performance or reliability.
"The first time each team saw their own spend number, there was a moment of genuine surprise. Not because the number was shocking, but because it was the first time it had ever existed. You can't manage what you can't see."
, Head of Cloud Engineering (anonymised)
Results After Six Months
Six months after the FinOps programme launched:
- Cloud spend reduction: 30% average across all three providers
- Cost growth trajectory: 40% YoY → negative
- Tagging coverage: 40% → 97%
- Cost anomalies caught before invoice: 11 incidents
- Time from cost anomaly to resolution: down from weeks to hours
- Teams with active FinOps ownership: 100%