The ease of deploying cloud infrastructure has shifted much of the problem from provisioning to financial management. Spinning up virtual machines, Kubernetes clusters, storage, databases, or AI services can take minutes; figuring out afterward who is using them, what they actually cost, and what value they produce is considerably harder. That’s where FinOps comes in — a discipline that tries to factor cost into technical decisions before the bill becomes a surprise.
FinOps and cloud spending key points in 30 seconds
- 85% of organizations consider cloud cost management one of their top challenges, and estimate 29% of IaaS and PaaS spending goes to waste.
- FinOps combines engineering, finance, and business to connect technology consumption with value.
- Rightsizing, tagging, budgets, usage commitments, and eliminating idle resources remain basic practices.
- The next step is unit economics: measuring cost per customer, transaction, service, or even AI token.
- Stable infrastructure also calls for comparing public, private, dedicated, and hybrid cloud models before trying to optimize a poorly chosen architecture.
The situation is particularly striking because companies have been working on optimization for years. Flexera’s State of the Cloud 2026 report, based on 753 cloud professionals and decision-makers, puts the average estimate of wasted IaaS and PaaS spend at 29%, after five years of decline. On top of that, 85% cite spend management as one of their biggest problems — ahead even of security, cited by 82%.
That waste is adding up fast: global cloud spending has already topped €875 billion, with AI increasingly blamed for driving unnecessary spend.
AI is making the equation even more complicated. GPUs, inference, storage, APIs, vector databases, and new PaaS services all bring different units of consumption than the traditional ones. The bill no longer depends solely on how many virtual machines stay powered on.
That’s why FinOps is evolving from simple savings toward a far more useful question: what is the company getting in exchange for the money it spends on technology?
FinOps starts before the bill arrives
The FinOps Foundation currently defines its framework around capabilities that include understanding usage and cost, quantifying business value, and optimizing both consumption and price. These include planning, forecasting, budgeting, KPIs, unit economics, architecture, workload placement, licensing, and sustainability.
This changes how the problem should be read.
A €100,000 monthly cloud bill isn’t necessarily worse than a €70,000 one. If the first supports ten times more customers, transactions, or revenue, it can represent a more cost-efficient infrastructure.
Hence the importance of unit economics.
Instead of asking only how much AWS, Azure, Google Cloud, a private cloud, or a Kubernetes platform costs, an organization can measure indicators such as cost per customer, order, transaction, virtual machine, API served, or service delivered.
The FinOps Foundation specifically includes Unit Economics as a capability for connecting technology usage and cost with the value produced by an organization’s services and activities.
The trend is already showing up at companies. According to Flexera, the share of organizations using unit economics metrics rose from 40% to 49% in a year.
That’s a meaningful difference.
Cutting cloud spend by 10% can look like a win. But if doing so increases latency, hurts availability, or throttles a growing product, the supposed savings can destroy more value than they create.
Visibility: knowing who is spending
Before optimizing, you need to be able to attribute consumption.
That requires a consistent policy around tags, accounts, projects, owners, and cost centers. A resource should, at minimum, be able to answer basic questions: who is responsible for it, which application it belongs to, which environment it runs in, and which business unit is paying for it.
Manual tagging tends to decay quickly. That’s why more mature organizations build these rules into provisioning and infrastructure as code.
The absence of an owner is, in fact, an especially useful signal. A virtual machine, volume, snapshot, IP address, or load balancer that nobody recognizes deserves review regardless of how small its individual cost looks.
The problem shows up through accumulation.
Rightsizing: paying for what you actually need
Another classic practice is rightsizing — matching allocated resources to actual consumption.
A machine with 32 vCPUs and 128 GB of RAM that consistently uses only a small fraction of that capacity may be oversized.
But sizing shouldn’t be cut based solely on average CPU usage, either.
You need to factor in memory, storage, IOPS, bandwidth, latency, demand spikes, capacity reservations, high-availability requirements, and operating margin.
A database may use little CPU while depending heavily on memory and storage. A service might sit nearly idle for hours and then multiply its load for a few minutes.
FinOps therefore needs technical metrics, not just billing data.
Forgotten resources still show up on the bill
Idle infrastructure takes many forms: development machines running overnight and on weekends, disks left over after an instance is deleted, old snapshots, unused public IPs, empty load balancers, oversized clusters, or test environments nobody remembers creating.
In these cases, savings can come simply from removing what no longer serves any purpose.
It’s also worth reviewing storage. Active data, backups, historical records, and long-term archives don’t necessarily need the same storage tier or performance.
And some costs go more unnoticed: cross-zone and cross-region transfer, egress, NAT gateways, observability, support, commercial licenses, or managed services priced by number of requests.
An infrastructure bill is a lot more than CPU and RAM.
Kubernetes and AI complicate the math
Kubernetes is a perfect example of the new cost problem.
A bill can show how much a set of nodes costs, but a company needs to know how much of that belongs to each namespace, application, team, or customer.
Open-source projects like OpenCost provide a provider-agnostic methodology for measuring and allocating infrastructure and container costs within Kubernetes.
AI takes this problem a step further.
OpenCost 1.121.0, released in August 2026, added capabilities aimed at tying Kubernetes costs to inference workloads. Its integration with llm-d and vLLM makes it possible to get closer to metrics like cost per model and per token, factoring in actual resource utilization.
This is where a particularly useful distinction comes in: cost of availability versus cost of utilization.
A language model loaded onto a GPU can be ready to respond immediately while also spending long stretches with very little activity. Even when it isn’t producing tokens, it keeps GPU memory and capacity occupied, and that still has a cost.
That spend can be perfectly reasonable if the application needs very low latency.
What matters for FinOps is making it visible.
An AI platform could end up measuring how much it costs to keep each model available, how much each million tokens processed actually costs, and how much comes from idle capacity kept around to guarantee certain response times.
It’s a clear example of why optimizing costs doesn’t always mean minimizing resources. Flexera’s own AI division has already built tools along these lines, rolling out FinOps capabilities aimed specifically at managing tokens, agents, data, and compute for AI workloads.
The best FinOps move can also be changing your architecture
There’s a question that should be asked even before rightsizing:
is each workload running on the right infrastructure model?
Pay-as-you-go has clear advantages when demand is unpredictable. An application that needs to multiply its capacity for a few hours can benefit enormously from elasticity.
The picture changes for a workload that keeps roughly the same resources running 24/7 for years.
An enterprise database, an ERP, a virtualization cluster, or a stable internal platform can justify comparing the real cost of public cloud against private cloud, dedicated servers, owned infrastructure, or hybrid architectures.
The comparison shouldn’t be reduced to the price of a vCPU, either.
It needs to include storage, traffic, licensing, support, backups, redundancy, operations, staffing, security, disaster recovery, and the cost of idle capacity.
Flexera specifically notes that, among migration challenges, the economic comparison between on-premises infrastructure and cloud is gaining weight, as organizations try to bring cost into architectural decisions earlier — a practice known as shift-left FinOps.
This points to something important: an organization can do a flawless rightsizing job and still overpay if the starting architecture doesn’t match how the workload actually behaves.
The reverse can also happen. Moving a variable application to fixed infrastructure purely because the monthly cost looks lower can force it to be oversized to cover its peaks.
FinOps should help decide which model fits each workload, not champion one of them by default.
From showback to economic accountability
Cost attribution can also change the relationship between departments.
With showback, each team knows how much it consumes even though the budget stays centralized. A department might discover its environments cost €18,000 a month even though the bill continues to be paid out of IT.
Chargeback goes a step further: those costs get charged to the corresponding budget.
Both models can change behavior because they bring the technical decision closer to its financial consequence.
But the attribution has to be reliable. If a shared platform serves twenty applications, arbitrarily splitting its cost among them can produce indicators that look precise but aren’t very useful.
Unit economics tries to solve the next stage of this.
An e-commerce company might measure infrastructure cost per order. A SaaS platform, cost per active customer. An AI application, cost per conversation or per million tokens. An internal platform, cost per environment or service.
That way you can tell the difference between spending more because the business is growing and spending more because the infrastructure is less efficient.
AI opens a new front for FinOps
2026 data shows why this issue is only going to grow in importance.
58% of Flexera’s respondents already use generative AI services in public cloud, and the share of wasted IaaS and PaaS spend has climbed back up to 29%.
Another Flexera study focused on technology asset management found that only 31% of organizations say they have visibility into their AI software, while 59% say AI-related wasted spend increased over the past year.
This raises new questions for infrastructure teams.
How much does each model actually cost? Which GPU is underutilized? Is it worth keeping a model loaded to cut latency? Is it cheaper to use an external API or run your own inference? Which department is generating the tokens? How much does each request cost once you add up GPU, storage, network, and platform?
These are FinOps problems even though they no longer look much like reviewing a virtual-machine bill.
The discipline is evolving because the infrastructure is evolving too.
The end goal remains fairly simple: making sure cost stops being discovered after the technical decision has already been made.
When architecture, engineering, operations, business, and finance can all know in advance how much a decision will cost and later measure the value it produces, FinOps stops being a periodic campaign to trim the bill.
It becomes part of how infrastructure is designed.
Frequently asked questions
What is FinOps?
FinOps is a management practice that connects technology consumption with its cost and the value it delivers to the organization. It requires collaboration between engineering, operations, finance, and business, and isn’t limited to cutting the cloud bill.
What cloud costs should be reviewed besides CPU and memory?
Storage, snapshots, data transfer, egress, IP addresses, load balancers, managed services, observability, support, and licensing can all account for a meaningful share. In Kubernetes and AI, it’s also important to attribute shared capacity and GPUs to specific applications, teams, and models.
What is unit economics in FinOps?
It means connecting technology cost to a unit that matters to the business. Examples include cost per customer, transaction, order, service, AI conversation, or million tokens processed.
Does FinOps apply to private cloud and data centers too?
Yes. The current FinOps framework focuses on the value of technology and can be used to compare different infrastructure models. A mature decision can combine public, private, and dedicated cloud with owned resources based on elasticity, utilization, technical requirements, and total cost.
