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.
Costs were growing 40% year-on-year with no underlying signal of why. There was no team-level attribution, no anomaly detection, no FinOps practice. Engineering decisions that drove cloud cost were made without anyone seeing the financial impact. By the time a cost spike showed up on the monthly invoice, the workload that caused it had already been running unchecked for weeks.
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.
The first six weeks of the engagement were spent building the visibility layer. We unified billing data from all three providers into a single warehouse, built showback dashboards by team and product, and instrumented every active workload with mandatory tagging that mapped resources to cost centres. Tagging was enforced at provisioning, not requested in documentation.
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.
Alongside rightsizing, we deployed an anomaly detection layer. Cost spikes that exceeded a workload's historical baseline by more than two standard deviations triggered automated alerts to the responsible team within four hours, not at the end of the month when the invoice arrived. The team owned both the alert and the response. Finance didn't need to escalate, the team that caused the spike was the team that fixed it.
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.
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)
By month three, cloud spend had become a regular agenda item in team retrospectives. By month six, it was a delivery KPI tracked alongside velocity and reliability. The cultural shift was the durable outcome, the savings were just the visible expression of it.
Results After Six Months
Six months after the FinOps programme launched:
- Average cloud savings: 30%
- Cost growth: +40% YoY → negative (first time in three years)
- Cost attribution: 100% of workloads tagged to a team
- Anomaly detection: real-time (was: end of month)
- Engineering teams reviewing cost weekly: 0 → all of them
The Wider Lesson
Cloud cost is not a finance problem. It's an engineering signal that gets miscategorised as a finance problem because it shows up on an invoice. The teams that get cloud cost under control are the ones who treat it as a first-class engineering concern, alongside latency and uptime, rather than a periodic clean-up exercise.
The 30% saving wasn't the goal. It was what happened automatically once cost became visible to the people who could actually do something about it.