FinOps Best Practices: A Practical Playbook for 2026

FinOps playbook title card with sketched cloud-cost motifs

The FinOps practices that pay off most are the same few, done consistently: allocate every dollar to an owner, put cost data in front of engineers while it is still fresh, remove waste before buying discounts, commit to discounts only on stable workloads, and review spend on a fixed rhythm. Everything else, from tooling to Kubernetes tuning, builds on those habits. This guide walks through each one, shows how to sequence them, and ends with a 90-day plan you can start this quarter.

Nullbit

Make Technology Spend Work Harder

Nullbit builds custom software and AI solutions to help businesses address operational inefficiency and optimize decision-making.

Explore Nullbit

TL;DR

FinOps is a repeating cycle of Inform, Optimize and Operate, run jointly by engineering, finance and the business, not a one-time cost-cutting project.
Start with allocation: enforce tags or labels for owner, cost center and environment, because they cannot be applied retroactively.
Cut waste first (idle, oversized, unscheduled resources), then buy commitments for the usage that remains.
For Kubernetes, combine billing data, cluster metrics and ownership metadata before you rightsize anything, and protect performance with SLOs.
Mature one capability at a time using a crawl, walk, run approach instead of chasing a perfect score everywhere.

What FinOps is, and why a cycle beats a cleanup
The six principles behind every good practice
Best practice 1: Build allocation before you chase savings
Best practice 2: Make cost visible where engineers already work
Best practice 3: Remove waste before you buy discounts
Best practice 4: Commit to discounts on stable usage only
Best practice 5: Control Kubernetes cost without hurting performance
Best practice 6: Govern with a rhythm, not a policy binder
Who does what: roles that make FinOps run
Using the maturity model without gaming it
A 90-day plan to get started
Where outside help makes sense
How Nullbit can help
FAQ
Sources

What FinOps is, and why a cycle beats a cleanup

The FinOps Foundation describes the FinOps Framework as an operational framework and cultural practice that maximizes the business value of technology, supports timely data-driven decisions and creates financial accountability through collaboration between engineering, finance and business teams. The key word is collaboration. A finance team that only sees the invoice at month end cannot fix anything, and an engineering team that never sees the invoice has no reason to.

The framework organizes the work into three phases: Inform, Optimize and Operate. You understand and allocate spend, find efficiency and rate opportunities, then implement, govern and keep improving. Microsoft’s overview of the framework frames the same cycle as visibility and shared accountability, then waste reduction, then monitoring of KPIs and governance tied to business goals.

The phases are not a straight line. A team will be informing on a new product while optimizing an old one and operating a third. That is normal, and it is why the best practices below are written as habits rather than steps.

The six principles behind every good practice

The Foundation lists six core principles: teams collaborate, business value drives technology decisions, everyone owns their technology usage, FinOps data is accessible, timely and accurate, FinOps is enabled centrally, and organizations take advantage of the variable-cost model of the cloud.

Two of them change daily behavior more than the rest.

Everyone owns their usage. If the platform team pays for what product teams spin up, nobody feels the cost of a forgotten cluster. Ownership has to be assigned by name or team, and it has to show up in the data.

Data is timely. A cost report that arrives three weeks after the deploy that caused the spike teaches nothing. Daily visibility, shared with the people who can act on it, is a practice worth building early.

Best practice 1: Build allocation before you chase savings

Allocation is the foundation, and most stalled FinOps efforts skipped it. The Foundation’s guidance on cloud cost allocation is to use hierarchies, tags and labels to assign costs to owners, departments or projects for showback or chargeback. It also advises defining required metadata, such as cost center and environment, and enforcing it, because tags cannot be applied retroactively. Spend that happened before a resource was tagged stays unattributed.

A workable starting standard:

Pick four or five mandatory keys: owner, cost center, product or service, environment, and optionally data classification.
Enforce them at creation time with policy or infrastructure-as-code checks, not with a quarterly cleanup email.
Track the percentage of spend that is allocated and publish it as a KPI.
Decide what to do with shared costs such as networking, observability and platforms, and write the rule down. A proportional split by usage is easier to defend than an even split.
Start with showback (teams see their costs). Move to chargeback only when the allocation is trusted.

Google Cloud’s cost optimization guidance recommends billing reports, labels, custom dashboards, quotas, budgets and alerts for visibility, attribution and overspend control. The order matters: establish visibility and attribution, then find idle or low-value resources, then automate controls such as schedules, budgets and alerts.

Best practice 2: Make cost visible where engineers already work

Dashboards nobody opens do not change behavior. Put the numbers where decisions happen: in pull requests that change infrastructure, in sprint reviews, in on-call handoffs and in the weekly engineering sync.

Budgets and alerts per owner. Set a budget for each product or team and alert on both absolute thresholds and unusual daily movement.
Unit economics. Total spend rises with success, so it is a poor signal on its own. Cost per customer, per transaction or per thousand requests shows whether you are getting more efficient as you grow. The Foundation lists unit economics as part of the Inform phase for this reason.
Forecasts with a named owner. A forecast is useful when someone is accountable for explaining the gap between it and reality.

A small, honest dashboard with five metrics beats a sprawling one. Start with allocated spend percentage, month-to-date versus budget, top ten cost drivers, anomaly count and unit cost.

Best practice 3: Remove waste before you buy discounts

Buying a commitment on top of oversized infrastructure locks in the waste. The Foundation’s guidance on optimizing cloud usage suggests prioritizing high-spend categories, using native tools, removing unused resources, rightsizing compute, managing storage lifecycles, scheduling resources, using autoscaling, serverless or Spot where appropriate, minimizing inter-region transfers, tuning logging, and using infrastructure-as-code to shut down unused infrastructure.

A sensible order of attack:

Priority	Action	Typical owner	Risk
1	Delete unattached volumes, idle load balancers, orphaned snapshots	Platform	Low
2	Schedule non-production environments off at night and weekends	Engineering	Low
3	Rightsize over-provisioned compute and databases	Service owners	Medium
4	Apply storage lifecycle rules and tier cold data	Data / platform	Low to medium
5	Review cross-region and cross-zone traffic	Architecture	Medium
6	Tune log volume and retention	Observability	Low

The same guidance says to rank opportunities by savings potential, execution effort, urgency, risk and business goals, and to report outcomes to stakeholders. That last part is easy to skip. Saved money that nobody sees does not build the credibility you need for the harder work later.

Best practice 4: Commit to discounts on stable usage only

Once waste is under control, rate optimization pays. Microsoft’s Azure guidance says commitment discounts can save up to 72% versus list costs for eligible resources, in exchange for a defined term and a usage or spend commitment. The trade is flexibility for price, so the rule is simple: commit to the baseline you are confident you will still run, and leave the variable part on demand.

A few habits make commitments safer:

Tie commitments to workload lifecycles, not just usage trends. A steady line on a chart may belong to a service scheduled for retirement.
Layer them. Smaller, staggered purchases reduce the damage of one bad forecast.
Track coverage and utilization of commitments as separate KPIs.
Centralize the buying while teams keep ownership of their usage, which is the central enablement principle in practice.

AI workloads add a new wrinkle. GPU and inference capacity are often bought on long, inflexible terms, and demand is hard to predict. Teams that need to plan this spend can look at models such as reserved AI inference capacity, where compute is reserved for a chosen duration and performance requirement rather than paid for entirely at spot-market prices. Treat it with the same discipline as any commitment: size it to baseline demand and review it on a schedule.

For the commercial side, the finance team should be in the room when renewals are negotiated. Our guide on first-year AI costs and procurement benchmarks for CFOs covers how to frame those conversations.

Best practice 5: Control Kubernetes cost without hurting performance

Containers make allocation hard because many workloads share the same nodes. The Foundation notes that container cost allocation needs cloud billing data, Kubernetes metrics and workload metadata combined, since one-to-one mapping is not possible on shared infrastructure. It also says container costs should be managed alongside traditional cloud spend, using native or third-party tooling, rather than in a separate silo.

A practical sequence for clusters:

Allocate first. Combine the invoice with node and pod telemetry and namespace or label ownership. Without this, every later number is a guess.
Rightsize requests and limits. Requests set by habit, often copied from a template, are the most common source of idle capacity.
Improve bin packing and autoscaling. Better packing means fewer nodes carrying the same work.
Remove idle capacity and schedule non-production. Dev and test clusters rarely need to run at 3 a.m.
Use Spot or preemptible nodes only for interruption-tolerant work. Microsoft’s guidance recommends Spot VMs for AKS workloads that tolerate eviction, such as batch and dev/test, and states they are not suitable for every workload.
Guard performance. Define SLOs, set pod disruption budgets, keep capacity safeguards, and compare utilization and latency before and after each change.

What results can you expect? It varies by environment, and published numbers should be read that way. One academic study of a multi-cloud Kubernetes approach across four deployments over 24 weeks reported a 38.4% mean infrastructure cost reduction, 61% less idle node-hour waste and average node CPU utilization rising from 34% to 67%. Use that as a sign of what is possible, not a target.

Visibility tooling also helps. A University of Porto dissertation described an OpenCost-based framework that gave cluster, namespace, node and pod level visibility and predicted costs with a 1.46% mean absolute percentage error over 20 days on an Amazon EKS test cluster. It was a test cluster, so validate on your own workloads before you trust a forecast.

Rack-mounted compute nodes in a server room

Best practice 6: Govern with a rhythm, not a policy binder

Cloud cost governance is mostly about cadence and clear decision rights. Policies that live in a document nobody reads fail; guardrails built into the platform succeed.

Guardrails in code. Required tags, approved instance families, region restrictions and default shutdown schedules, enforced in pipelines.
A fixed review rhythm. A weekly anomaly check, a monthly review with service owners and finance, and a quarterly look at commitments and architecture.
Change management hooks. Ask for a cost estimate on significant architecture changes, and review the actual cost after launch.
Anomaly response with an owner. An alert is only useful when it routes to someone who can explain it within a day.
Exception paths. Teams will have valid reasons to break a rule. Make exceptions visible and time-boxed.

This work sits close to process design, and the same thinking applies. If you are formalizing how decisions get made across teams, our article on choosing and applying a process optimization framework can help.

Who does what: roles that make FinOps run

The Foundation says FinOps involves engineering, finance, product, business, procurement, leadership and FinOps practitioners. Practitioners educate, standardize and promote best practices, while a central function enables collaboration.

In a mid-sized company this usually looks like:

Role	What they own
Engineering leads	Rightsizing, architecture choices, tag compliance
Finance partner	Budgets, forecasts, accruals, commitment accounting
Product owners	Unit economics, trade-offs between cost and features
Procurement	Contract terms, marketplace purchases, renewals
FinOps practitioner or small team	Reporting, standards, education, opportunity backlog
Executive sponsor	Priorities, removing blockers

The skills worth hiring or building are a blend: enough cloud engineering to read an architecture, enough finance to explain amortization and forecasting, and the communication skill to get both groups to agree on a number.

Using the maturity model without gaming it

The Foundation’s maturity model uses a crawl, walk, run approach: start small, then grow in scale, scope and complexity as business value warrants. It also states that the goal should never be simply reaching Run in every capability. That is useful advice. Allocation may deserve Run maturity in a large organization, while a niche capability may be fine at Walk.

A simple way to use it:

List the capabilities that matter to you: allocation, anomaly management, forecasting, rate optimization, unit economics.
Score each as crawl, walk or run, honestly, with a short evidence note.
Pick the two with the best return and move only those up this quarter.
Re-score every six months.

A 90-day plan to get started

Days 1 to 30: Inform.

Agree on the mandatory tag or label set and start enforcing it on new resources.
Build a baseline: spend by product, environment and owner, with the unallocated share visible.
Name an executive sponsor and a FinOps lead, and schedule the monthly review.

Days 31 to 60: Optimize.

Clear the obvious waste: orphaned resources, idle environments, oversized instances.
Schedule non-production shutdowns.
For Kubernetes, allocate cluster costs and fix the worst requests and limits.
Keep a ranked backlog scored by savings, effort, urgency and risk.

Days 61 to 90: Operate.

Add budgets, anomaly alerts and owner routing.
Buy your first layer of commitments on baseline usage.
Publish unit cost for your top product.
Run the first quarterly review and re-score maturity.

Where outside help makes sense

Many teams can run the first 30 days alone. The slower parts are usually allocation design across several clouds, infrastructure-as-code guardrails, and re-architecting the workloads that are expensive by design. This is engineering work as much as finance work.

The Nullbit perspective

We see the same pattern in cloud cost work: the bill is a symptom of architecture and process decisions made months earlier. Tagging and dashboards help, but real savings come when cost is treated as a design constraint, next to reliability and security.

That is why we approach cloud infrastructure and system engineering as one problem. A technology-agnostic view lets us choose what fits the workload, whether that means serverless, containers or a plain virtual machine, instead of pushing one vendor’s catalog.

We also build automation into the operating model: schedules, policy checks and reporting that run without someone remembering to do them. Our focus is on measurable business results and transparency, so the first deliverable is usually a clear picture of where money goes and who owns it, before any optimization begins.

Migrations deserve special attention, because cost problems are often baked in at that moment. Our analysis of cloud migration cost shows how much of the total can be labor, which is a reason to plan the target state carefully.

Matija

How Nullbit can help

If your cloud bill is growing faster than your product, we can help you design the allocation model, automate the guardrails and re-architect the expensive parts. Our cloud infrastructure services cover AWS, Azure and GCP, and our system engineering work handles architecture and integration.

Nullbit

We publish how we engage on our cooperation page: an agile engagement from 5,000 to 40,000 EUR per month, or a fixed-price turnkey project from 5,000 to 60,000 EUR one-off. Smaller targeted automations, such as scheduled shutdowns and reporting pipelines, start from 3,000 EUR one-off on our AI automation page.

FAQ

What are the three phases of FinOps?

The phases are Inform, Optimize and Operate. Inform builds visibility and allocation, Optimize finds efficiency and rate savings, and Operate puts governance and continuous improvement in place. Teams cycle through them repeatedly rather than finishing one and moving on.

What are the six principles of FinOps?

Teams collaborate, business value drives technology decisions, everyone owns their technology usage, FinOps data is accessible, timely and accurate, FinOps is enabled centrally, and organizations take advantage of the variable-cost model of the cloud. They are published by the FinOps Foundation.

Where should a company start with cloud cost optimization?

Start with allocation: enforce tags or labels for owner, cost center and environment, and measure how much spend is unallocated. Then remove obvious waste and schedule non-production resources. Buy commitments only after that, on the baseline usage you are confident in.

Can we cut Kubernetes costs without risking performance?

Yes, if you change one thing at a time and measure. Allocate costs first, rightsize requests and limits, improve autoscaling and use Spot nodes only for interruption-tolerant workloads. Keep SLOs and disruption budgets in place, and compare latency and utilization before and after.

FinOps Best Practices: A Practical Playbook for 2026