Background: How FinOps Became a Discipline
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.
The Origins of the FinOps Foundation
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 Four Domains of the FinOps Framework
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.
Domain 1: Understand Cloud Usage and Cost
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.
Domain 2: Quantify Business Value
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.
Domain 3: Optimize Cloud Usage and Cost
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.
Domain 4: Manage the FinOps Practice
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 Five Personas
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 Crawl-Walk-Run Framework
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.