A comprehensive guide to the FinOps maturity model — from foundational cost visibility to advanced cloud financial management. Written for engineers and finance leaders who need a practical roadmap, not theory.
No card. No drip campaign. One email with the PDF.
Structured so you can jump to the chapter that matters most.
Talvinder leads engineering and product at Zop.Dev, focused on multi-cloud automation and the autonomous cost-optimization platform. He writes about FinOps maturity, platform engineering, and what actually works at scale.
Why we wrote this guide — and how to use it without skimming.
A comprehensive guide to the FinOps maturity model — from foundational cost visibility to advanced cloud financial management.
This book is organized into chapters that progressively build your understanding of the topic. Each chapter is self-contained but references concepts from earlier chapters where relevant.
Where every cloud bill goes wrong: the four root causes behind 60%+ waste.
Cloud spending crossed $669 billion globally in 2024. By 2026, analysts project it will exceed $840 billion. That growth rate would be exciting if organizations were getting full value from every dollar. Most are not.
The Flexera 2025 State of the Cloud Report found that 84% of organizations cite cloud spending as their top challenge. More pointedly, 78% of organizations estimate that 21 to 50% of their cloud spend is wasted. A Harness report put the number at $44.5 billion in preventable waste in 2025 alone.
This is not a budgeting problem. It is a visibility, accountability, and culture problem. And it is exactly what FinOps was designed to solve.
FinOps is not a tool. It is not a software category or a vendor pitch. The FinOps Foundation, the governing body that defines the practice, describes it as a cultural practice that enables organizations to get maximum business value from their cloud investments by bringing engineering, finance, and business teams together around a shared model of cloud accountability.
The word itself is a contraction of “Finance” and “DevOps.” That etymology matters. FinOps borrows DevOps’ core principle: break down silos between teams that need to work together, establish shared ownership, and build feedback loops that make decisions faster and better.
In cloud cost management, those silos between engineering and finance are expensive. Engineering teams build and scale without cost context. Finance teams receive cloud invoices they cannot decode. Neither team can act effectively without the other. FinOps creates the bridge.
Before examining how organizations improve their FinOps maturity, it is worth pausing on why this problem is so persistent.
Cloud cost waste does not come from carelessness alone. It comes from the structural disconnect between how cloud resources are provisioned and how financial decisions are made in most organizations. In traditional IT, procurement was a deliberate, slow process. Buying a server required purchase orders, approvals, and delivery timelines. The friction itself enforced discipline.
Cloud removed that friction entirely. An engineer can provision $50,000 worth of compute in minutes, often without any approval. That same engineer is rarely accountable for what the instance costs when idle at 3 AM on a Sunday. The provisioning decision and the cost consequence are separated by organizational distance.
The result: idle compute resources account for 35% of cloud waste. Overprovisioned instances account for another 25%. A 2024 State of Cloud Cost Intelligence Report found that only 30% of surveyed organizations knew exactly where their cloud budget was going.
The FinOps Foundation developed the FinOps Maturity Model to give organizations a structured path forward. It is not a certification or a one-time assessment. It is a continuous improvement framework.
The model organizes FinOps capabilities across four domains: understanding cloud usage and cost, quantifying business value, optimizing cloud usage and cost, and managing the FinOps practice itself. Within those domains sit 22 distinct capabilities, and each capability can be practiced at three maturity levels.
Those three levels are Crawl, Walk, and Run.
Crawl is where most organizations begin. Costs are tracked reactively. Tagging is inconsistent. Accountability is unclear. The finance team gets a monthly invoice and nobody in engineering feels responsible for it.
Walk is where cost optimization becomes an active practice. Teams start using the visibility from Crawl to take action. Budget controls go in. Rightsizing recommendations get implemented. Cross-functional meetings between finance and engineering happen regularly.
Run is where cloud cost is woven into architecture decisions before code ships, not after invoices arrive. Optimization is automated. Unit economics connect cloud spend to business outcomes. Cost avoidance is measured alongside cost reduction.
This book is organized to take you through each dimension of that journey.
The Background chapter explains the history of how FinOps emerged as a discipline and how the FinOps Foundation codified the framework. It covers the four domains in detail and introduces the personas who make FinOps work.
The Analysis chapter examines each maturity stage in depth. What does Crawl actually look like inside an organization? What are the failure modes that keep teams stuck there? What does the transition to Walk require? What separates Walk from Run? This chapter provides the diagnostic lens to understand where an organization stands and what holds it back.
The Case Studies chapter draws on documented examples: WPP saving $2 million in three months and reaching a 30% annual cost reduction, a global insurer uncovering $17 million in annual savings, and an adtech company cutting AWS costs by 62%. These are not hypothetical scenarios. They are repeatable patterns with identifiable causes.
The Conclusion chapter synthesizes the key principles and offers a practical starting framework.
Before diving in, one principle from the FinOps Foundation deserves emphasis. It is counterintuitive and important.
The goal of the FinOps Maturity Model is not to reach Run stage across all capabilities. The FinOps Foundation explicitly states this: “There are no runners.” Getting to Run is not the goal, and it is not the finish line.
The goal is to practice each capability at the maturity level appropriate for your specific environment, team size, and business context. A startup with three engineers and a single AWS account does not need the same level of FinOps sophistication as a Fortune 500 company running workloads across AWS, Azure, and GCP.
Maturity is not a competition. It is a calibration.
That calibration, done well, is how organizations stop losing 30% of their cloud budget to waste and start directing that money toward the workloads that actually move the business forward.
How FinOps moved from a slack channel to a board-level function in five years.
Cloud computing did not arrive with a cost management framework attached. For most of the 2010s, organizations adopted cloud primarily to gain speed and scale. The cost implications came later, often as a shock.
The early pattern was predictable. A company migrates workloads to AWS or Azure. The first few months feel like a win: no more capital expenditure, no data center procurement cycles, teams shipping faster. Then the monthly bills start growing. Then they start growing faster than the engineering headcount that explains them. By the time finance escalates the issue, the cloud environment has sprawled into something nobody fully understands.
This pattern repeated itself across industries throughout the 2010s. The companies that avoided it were not more disciplined by default. They built intentional processes to connect cloud resource decisions to financial accountability.
In 2019, a group of practitioners who had been managing cloud costs at scale decided to formalize what they had learned. They founded the FinOps Foundation under the Linux Foundation with a specific mandate: define the practice of FinOps, establish shared language and frameworks, and build the professional community around it.
The Foundation published the first version of the FinOps Framework in 2020. That framework has been updated continuously since. The 2024 revision was the most significant since launch: it consolidated the framework from six domains to four, updated the capability definitions, expanded the personas model, and formally recognized AI-related cloud spend management as a FinOps responsibility.
Today, 75% of Forbes Global 2000 companies have adopted some form of financial operations for cloud. A dedicated FinOps team now exists in 59% of organizations, up from 51% the prior year. The practice has moved from early adopter to mainstream in under five years.
The 2024 FinOps Framework organizes all cloud cost management activity into four domains. Each domain represents a distinct category of work that organizations must do to manage cloud costs effectively.
This is the foundation. Before an organization can optimize anything, it needs to know what it is spending, where, and why. This domain covers cost visibility, tagging and labeling, and cost allocation.
Cost allocation is particularly important. Cloud costs need to be mapped to the business units, teams, applications, and projects that generate them. Without that mapping, cloud invoices are organizational noise. Nobody knows which team owns which spend, and nobody feels accountable for reducing it.
Tagging is the technical mechanism that enables allocation. Every cloud resource should carry metadata that identifies its owner, purpose, environment (production vs. development), and cost center. Organizations that invest in a disciplined tagging taxonomy in the Crawl stage see disproportionate returns in every subsequent capability.
This domain emerged from merging two older framework capabilities: Performance Tracking and Benchmarking, and Real-Time Decision Making. The unifying theme is translating cloud cost data into business language.
The key concept here is unit economics. Rather than tracking total cloud spend in absolute dollars, mature FinOps practices measure cost per customer, cost per transaction, or cost per unit of whatever metric the business uses to measure growth. When engineering can tell the business that serving each paying customer costs $2.40 per month in cloud infrastructure, and that number has dropped from $3.10 over the past two quarters, cloud cost becomes a business conversation rather than an IT cost center argument.
This domain covers the actual work of reducing waste and improving efficiency. It was created by merging Cloud Rate Optimization and Cloud Usage Optimization.
The distinction between rate optimization and usage optimization matters. Rate optimization is about paying less for the same usage: negotiating enterprise discounts, purchasing reserved instances for predictable workloads, using savings plans. Usage optimization is about using less: rightsizing overprovisioned VMs, shutting down development environments outside working hours, eliminating zombie resources that were never decommissioned.
Both levers are necessary. Organizations that focus only on rate optimization often find that usage growth outpaces their discount savings within a year.
This domain covers the organizational and cultural side of FinOps: building the team, establishing governance, creating the feedback loops that make the practice self-sustaining, and integrating FinOps into engineering workflows and financial planning processes.
This is where most FinOps initiatives stall. The technical capabilities in Domains 1 through 3 are learnable. The organizational change required in Domain 4 is harder. Getting engineering teams to accept cost accountability alongside performance and reliability accountability requires cultural shifts that tools alone cannot create.
The FinOps Framework identifies five personas whose participation is required for an effective FinOps practice. The framework is explicit: FinOps is not a job that belongs to one team. It is a shared responsibility model.
| Persona | Primary Role | FinOps Responsibility |
|---|---|---|
| FinOps Practitioner | Dedicated specialist | Connects finance, engineering, and leadership around shared cost accountability |
| Finance | Budget and accounting | Translates cloud costs into financial planning, chargeback, and forecasting models |
| Engineering | Infrastructure and product | Implements optimization recommendations, builds cost awareness into architecture decisions |
| Leadership (CFO/CTO) | Strategic oversight | Sets cost governance expectations, resolves cross-functional priority conflicts |
| Product | Product strategy | Connects cloud spend to product unit economics and business outcomes |
The FinOps Practitioner sits at the center of this model. This person is not necessarily the one doing all the optimization work. They are the connective tissue: the person who makes sure finance understands what engineering is building, engineering understands the cost impact of their architecture choices, and leadership has the information needed to make investment decisions.
In small organizations, one person may cover the entire FinOps Practitioner role alongside other responsibilities. In large enterprises with multi-cloud environments spanning dozens of teams, a FinOps team of four to six specialists is typical.
The maturity model is the FinOps Foundation’s answer to a common question: where do we start? The three-stage framework provides a practical progression that organizations can navigate at their own pace.
The critical design principle: the stages are not a race. Organizations are expected to be at different maturity levels for different capabilities simultaneously. A company might be at Run stage for cost allocation while still at Crawl stage for unit economics. Both are normal.
The Crawl stage is characterized by reactive visibility. Organizations know they have a cloud cost problem but lack the data, processes, and accountability structures to address it systematically.
The Walk stage is characterized by active optimization. The visibility foundation from Crawl is in place. Teams are using that visibility to take action: rightsizing instances, setting budgets, running regular cost reviews. The shift from reactive to proactive is the defining characteristic of this transition.
The Run stage is characterized by embedded cost governance. Cloud cost is factored into architecture decisions before code ships. Optimization is automated. Unit economics connect every dollar of cloud spend to a business outcome.
The FinOps Foundation emphasizes one principle above all others in the maturity model: the goal is not to achieve Run stage everywhere. The goal is to operate each capability at the level that delivers the most value for your specific environment, team size, and business context. Appropriate maturity beats theoretical maximum maturity every time.
Crawl, walk, run — what teams actually do at each maturity stage, with concrete tells.
The Crawl-Walk-Run framework is easy to understand in the abstract. Most FinOps teams find it harder to apply to their own organization. When asked “where are you on the maturity model?” the instinctive answer is usually Walk, regardless of actual capability level.
This chapter provides the diagnostic lens to assess honestly. It examines each maturity stage in depth: the specific characteristics that define it, the failure modes that keep organizations stuck there, and the concrete changes required to progress.
Crawl is not the same as having no FinOps practice. Most organizations that are genuinely at Crawl stage have cloud dashboards, someone who looks at the bills, and occasional conversations about costs when a budget alert fires. What they lack is the infrastructure for systematic action.
The defining characteristics of Crawl stage break down into three categories: visibility gaps, accountability gaps, and process gaps.
The 2024 State of Cloud Cost Intelligence Report found that only 30% of organizations knew exactly where their cloud budget was going. The other 70% had a total number but not the breakdown that would allow them to act. When $2 million in cloud spend cannot be attributed to specific teams, projects, or applications, every optimization conversation becomes an argument about ownership rather than a technical discussion about waste.
In Crawl stage, cloud cost is typically owned by a single person or team (often DevOps or a central platform team) who cannot actually control what other teams spend. Engineering teams deploy resources; the platform team gets the bill; nobody in engineering feels direct financial pressure. The person accountable for the cost is not the person making the resource decisions.
Cost reviews happen when something goes wrong, not on a regular cadence. Budget alerts are set on total spend rather than per-team or per-application baselines. Tagging policies exist in documentation but are not enforced at deploy time.
Organizations remain in Crawl longer than they need to because the business pain is diffuse. Nobody gets fired when cloud costs grow 30% if revenue is also growing 30%. The reckoning comes later, often when growth slows, when a competitor demonstrates better margins, or when a board begins asking unit economics questions that the CFO cannot answer.
The transition from Crawl to Walk is not a single event. It is a series of capability upgrades, typically spread over six to eighteen months, that collectively shift the FinOps practice from reactive to proactive.
The most reliable signal that an organization has reached Walk stage is this: when a cloud cost anomaly is detected, the team responsible for it is notified directly and expected to act within a defined SLA. Accountability has been distributed.
Cost allocation is functional. Tagging coverage is above 80% for all production resources. Cloud costs can be viewed by team, by application, and by environment. The monthly cloud bill is not a surprise to anyone.
Budget controls are active. Teams have defined budgets. Alerts fire when spend approaches those budgets, and the right people receive those alerts. A new instance that would push a team over budget requires a conversation, not just a provisioning command.
Rightsizing is happening regularly. The organization has identified and acted on the most obvious waste: unused instances, oversized VMs, development environments running 24/7. Not everything is optimized, but the largest items have been addressed.
Cross-functional collaboration exists. Finance and engineering have a regular meeting, however informal. There is shared language around cloud costs. Finance is not receiving invoices it cannot decode; engineering is not building in a cost vacuum.
| Capability | Crawl | Walk |
|---|---|---|
| Cost allocation | Total spend visible, no attribution | Spend attributed by team and application |
| Tagging | Policy exists, low coverage | 80%+ coverage, enforced at deploy |
| Budget controls | Total budget alerts only | Per-team budgets with ownership |
| Rightsizing | Ad hoc, triggered by alerts | Regular review cadence, most waste addressed |
| Cross-functional collaboration | Finance reviews invoice alone | Regular joint cost reviews with engineering |
| Savings plans | None or opportunistic | Basic reserved instances for stable workloads |
Organizations that reach Walk stage often stall there because the remaining optimization opportunities are harder than the ones they have already captured. The easy wins, the idle instances and the obviously oversized VMs, have been addressed. What remains requires architectural decisions, not just configuration changes.
The team that rightsized 40 VMs last quarter feels like it has done its job. The next opportunity, redesigning a monolithic service so it can run on spot instances, requires engineering commitment and product planning. Without leadership support for that kind of investment, Walk organizations plateau.
Run stage organizations look fundamentally different from Walk stage organizations. The difference is not the sophistication of their tooling. It is where cost accountability sits in the engineering process.
At Walk stage, cost reviews happen after deployment. At Run stage, cost is a design constraint that shapes architecture decisions before the first line of code is committed.
In Run stage, engineering teams receive cost impact data as part of their normal workflow. Infrastructure changes trigger cost impact estimates. Pull requests that would increase estimated monthly spend by more than a defined threshold require FinOps review. Cost is not an afterthought; it is a gate.
The most time-consuming optimization tasks are automated. Unused resources are flagged and decommissioned automatically after a review period. Development and staging environments that are not in active use are shut down on a schedule. Rightsizing recommendations are generated continuously and acted on without manual triage.
Run stage organizations can answer the question: what does it cost to serve one customer, process one transaction, or deliver one unit of our core business metric? They can answer it for today, and they can show a trend over time. When that cost per unit is rising, engineering and product teams are alerted and expected to investigate.
Cloud spend forecasts are accurate to within 10%. They are based on a combination of historical trends and planned feature development, not just a straight-line extrapolation of last quarter’s spend. Finance can plan against these forecasts with confidence.
Run stage is often described as the pinnacle of FinOps maturity. The FinOps Foundation pushes back on this framing. Run stage in one capability does not mean Run stage everywhere. And reaching Run does not mean staying there without effort.
Organizations that achieve Run-level cost allocation may still be at Crawl for AI spend management. A team that has fully automated rightsizing for compute may have no governance over data transfer costs. The model is not a staircase with a top step. It is a continuous improvement framework across 22 distinct capabilities.
The practical implication: organizations should identify the capabilities that create the most value for their specific context and invest in maturing those first. A company where data egress costs represent 40% of the cloud bill should prioritize data transfer governance before rightsizing compute. The maturity model is a tool for prioritization, not a checklist to complete in sequence.
Three production case studies: B2B SaaS, marketplace, and AI inference platform.
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 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.
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.
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.
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.
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.
A 90-day roadmap to move up one maturity stage without slowing engineering.
The numbers are consistent across sources and years. Cloud waste runs at 27 to 35% of total spend. Organizations that implement structured FinOps practices capture 20 to 62% cost reductions, depending on how long the environment has been ungoverned and how disciplined the implementation is. Deloitte projected that $21 billion in cloud savings will be captured by companies using FinOps tools and practices in 2025 alone.
These are not outlier results from exceptional teams with exceptional budgets. They are repeatable outcomes from a framework that is now well-documented, well-tooled, and well-supported by a growing professional community.
What separates organizations that capture these savings from those that continue to overpay is not knowledge. Most engineering and finance leaders know cloud costs are too high. It is the organizational infrastructure to act on that knowledge systematically.
Looking across the case studies and the maturity model framework, five principles consistently differentiate organizations that build durable FinOps practices from those that cycle through cost-cutting initiatives that do not stick.
The goal of cloud cost management is not to have a dashboard. It is to have a dashboard that drives behavior. Organizations that treat visibility as the end state of their FinOps practice accumulate reporting infrastructure without changing how engineering teams make decisions.
Visibility is complete when every team can see its own cloud spend in near real time, understands what is driving it, and knows what actions they can take to influence it.
A central FinOps team cannot optimize a cloud environment at scale. They can identify opportunities, but only the teams who build and operate the services can act on them sustainably. The FinOps Practitioner role is most effective as a facilitator and educator, not as an optimizer.
Organizations that try to run FinOps as a centralized cost-cutting function hit a ceiling at Walk stage. The remaining optimization opportunities require engineering ownership that centralized teams cannot manufacture.
Every cloud environment that has operated for two or more years without structured FinOps governance contains significant waste that can be eliminated without engineering effort. Unused reserved instances, zombie resources, and oversized development environments are almost always present. These quick wins typically represent 15 to 25% of total spend.
Capturing those wins early, in the first 90 days of a FinOps initiative, creates the financial and organizational justification to fund the harder, longer-term work. Leadership support for FinOps is much easier to maintain when the program has already demonstrated concrete savings.
One-time rightsizing exercises do not stay rightsized. Development environments that are scheduled to shut down outside working hours will be provisioned again during a crunch period and forgotten. Reserved instance coverage that is manually managed will drift as the environment changes.
The difference between Walk and Run is largely automation. Run-stage practices are characterized by optimization rules that execute without human intervention, enforcement policies that catch violations before they become costs, and alerting systems that route anomalies directly to the engineers who can act on them.
The ultimate measure of FinOps maturity is not cost reduction in absolute dollars. It is the ability to answer the question: are we getting increasing business value from our cloud investment over time?
Unit economics provide that answer. When a company can track cost per customer, cost per transaction, or cost per API call over time, cloud spend becomes a business performance metric rather than a budget variance. That shift changes the organizational conversation from “why is the cloud bill so high?” to “is our cost-to-serve improving at the rate our business model requires?”
For teams beginning or restarting their FinOps journey, the following 90-day framework reflects the pattern common to successful implementations:
This framework is deliberately minimal. It does not require new tooling purchases, architectural redesigns, or organization restructuring. It requires data collection, communication, and the willingness to assign ownership to things that were previously unowned.
The FinOps Foundation’s 2025 State of FinOps report noted that 63% of FinOps teams are now using their practices to manage AI-related cloud spend, up from 31% the prior year. That 100% growth rate in a single year reflects the pattern of every previous cloud adoption wave: technology adoption outpaces cost management adoption, and then the bill arrives.
Organizations that have already built FinOps maturity across their traditional compute and storage workloads are better positioned to govern AI spend as it grows. They have the tagging policies, the accountability structures, and the unit economics frameworks that apply to GPU instances and foundation model API calls as directly as they apply to virtual machines.
Organizations that are starting their FinOps journey now are not late. The FinOps Foundation’s data shows that even organizations with multi-year cloud environments still find 20 to 40% waste when they apply structured analysis for the first time. The opportunity is there regardless of when the journey begins.
The maturity model is not a destination. It is a way of thinking about cloud cost management as a continuous practice: measure where you are, identify the capability that would deliver the most value if improved, invest in improving it, and measure again.
Organizations that apply that thinking consistently tend to end up in a similar place: spending significantly less on cloud, understanding significantly more about the business value they are getting from it, and building the engineering culture where cost-aware architecture is a professional standard rather than an external mandate.
The goal is not to finish. It is to improve.
See. Find. Fix. Automatic.
Connect your first cloud account in under 5 minutes. See your first remediation in under 7. No credit card required.
We'll send the download link to your inbox.
Check your inbox