FinOps

What is FinOps?

FinOps is the practice of managing cloud spending as a shared responsibility between the people who run up the bill and the people who pay it. Engineering, finance, and the business sit at the same table, so the team spinning up servers can see what they cost and the team paying for them can see what they buy.

The name is a blend of "finance" and "DevOps", and it borrows the same idea from DevOps: a cost problem, like a reliability problem, is best solved by the engineers who create it having visibility and ownership, not by a finance report that lands a month too late to change anything.

The FinOps Foundation, the body that maintains the framework, defines it as an operational framework and cultural practice that maximises the business value of technology through collaboration between engineering, finance, and business teams. The goal is value, not just a smaller bill.

Why FinOps exists

On-premises IT was a capital purchase. You bought servers once, and the spending decision was made up front by a few people. Cloud flipped that. Now any engineer can provision resources with a line of code, spending is variable and continuous, and the bill only arrives after the money is already gone.

That model gives huge flexibility and is easy to lose control of. A forgotten test environment, an oversized database, or a query that scans far more data than it needs all quietly add up. FinOps is the discipline that puts visibility and accountability back into a spending model that otherwise has neither until the invoice lands.

The FinOps lifecycle

The FinOps Foundation describes the practice as three repeating phases.

Inform. Make spending visible and understandable. Allocate costs back to the teams, products, or customers that caused them, so a bill becomes a set of answerable questions instead of one big number.

Optimize. Act on what the visibility reveals. Rightsize oversized resources, shut down idle ones, and take advantage of pricing options like reservations or committed-use discounts.

Operate. Make it continuous. Set budgets, track cost against them, define policies, and build the habit so optimisation is not a one-off cleanup but part of how teams work.

Teams cycle through these phases constantly rather than finishing one and moving on to the next.

FinOps beyond cloud: data and AI

FinOps started with raw cloud infrastructure, but the same discipline now covers data platforms and AI. A warehouse billed per query, a lakehouse billed for compute, or a Microsoft Fabric tenant running on a purchased Fabric capacity (F-SKU) all share one trait: usage drives cost continuously, and without allocation you cannot tell which report or pipeline is expensive.

This is where FinOps overlaps with DataOps and data governance. Knowing which pipeline burns the most compute is a cost question and an engineering one at the same time, and the tagging and ownership that governance provides is exactly what cost allocation depends on.

AI has sharpened the point. Cheaper, more efficient models do not automatically mean lower bills, because cheaper compute invites far more of it, an effect known as the Jevons paradox. FinOps is how you notice that your total spend went up precisely because each call got cheaper.

What to watch out for with FinOps

Treating it as cost-cutting. FinOps is about value, not the lowest possible bill. Sometimes the right call is to spend more on something that earns more, and a team measured only on reducing spend will starve the things that matter.

Visibility with no action. A beautiful cost dashboard that nobody acts on is just overhead. The Inform phase only pays off if it feeds the Optimize one.

No cost allocation. If you cannot attribute spend to a team or product, you cannot create accountability, and untagged resources become a bill nobody owns.

Finance and engineering staying in silos. The whole point is collaboration. If finance sets budgets engineers never see and engineers spend numbers finance never understands, you have two silos, not FinOps.