Case Studies: FinOps Maturity in Practice
Theory and framework are necessary. They provide the vocabulary and the map. But the most useful question in FinOps is not “what does the framework say?” It is “what did that team actually do, and what did it cost to get there?”
This chapter examines documented FinOps implementations across industries. The numbers are from published reports and press releases. The patterns, what made them work and what nearly derailed them, are consistent enough across cases to treat as reliable signals.
WPP: From Crawl to Run in Two Years
WPP is one of the world’s largest advertising holding companies. When they began their FinOps journey, they were operating cloud workloads across dozens of agencies, each with its own AWS accounts, billing structures, and engineering teams. The result was classic enterprise sprawl: high spend, low visibility, and no shared accountability model.
Their starting point was Crawl. A central team could see total cloud spend across the organization, but attribution to individual agencies and projects was manual and error-prone. Engineering teams provisioned resources without cost context. Finance received invoices but had no mechanism to connect those invoices to business outcomes.
The intervention. WPP deployed a FinOps Practitioner function that worked across agencies to establish consistent tagging, centralize cost visibility, and build per-agency accountability structures. The first three months focused exclusively on Domain 1: understanding cloud usage and cost. No optimization, no savings initiatives. Just data.
The result. Within three months of the initial deployment, WPP had saved $2 million. Not through architectural changes or complex optimization programs. Through eliminating waste that had been invisible: idle instances, orphaned storage, development environments running continuously in production accounts.
The savings scaled. WPP achieved a 30% annual reduction in cloud spend, sustained over multiple years. That sustained reduction is the important number. One-time cost cuts are easy to find in a cloud environment with no prior governance. Sustained improvement requires the cultural and process changes that define Walk and Run stage maturity.
The lesson. Visibility alone generates savings. Before WPP had implemented a single optimization initiative, simply knowing what was running and who owned it created enough accountability pressure to eliminate 30% of waste.
Global Insurer: $17 Million in Annual Savings
A large global insurance company engaged a cloud optimization practice after cloud costs had grown significantly faster than revenue for three consecutive years. Their environment combined AWS, Azure, and a significant on-premises footprint, with inconsistent governance across business units in different geographies.
The assessment found that the organization was firmly in Crawl stage across most capabilities. Tagging coverage was below 40%. Cost allocation was done manually by matching resource names to project lists, a process that took two weeks per quarter and was still inaccurate. Engineering teams in different regions had no visibility into each other’s spend patterns and no shared optimization practices.
The intervention. The team identified $17 million in annual savings potential across three categories:
Rate optimization: $6 million in quick wins from unused reserved instances that had been purchased but not applied, and committed use discounts that had expired without renewal. These savings required no engineering work.
Usage optimization: $8 million from rightsizing, scheduling, and eliminating 340 zombie resources (instances and volumes that had not been accessed in more than 90 days but were still incurring costs).
Architectural optimization: $3 million from consolidating overlapping services that had been built independently by different regional teams.
The $6 million quick win. The immediate wins deserve particular attention. They came entirely from rate optimization failures: commitments that had been purchased and then forgotten, discount programs that had been enrolled and then left unmanaged. This is a Crawl-stage failure pattern. The organization had spent money on cloud discounts but had no process to ensure those discounts were being applied or renewed.
The lesson. In organizations that have been running cloud workloads for several years without structured FinOps practices, there are almost always rate optimization failures that represent immediate, zero-engineering-effort savings. Auditing existing commitments before any optimization program begins is consistently one of the highest-ROI activities in an early FinOps engagement.
Adtech Company: 62% AWS Cost Reduction
A fast-growing advertising technology company built its platform on AWS and scaled rapidly through a period of high growth. Like many high-growth startups, the priority was shipping features, not optimizing infrastructure. By the time the cloud bill attracted board-level attention, the environment had accumulated several years of ungoverned provisioning decisions.
The assessment found three primary waste categories:
Test data accumulation: The engineering team had built comprehensive test suites that generated and stored large amounts of test data in S3. This data had never been deleted. Terabytes of test data, generating storage and egress costs, had accumulated over several years. Elimination of this test data alone reduced storage costs by 28%.
Overprovisioned instances: Analysis showed that the median CPU utilization across production instances was 12%. Instances had been provisioned based on peak load assumptions, not actual utilization patterns. Rightsizing to match actual P95 utilization requirements reduced compute costs by 31%.
Unoptimized usage patterns: Several services that served traffic with a clear weekday pattern were running at full capacity 24/7. Implementing scheduled scaling reduced the cost of these services by 40% with no impact on user-facing performance.
Combined, these three interventions reduced AWS costs by 62%. The company went from Crawl to Walk stage in six months.
The data point that matters. The 62% reduction came without any architectural redesign. No services were rewritten. No databases were migrated. Every saving came from applying existing AWS optimization mechanisms to a cloud environment that had been built without any cost governance. This is the defining characteristic of the Crawl-to-Walk transition: most of the value is captured by fixing configuration decisions, not by redesigning the system.
IT Consulting Firm: 43% Multi-Cloud Cost Reduction
An IT consulting firm managing cloud environments for its own operations across GCP and Azure faced a different challenge. Unlike the previous examples, they had engineering expertise in abundance. The problem was not visibility or technical knowledge. It was process.
Different practice areas within the firm managed their own cloud environments with minimal coordination. A machine learning practice was running GPU instances continuously for training jobs that ran for 4 hours per day. A data engineering practice had built a GCP environment that mirrored its Azure environment because the team lead preferred GCP. A software development practice was running development environments continuously and had never implemented any scheduling.
The intervention focused on process standardization rather than technical optimization.
Dynamic scaling policies were implemented across all compute environments, with default scale-to-zero for non-production workloads outside defined hours. The ML practice’s GPU instances were scheduled to terminate after job completion and provision on demand for the next training run.
The duplicate GCP and Azure environments were consolidated after a multi-team review that produced a clear architectural decision: GCP for ML workloads, Azure for everything else. The duplication had persisted because there was no organizational mechanism to make and enforce cross-team decisions.
A chargeback model was implemented that allocated cloud costs directly to the project and client that generated them. Within two months, project managers were asking engineering teams for cost estimates before approving infrastructure changes.
The result. 43% cost reduction on GCP and Azure combined. More importantly, the chargeback model created durable accountability that made the savings self-sustaining. When cloud costs affect project margins, project managers enforce cost discipline without being told to.
The lesson. In technically sophisticated organizations, FinOps adoption often stalls not because the engineering team lacks the knowledge to optimize, but because there is no organizational mechanism to create accountability or coordinate cross-team decisions. The maturity model’s Domain 4, managing the FinOps practice, is not a technical problem. It is an organizational design problem.
Patterns Across Successful Implementations
Analyzing these cases alongside the broader FinOps Foundation case study library reveals consistent patterns in how successful FinOps implementations work.
| Pattern | What It Looks Like | Why It Matters |
|---|---|---|
| Visibility before optimization | First 30-90 days focused entirely on tagging and allocation, no optimization initiatives | Organizations that skip visibility and go straight to optimization find themselves implementing changes with no baseline to measure against |
| Quick wins fund the program | Early savings from rate optimization and zombie resources cover the cost of the FinOps practice | Creates business case sustainability without requiring leadership to fund an ongoing cost center |
| Accountability distribution is the hard part | Engineering team resistance to cost accountability is the most common implementation failure | Tools create visibility but culture creates accountability; the two require different interventions |
| Chargeback accelerates behavior change | When cost is visible at the team or project level, optimization behavior emerges without mandates | Engineers who see their own spend change their behavior faster than engineers who receive optimization recommendations from a central team |
| Sustained savings require automation | One-time savings from manual cleanup do not persist without automated governance | Three months after a rightsizing exercise, without automation, utilization patterns return to baseline |
The organizations that reach and sustain Run-stage maturity are not the ones with the best tooling. They are the ones that figured out how to make cloud cost a native part of how engineering teams think about their work.