Why is cloud waste rising again in 2026?

What did Flexera's 2026 State of the Cloud report find about waste?

Flexera's 2026 State of the Cloud Report estimates that 29% of IaaS and PaaS spend is wasted.

That figure had fallen for five years in a row as FinOps practices matured, and in 2026 it rose slightly. Flexera attributes the increase to growing cost complexity from AI and from new IaaS and PaaS services.

Why does cloud complexity create waste?

Complexity creates waste because new pricing models, easy experiments, untagged hand-made resources and extra environments all make it harder to see what is still needed.

• New services have new pricing models that teams do not yet understand.
• Experiments, including AI experiments, are easy to start and easy to forget.
• Resources created by hand or by short-lived scripts escape tagging and review.
• More environments, such as previews per pull request, multiply always-on costs.
• Nobody owns the bill line by line, so nothing triggers a clean-up.

Does rising cloud waste apply to small SaaS teams?

Yes, often more so, because small SaaS teams rarely have anyone reviewing the bill line by line, and a few hundred pounds a month matters more to a ten-person company.

Yes, often more so. A large company has a FinOps team. A small SaaS team usually has a founder glancing at the total each month. The mechanics of waste are the same: something is created for a good reason, its reason goes away, and it keeps billing. The difference is that a few hundred pounds a month matters much more to a ten-person company.

What can a small team do about cloud waste?

A small team can control waste with infrastructure as code, owner tags, budgets, anomaly alerts, expiry dates on experiments and a monthly cost review.

The monthly AWS cost review checklist turns the last row into a routine.

Is some cloud waste acceptable?

Some spend that looks like waste is acceptable, such as spare capacity, recovery backups and fast developer environments, as long as someone chose it on purpose.

Some is. Spare capacity for traffic spikes, backups kept for recovery, and environments that let developers work quickly all cost money and can be worth it. Waste is spend nobody would choose if they saw it. The aim is to see it, decide, and act, every month.

How much cloud waste is your team likely carrying?

Tick each statement that is true for your AWS account.

How quickly can a small team cut cloud waste?

Most of the easy savings, such as deleting idle resources, setting log retention and scheduling non-production environments, can be done within a week or two once someone owns it.

Rightsizing and commitments take longer, because they need a few weeks of usage data and care to avoid performance problems. Start with the easy savings, then measure the effect before the next step.

Write down what each change saved, using Cost Explorer a month later. Seeing the real effect makes it easier to justify the time for the next round, and shows which kinds of waste come back if nobody watches them.

What counts as cloud waste?

Cloud waste is spend that buys nothing you need: idle or forgotten resources, capacity far above real usage, storage nobody reads, and on-demand prices paid for steady usage that could be committed.

It does not include spare capacity or backups you keep on purpose. The test is simple: would anyone choose this spend if they saw it on the bill?

Are AI workloads especially wasteful?

They can be, because they often use expensive compute, are run as experiments and are easy to leave running.

GPU instances, managed model endpoints and large data stores built for a proof of concept can keep billing long after the experiment ends. Put an owner and an end date on every AI experiment, and include those resources in the monthly review.

How do you find forgotten cloud resources quickly?

Compare what is running with what is defined in your infrastructure code.

Anything in the account that is not in Terraform or OpenTofu is a candidate. Then sort Cost Explorer by resource where possible, check resources without an owner tag, and look at utilisation for the largest items. AWS Compute Optimizer can also flag idle and over-provisioned compute.

What is FinOps, and does a small team need it?

FinOps is the practice of making engineering, finance and the business share responsibility for cloud spend, with regular reviews and clear owners.

A small team does not need a FinOps function, but it does need the habits: tags, budgets, alerts, a monthly review and someone who acts on it. That is FinOps at the scale of a ten-person company.