Hey everyone. The State of FinOps 2026 report is out: the sixth annual survey, 1,192 respondents, more than $83 billion in annual cloud spend represented. I want to walk through what the numbers are telling us and why they matter if you're working anywhere near Kubernetes infrastructure.
Whether you're on an infrastructure team, a software team, or leading one, it doesn't matter. At the end of the day, no matter how advanced the systems we build, there's one truth that overrides everything: none of it matters when the company is bleeding money. And the cost cuts that follow tend to hit in ways you might not expect.
What unchecked cloud cost does
When cloud costs go unchecked, the impact shows up from multiple directions:
- From the employer's side: budget problems. To keep margins healthy, cuts start showing up in other areas: perks, events, team activities, and sometimes even raises.
- From the employee's side: you won't see the cloud bill, but you'll feel what it causes. Budget constraints push good engineering practices to a lower priority. Tooling gets deprioritized, tech debt compounds, and the improvements you know are possible keep getting pushed to next quarter. It blocks potential that could have been even better.
- From the cloud itself: cloud is genuinely fantastic. The shared responsibility model takes a massive amount of operational overhead off your plate, and the pay-as-you-go model lets businesses move fast. But that same flexibility has a flip side. If you're not actively optimizing, if you're provisioning generously and nobody's watching the bill, it will catch up with you. Cloud doesn't punish you upfront. It lets you run, and then the invoice arrives.
Where cost optimization happens
So where does the waste actually come from? There are several areas where you can potentially optimize costs across your infrastructure (on-premise, cloud, or hybrid):
- Over-provisioned containers
- Idle workloads
- Orphaned resources
- Under-utilized node groups
- On-demand instance types when spot would work
- Data transfer costs (egress, cross-AZ)
- Idle GPU workloads
<!-- callout:note -->We plan to cover these topics in two series: a FinOps Framework series that walks through the framework conceptually, and a Kubernetes Cost Optimization series that goes deep into the technical practices, from workload rightsizing to node group optimization.
Why FinOps became this important
Your Kubernetes cluster scales beautifully. Your costs don't. That gap is exactly what the FinOps Framework exists to close, and it's a framework I personally follow closely. The functions that drive Kubeadapt are built around it. The adoption curve is accelerating, and it's not hard to see why.
A cost optimization tool's core value isn't just about showing you potential optimization opportunities. Reporting alone (cost dashboards) can be extremely valuable. Why? Companies don't just want to see their IT infrastructure costs. They want to see the developer's license fees, the HR system's internal tool costs, and a whole range of other external costs, all inside the tools that adopt the FinOps framework. Why? Because by using these as long-term reporting tools, they can reshape their budgeting strategies: where to invest, how to invest, and whether they've managed to turn waste into a reusable resource.
Before FinOps, managing all this was painful because there was no shared framework. Each role had its own spreadsheets, its own dashboards, its own version of the truth. Now, with FinOps as the common language, CFOs, CTOs, and power-users such as Platform or DevOps engineers can all get their different needs met from the same framework. The cost we used to be blind to is now gradually becoming part of one or more stages of the development lifecycle, alongside cost optimization products.
Key numbers from State of FinOps 2026
The biggest shift is AI. The share of respondents managing AI spend went from 31% to 98% in two years (report). The pressure behind it is simple: optimize what you already run so you can afford what comes next. Many organizations report being asked to fund their AI investments out of optimization savings.
FinOps isn't just about cloud anymore, either. The scope has expanded well beyond the cloud bill:
- 90% manage SaaS costs or plan to in the coming year (think Slack, Jira, Datadog)
- 64% manage software licensing
- 57% manage private cloud, 48% data centers
- 28% are starting to include labor costs
(All from the report's technology categories section.)
It's becoming the entire technology spend.
The easy wins are mostly gone. In the report's words, teams "have hit the 'big rocks' of waste and now face a high volume of smaller opportunities that require more effort to capture" (priorities). The conversation is shifting from "how do we cut costs" to "are we getting value from what we spend?" Unit economics (cost per customer, cost per transaction) is moving to the foreground.
78% of FinOps teams now report to the CTO or CIO, up 18% since 2023. Teams with VP-level or higher engagement report 2-4x more influence over technology selection (teams): which cloud provider to use, where to run workloads, which services to adopt. That's a different level of impact from a few years ago.
Then there's shift-left. Pre-deployment architecture costing came up as one of the most wanted tool capabilities. Teams want engineers to estimate costs before deploying. "If we build this architecture, how much will it cost per month?" Great idea, but there's a real measurement problem. Say a developer catches an over-provisioned request in a PR and drops CPU from 4 cores to 1. That saves $300/month. But the wasteful version never hit production, so the saving doesn't show up anywhere. No cost went down because the cost never went up. The evidence disappears the moment the fix happens. That's a gap most teams don't have an answer for yet.
What ties it together: organizations managing more than $100M a year average 8-10 FinOps practitioners plus 3-10 contractors. They don't scale by hiring more. They scale by setting central standards and relying on federated champions across the organization.
The FinOps Foundation also changed its mission from "Advancing the people who manage the value of cloud" to "Advancing the people who manage the value of technology." That says a lot about where this is heading.
The scaling problem
FinOps teams are small: about ten practitioners even at the largest spenders, and at some companies they don't exist at all. Even where they do, scaling FinOps across IT is not something ten people can pull off. Because the optimization here, especially optimization that doesn't degrade performance, requires expertise across multiple layers. From workload optimization to node group optimization. Even if you find people with the right skills, applying these improvements with ten people across a company of 500, 1,000 or 2,000 engineers is very hard.
Two approaches to managing this
1. Full automation
Automating the optimization processes end-to-end. There are vendors in the market doing this. You'll probably come across them if you look around a bit. But there's a problem: a vendor wired into your cluster's node autoscaler is a lock-in you can't easily walk away from.
On top of that, you'll need to shift your focus to audit trail mechanisms that sit outside industry standards. What do I mean by that? For example, if you're applying GitOps patterns in Kubernetes and managing your cluster state in git repositories, it's completely natural to have reservations about integrating a tool that talks directly to the Kubernetes API and makes changes at that level. I won't go into the pros and cons here, but this was the first approach.
2. Bringing cost metrics down to the team level
Let's go back to our ten-person FinOps team. How long do you think it would take them to drive these optimizations across 500-1,000 deployments managed by 1,000 developers? While also carrying the coordination overhead, and dealing with a manager asking "why is this moving so slowly, why aren't costs dropping as expected?"
An argument can certainly be made, but the obvious problems are already visible:
- You need to sit down with the developer team and decide whether their application is CPU-intensive or memory-bound. Oh wait, before that, you need to coordinate with the team and schedule the meeting at the right time. Just managing these back-and-forth logistics is extra work. And when you factor in sick leaves, vacations, and developers with completely different priorities, it becomes unmanageable.
- In a 1,000-person organization, hopefully there's an internal developer platform. Otherwise, without systematic and organized service ownership tracking, I don't even want to think about the delays that would happen while trying to figure out who owns which service and who's responsible for what.
- Remember the "FinOps champions" concept from the report? There's an underrated version of this: incentivize the people who actually drive savings. Say a team proves $100K in annual savings through rightsizing. If the company gives back 1-2% of that as a reward (a bonus, a gift, whatever fits the culture), you'd be surprised at the chain reaction it creates. People start paying attention. Other teams want in. The optimization work stops feeling like a chore imposed by the FinOps team and starts feeling like something worth doing. But here's the catch: none of this works unless you can actually track savings per team, per department, per service. You need that attribution layer in place first. That's one of the reasons we built Teams & Departments into Kubeadapt.
Sure, these situations can happen at any company. But the point isn't to fix organizational dysfunction. It's that when these kinds of processes are the norm, you need a tool that works within the reality of how your teams already operate, not one that demands a perfect organization before it can deliver value.
What's next
This post is the entry point for two dedicated series:
FinOps Framework Series
A walkthrough of the FinOps Framework itself: principles, scopes, personas, phases, maturity, domains, and capabilities. If you want to understand how to build and scale a FinOps practice in your organization, this is your path.
Kubernetes Cost Optimization Series
The technical deep-dive into Kubernetes cost optimization practices. The first topic is workload rightsizing: requests, limits, OOM kills, CPU throttling, autoscaling strategies. More topics, like node group optimization and idle workloads, will follow.
If you want to see more on these topics, follow along. I hope this was a useful read, and I'll see you in the next one.
If you want to see workload rightsizing in action, Kubeadapt installs with one Helm command. After about a week of usage data it gives per-workload rightsizing recommendations with their estimated monthly savings.
