What happens when your cloud bill grows faster than your revenue, and nobody can explain why? That question keeps a lot of finance and engineering leaders awake at night. The FinOps framework exists to answer it. It is a structured way to make cloud spending visible, understandable, and accountable, without slowing down the teams that build and run your products. (Cloud computing)
FinOps is short for Cloud Financial Management, and it treats cost as an engineering problem and a business metric at the same time. This article explains how the framework is built, how the lifecycle works, where teams usually stumble, and what progress realistically looks like.
What Is FinOps and Where Did It Come From?
The term FinOps was coined around 2019 and later trademarked, and the FinOps Foundation was founded the same year before becoming a project of the Linux Foundation. That lineage matters: FinOps grew out of practitioner communities rather than a vendor’s marketing department, which is why the framework reads like a field manual rather than a product pitch.
The FinOps Foundation defines FinOps as an operational framework and cultural practice that maximizes the business value of cloud, enables timely data-driven decisions, and creates financial accountability through collaboration between engineering, finance, and business teams. Read that definition twice. The word “collaboration” carries more weight than any spreadsheet or dashboard.
The core idea is simple. In a traditional data center, costs were lumpy and slow: you bought servers, depreciated them over years, and argued about next year’s budget. In the cloud, every engineering decision, from instance size to storage tier to container count, is a purchasing decision made in real time. FinOps exists to connect those decisions to financial outcomes without turning engineers into accountants.
The Three-Phase Lifecycle: Inform, Improve, Operate
The framework’s backbone is a continuous loop with three phases. Teams do not finish one and move on; they cycle through all three at different speeds for different workloads.
Inform
The Inform phase is about visibility. You need to know who spent what, on which service, for which product, and whether the spend delivered value. This is where most organizations discover uncomfortable truths: untagged resources, shared costs nobody owns, and a handful of workloads quietly consuming a third of the budget.
Practical tip: start with tagging discipline before buying any tool. A cost dashboard built on unreliable tags produces confident, wrong answers. The most common mistake teams make is skipping this step and jumping straight to optimization, then wondering why savings never stick.
Improve
The Improve phase covers rate reduction (commitments, savings plans, reserved capacity) and workload changes (rightsizing, shutting down idle resources, storage lifecycle policies, architecture changes). Rate reduction is fast and mechanical. Workload changes are slower and require engineering judgment.
A common trap here: teams chase commitment discounts before they understand their usage baseline, then get locked into commitments for workloads that shrink three months later. Discounts on waste are still waste.
Operate
The Operate phase is where the framework becomes a habit. It covers budgeting, forecasting, anomaly detection, policy enforcement, and the regular rhythm of reviews that keeps cost visible. This is also where governance lives: guardrails, approval flows, and automated responses to spend spikes.
Without Operate, the first two phases decay. Savings get reabsorbed, forecasts drift, and the organization slides back to reactive firefighting.
Domains, Capabilities, and the People Involved
The framework organizes work into domains and capabilities. The exact capability list has been revised over time, so teams should work from the current published version rather than a secondary summary. Broadly, the domains cover:
| Domain | What It Answers | Typical Capabilities |
|---|---|---|
| Understand usage and cost | Where does the money go? | Data ingestion, allocation, tagging, showback and chargeback |
| Quantify business value | Is the spend worth it? | Forecasting, budgeting, unit economics, benchmarking |
| Reduce usage and cost | How do we spend less for the same outcome? | Rate reduction, workload changes, licensing |
| Manage the FinOps practice | Who does what, and how do we improve? | Policy, governance, tooling, training, on-call processes |
The framework also defines personas: FinOps practitioners, engineering, finance, procurement, leadership, and product owners. Each persona has different responsibilities and different questions. An engineer wants to know which service is expensive and why. A product owner wants cost per customer. A CFO wants a forecast they can defend. The framework’s genius is giving all of them a shared vocabulary.
The Maturity Model: Crawl, Walk, Run
The FinOps Foundation publishes a maturity model with three stages: Crawl, Walk, and Run. The labels are deliberately unglamorous because they set expectations honestly.
In Crawl, teams get basic visibility, manual reporting, and ad hoc optimization. In Walk, allocation becomes reliable, forecasts appear, and optimization becomes a recurring process with named owners. In Run, automation handles anomaly response and policy enforcement, unit economics drive product decisions, and cost is embedded in engineering workflows.
Two practical observations from watching teams move through these stages. First, maturity is not uniform across an organization. A company can be at Run for its main platform and Crawl for a recently acquired business unit. Second, skipping stages backfires. Teams that jump to automated optimization without allocation discipline usually automate the wrong things. (News)
What the Survey Data Suggests
The Foundation’s annual State of FinOps survey has consistently found that reducing waste and improving cost visibility rank among the top priorities for respondents, while only a minority of organizations report fully automated cost optimization. That gap between ambition and automation is the practical reality for most teams: the work is still largely manual, and the biggest wins come from fundamentals rather than clever tooling.
That finding should be reassuring. It means you do not need a sophisticated platform to start. You need clean data, clear ownership, and a recurring conversation.
How FinOps Relates to Other Frameworks
FinOps does not exist in a vacuum. It overlaps with Technology Business Management (TBM), a discipline that maps technology costs to business services, typically for IT chargeback and portfolio decisions. TBM tends to look at the whole technology estate, including on-premises and labor. FinOps tends to focus on variable cloud spend and engineering behavior. Mature organizations often use both, with TBM providing the enterprise lens and FinOps providing the cloud-level detail.
FinOps also increasingly connects to GreenOps, which extends cost thinking to carbon and energy. The logic is straightforward: idle resources waste money and energy in the same way, so the same optimization work often serves both goals.
Practical Steps to Start Without Burning Out
Here is a sequence that works for most teams, based on what tends to go wrong when it is skipped.
- Pick one high-spend product or business unit. Do not attempt an enterprise-wide rollout first. Prove the model where the money is.
- Fix tagging for that scope only. Define a small tag schema (owner, product, environment, cost center) and enforce it at provisioning time, not after the fact.
- Build a single source of truth for cost data. One dashboard, agreed definitions, refreshed on a predictable schedule.
- Assign named owners. Unowned cost is invisible cost. Every workload needs a human attached to it.
- Establish a monthly review rhythm. Short, regular, and focused on decisions rather than reporting theater.
- Reduce rates only after you trust your baseline. Then layer in workload changes and, eventually, automation.
Common mistakes worth naming: treating FinOps as a finance-only project, building dashboards nobody uses, optimizing one-time costs while ignoring recurring ones, and celebrating savings that reappear next quarter because the underlying behavior never changed.
Building Culture Beyond the Dashboard
The hardest part of FinOps is not technical. It is convincing engineers that cost is a design constraint rather than an accounting nuisance, and convincing finance that cloud spend is variable by nature rather than a failure of control.
What actually works in practice: make cost visible where engineers already work, such as in pull requests and deployment pipelines. Give teams budget ownership with real autonomy. Celebrate good cost decisions publicly, beyond savings numbers. And keep the tone curious rather than punitive, because blame drives cost underground and underground cost is unmanageable cost. (Blog)
For teams that want to go deeper into practitioner perspectives and industry developments, the news section at 9481.org covers emerging practices, and the blog at 9481.org offers ongoing commentary on cloud financial management. Organizations building internal training programs sometimes contribute their own lessons through the editorial and contributor inquiries page at 9481.org. (Write for 9481.org)
Conclusion
The FinOps framework is not a product you buy or a project you finish. It is a loop: make cost visible, improve what matters, and build the operating habits that keep both happening. The lifecycle gives you a sequence, the domains give you scope, the personas give you accountability, and the maturity model gives you permission to start small.
Start with one product, fix the data, name the owners, and meet monthly. The organizations that succeed at cloud financial management are rarely the ones with the fanciest tooling. They are the ones that turned cost into a shared, recurring conversation and kept it going long after the initial enthusiasm faded.
Frequently Asked Questions
What is the FinOps framework in simple terms?
It is a structured approach to managing cloud costs. It combines a three-phase lifecycle (Inform, Improve, Operate) with defined capabilities and roles, so engineering, finance, and business teams can make spending decisions together using shared data.
Who owns FinOps in an organization?
There is no single owner. A central FinOps team usually runs the practice, but accountability is distributed: engineering owns workload decisions, finance owns forecasting and budgeting, procurement owns commitments and contracts, and leadership sets priorities. The framework’s persona model exists precisely because ownership is shared.
How long does it take to reach a mature FinOps practice?
It varies widely, but most organizations spend months rather than weeks moving from Crawl to Walk, and longer to reach Run. Progress is uneven across business units. The realistic goal is steady improvement in visibility and accountability, not a fixed timeline.
Do we need special tools to practice FinOps?
No. Native cloud provider cost tools plus a spreadsheet can carry a team through the Crawl stage. Third-party platforms help at scale, particularly for allocation, anomaly detection, and automation, but they amplify good practices and bad ones equally. Fix the process before buying the platform.
How is FinOps different from cost cutting?
Cost cutting is a one-time reduction. FinOps is a continuous practice that connects spend to business value. Sometimes the right answer is to spend more on a workload that drives revenue. The framework optimizes for value, not for the lowest possible bill.
Does FinOps apply outside the cloud?
The framework was built for variable cloud spend, but its principles, such as visibility, ownership, and unit economics, transfer to SaaS licensing, data platforms, and even on-premises capacity. Many organizations extend the same rhythms to any technology cost that varies with usage.
The framework also emphasizes iteration over perfection. Early allocation will be imperfect; tagging will have gaps; forecasts will miss. The practice improves through repeated cycles, not through a single flawless implementation. Teams that wait for complete data before acting rarely act at all. Equally, the framework is vendor-neutral by design, which means it describes what good looks like without prescribing specific platforms. That neutrality is a strength: it lets organizations adopt the lifecycle at their own pace and with their existing tools, then layer in automation as their processes mature. Finally, treat the framework as a living reference. The FinOps Foundation updates capabilities and guidance as cloud pricing models, AI workloads, and licensing structures evolve. Revisit the current published materials periodically rather than relying on an implementation you designed two years ago. The fundamentals endure; the details keep moving. (AWS Well-Architected Framework)
