Cloud12 min read

FinOps in 2026: where companies overpay most in the cloud and how to measure it in one week

For the first time in five years, the estimate of cloud waste went up this year. Here are the five places where overpaying happens most often, and a five-day audit that measures them without a new tool.

Summary

According to the Flexera State of the Cloud 2026 report, companies estimate that they waste 29% of their IaaS and PaaS spend – and for the first time in five years, that estimate has gone up. Most of the overspend sits in a handful of places: oversized Kubernetes clusters, forgotten resources, non-production environments running around the clock, missing commitment discounts and data transfer. This article shows how to measure these places in five working days without buying another tool, and when optimization is not worth it.

What the 2026 numbers say

The industry’s two most-cited surveys tell a similar story this year: the discipline is maturing, but the waste is not going away.

The Flexera 2026 State of the Cloud Report is based on responses from 753 technical professionals and executives worldwide. Respondents estimate that 29% of IaaS and PaaS spend is wasted, the first increase after five years of decline. 85% of respondents named cost management their number one priority. Meanwhile, 63% of organizations already have a FinOps team.

State of FinOps 2026 from the FinOps Foundation (1,192 respondents, companies with combined annual cloud spend of over 83 billion dollars) shows where the field is heading. 98% of the teams surveyed now manage AI spend, up from 31% two years ago. According to the press release of 19 February 2026, 78% of FinOps teams report to the CTO or CIO – in other words, to technology, not finance.

For practitioners, one sentence of the report matters most: workload optimization and waste reduction remain the top current priority, while FinOps for AI is the top future priority. Put differently – even companies with mature FinOps have not finished the basics.

How to read these numbers

The 29% figure is the respondents’ estimate, not a value measured from invoices. State of FinOps, in turn, mostly describes large organizations with an established FinOps team. Treat both numbers as a pointer to where to look, not as a promise of savings. You will only find the real share of waste in your company from your own data.

Five places where overpaying happens most often

1. Oversized Kubernetes clusters

In its 2026 State of Kubernetes Resource Optimization report (April 2026), Cast AI reports average utilization of 8% for CPU and 20% for memory; a year earlier it was 10% and 23%. The data comes from tens of thousands of production clusters on AWS, GCP and Azure, measured before any optimization. So it is a sample of clusters whose operators were only just adopting an optimization tool – and the vendor has an interest in a dramatic number. An older, more independent view paints roughly the same picture, though: Datadog State of Cloud Costs (June 2024) calculated from AWS data that 83% of container spend goes to idle resources, of which 54% is oversized cluster infrastructure and 29% is unnecessarily high workload requests.

The cause is structural. Developers set requests “just to be safe”, nobody reviews them, and the node pool scales on requests, not on actual consumption.

2. Resources nobody uses

Detached disks, old snapshots, load balancers without backends, unassigned public IP addresses, stopped virtual machines with a premium disk still attached, forgotten test environments. Trivial on their own, together a line item that grows with every project and never shrinks by itself.

3. Non-production environments running 24/7

A week has 168 hours. A development or test environment used ten hours a day on working days is active for 50 hours, roughly 30% of the time. For the remaining 70% of hours you pay for capacity nobody touches. Environments that cannot be shut down entirely can usually at least have their node pools and databases scaled down to the minimum.

4. Paying full on-demand prices for steady workloads

Commitment discounts are the simplest lever that needs no architectural change. In the Savings Plans documentation, AWS cites savings of up to 72% in exchange for a one- or three-year commitment expressed in dollars per hour. Yet according to the Datadog analysis mentioned above, only 67% of organizations used commitment discounts, and only 29% covered more than half of their eligible spend with them. The numbers are from 2024 and concern AWS, but the pattern still holds: companies fear commitment more than is rational.

5. Data transfer and outdated resource types

The same Datadog analysis found that traffic between availability zones makes up almost half of data transfer costs on AWS, and 98% of organizations pay for it. Previous-generation instances accounted for about 17% of EC2 spend, and 58% of EBS spend went to older gp2 disks. These items hide under generic lines on the invoice, and without a breakdown by usage type nobody sees them.

Mind the order of steps

Buy commitments only after rightsizing and after switching off unnecessary resources. A three-year Savings Plan signed on top of oversized infrastructure does not make the waste cheaper – it locks it in. Once you downsize the instances, the commitment goes unused.

Without allocation, nothing can be managed

All of the places above share a common denominator: someone has to know whose cost it is. An invoice broken down by service (“EC2”, “Storage”) will not tell you. You need a breakdown by team, product and environment.

A minimal tag set that is enough to start with: owner (team), service (application or product), env (prod, test, dev) and cost-center. Enforcement matters more than the number of tags. Tags belong in Terraform modules as required variables and in policy (AWS Organizations tag policies, Azure Policy), not in a wiki. How to build modules so the rules cannot be bypassed is covered in the article on Terraform module design.

In Kubernetes, cloud resource tags are not enough, because a single node is shared by dozens of workloads. This is where OpenCost helps – a vendor-neutral open source project for measuring and allocating infrastructure and container costs, which has been a CNCF incubating project since 25 October 2024. It splits node costs by namespace, deployment or label.

FOCUS: one format for every invoice

Multi-cloud companies run into the fact that each provider exports billing data in a different structure. The open FOCUS specification (FinOps Open Cost and Usage Specification) addresses this; its current version 1.4 was released on 4 June 2026. According to the changelog, it added, among other things, datasets for invoice reconciliation; version 1.3 from December 2025 brought contract commitments and shared cost allocation.

The providers are a step behind: AWS Data Exports offers a FOCUS 1.2 with AWS columns table, and Microsoft Cost Management lists version 1.2-preview as the latest. For a one-week audit this does not matter. But if you are building your own reporting, turn on the FOCUS export right away – historical data is not as easy to get retroactively, and according to State of FinOps, 68% of organizations spending over 100 million dollars already use FOCUS or are experimenting with it.

The one-week audit: five days, no new tool

The goal is not to save, but to measure: by the end of the week you should have a list of findings, each with an estimate in Czech crowns and an owner’s name. The provider’s native tools are enough, plus one person with read access to billing and the accounts.

DayWhat to measureOutput
MondayCosts for the last three months by service, account/subscription and tags; share of untagged costsThe ten largest items and the percentage of costs without an owner
TuesdayUnused resources: detached disks, snapshots, unused IP addresses, load balancers without traffic, stopped machinesA deletion list with monthly prices
WednesdayRightsizing: AWS Compute Optimizer / Azure Advisor recommendations; in Kubernetes, requests vs. actual consumptionThe twenty most oversized workloads and instances
ThursdayCommitment coverage and utilization; operating hours of non-production environmentsA stable baseline load suitable for commitment; candidates for nightly shutdown
FridayData transfer (inter-zone, NAT, egress), old instance and disk generations; writing up the findingsA prioritized backlog: savings, effort, risk, owner

Example: the first three queries

Costs by tag, detached disks in AWS and Azure, and a comparison of requests against consumption in the cluster:

# AWS: costs for September 2026 by the "owner" tag
aws ce get-cost-and-usage \
  --time-period Start=2026-09-01,End=2026-10-01 \
  --granularity MONTHLY --metrics UnblendedCost \
  --group-by Type=TAG,Key=owner

# AWS: disks not attached to any instance
aws ec2 describe-volumes --filters Name=status,Values=available \
  --query 'Volumes[].[VolumeId,Size,VolumeType,CreateTime]' --output table

# Azure: unattached managed disks
az disk list --query "[?diskState=='Unattached'].[name,diskSizeGb,resourceGroup]" -o table

# Kubernetes: actual consumption vs. configured requests
kubectl top pods -A --sort-by=cpu
kubectl get pods -A -o custom-columns=\
'NS:.metadata.namespace,POD:.metadata.name,CPU_REQ:.spec.containers[*].resources.requests.cpu,MEM_REQ:.spec.containers[*].resources.requests.memory'

The empty row for the owner tag in the first query is the most important number of the whole Monday. kubectl top shows a point-in-time snapshot; to decide on requests, use percentiles over several weeks from Prometheus or OpenCost.

What should be on the table on Friday

The percentage of costs without an owner (untagged, or shared without an allocation key)
A list of unused resources with monthly price and creation date
Average CPU and memory utilization at cluster level, and the largest gaps between requests and consumption
The share of compute spend covered by commitments, and the utilization of existing commitments
Hours per week that non-production environments run, versus the hours they are actually used
A backlog of findings ranked by savings-to-effort ratio, each with a name attached

What to do with the results, and in what order

Recommended order

  • Delete what nobody uses. Zero performance risk, immediate savings. Before deleting a disk, take a snapshot and give the owner a deadline.
  • Shut down non-production environments outside working hours. Scheduled scaling of node pools to zero, stopping databases where the service allows it.
  • Rightsizing. Kubernetes requests first, then instance types. Change things gradually and watch latency and OOM kills.
  • Commitments for the stable baseline. Start conservatively – cover the minimum consumption of recent months, preferably with a more flexible commitment type and a shorter term.
  • Architectural changes. Inter-zone traffic, NAT, choice of storage classes. The highest effort, so they come last.

A one-off cleanup lasts a few months. To keep the savings from evaporating, you need three permanent things: mandatory tags enforced in the pipeline, team-level budgets with alerts, and a monthly fifteen-minute review of the biggest changes. State of FinOps calls this “shift left” – dealing with cost at design time and in the pull request, not when the invoice arrives. The report also admits an open problem: savings that are avoided up front are invisible, and developers rarely get credit for them.

Where infrastructure is built by hand and without standards, allocation will never work; the broader context is described in the article on infrastructure chaos before adopting AI.

When optimization is not worth it

FinOps has its own cost, and some recommendations do not always apply.

  • A small account. If your monthly bill is in the tens of thousands of Czech crowns, a week of a senior engineer’s time costs more than the annual savings. Deleting the obvious leftovers and setting up a budget alert is enough.
  • Headroom is not waste. Spare capacity for peaks, failover to a second zone and headroom for rolling updates are the price of availability. 8% CPU utilization is wrong; a 90% target is wrong too. A sensible target is set by the load profile and the SLOs, not by a benchmark.
  • Inter-zone traffic. Pulling a service into a single zone saves on transfer but hurts resilience. The answer is more often topology-aware routing than giving up on multi-AZ.
  • Commitment before a change. If you are planning a migration, a switch to a different processor architecture or a major rescaling, a three-year commitment to a specific instance family is a bet against your own plan.
  • A fast-growing product. When delivery speed is the bottleneck, a developer hour spent tuning requests can cost more than an overpaid node. Unit economics decide, not the absolute size of the bill.

The goal is not the lowest bill, but knowing the cost of every service and who makes decisions about it.

What about AI costs?

The jump from 31% to 98% of teams managing AI spend shows that a fringe topic became standard within two years. State of FinOps also names AI cost management as the number one skill teams need to add. In this year’s report, Cast AI measured GPUs for the first time and reports average utilization of 5% – with the same caveat about the sample as for CPU.

For the one-week audit, this means just one thing: put AI services and GPU node pools into the same breakdown as all other costs. Same tags, same owners, same budgets. A separate “AI invoice” outside allocation is exactly the kind of blind spot that made the waste estimate rise this year for the first time in years.

Key takeaways

  • Waste is growing again. Flexera 2026 reports an estimated 29% of IaaS/PaaS spend wasted, the first increase in five years, even though 63% of organizations have a FinOps team.
  • Even mature organizations have not finished the basics. According to State of FinOps 2026, workload optimization and waste reduction are still the top current priority.
  • The biggest slack is usually in Kubernetes. Both vendor and more independent data point to low utilization of requests; measure your own clusters before adopting the numbers.
  • Allocation first, savings second. Without mandatory tags and an owner, no finding turns into action.
  • Order matters. Delete, shut down, downsize – and only then commit.
  • The audit can be done in a week with native tools. The output is a backlog with prices and names, not a slide deck.
  • Headroom for availability is not waste. Target utilization is set by your SLOs, not by a survey average.

Sources

  1. FinOps Foundation: State of FinOps 2026 Report (February 2026)
  2. Linux Foundation: State of FinOps Survey – press release (February 2026)
  3. Flexera: 2026 State of the Cloud Report (2026)
  4. Cast AI: 2026 State of Kubernetes Resource Optimization (April 2026)
  5. Datadog: State of Cloud Costs (June 2024)
  6. FinOps Foundation: What is FOCUS? (June 2026)
  7. FOCUS Spec: CHANGELOG (June 2026)
  8. AWS: What are Savings Plans? (documentation, accessed October 2026)
  9. Microsoft Learn: FOCUS cost and usage details file schema (documentation, accessed October 2026)
  10. CNCF: OpenCost (October 2024)

Do you know how much of your cloud bill has no owner?

DevSecOps.cz helps teams on AWS and Azure measure costs, set up allocation and tagging in Terraform, and shrink Kubernetes clusters without affecting availability.

Or write to info@devsecops.cz. We process your data under our privacy policy.