Why does the cloud bill keep growing? Finding waste, measuring it, and making the cut stick

Short answer: the bill grows because waste never sits in one line item and nobody owns the number. Flexera's 2026 State of the Cloud report puts wasted IaaS and PaaS spend at 29 percent, up from 27 percent in 2025 after five years of decline. Datadog's measurements find 83 percent of container spend going to idle resources. The problem is rarely that you picked an expensive service. It is that you reserved capacity you never use and no one looks at the gap. That is why cutting is the wrong first move. Split the spend across teams and products first, fix the three largest line items second, and buy commitment discounts last. Teams that run this backwards lock their waste into a three-year contract.

Whose number is it

The first step toward a lower bill is accounting, not engineering. If no resource has an owner, your report shows one large figure, and nobody makes a decision from one large figure. Tagging gets deferred because it is dull work, yet everything else depends on it.

The rule that holds up in practice: enforce required tags inside your infrastructure code, reject hand-created resources, and bill untagged spend to the platform team rather than spreading it around. Once that figure has a name on it, it gets cleaned up fast. The FinOps Foundation's 2026 State of FinOps report, covering 1,192 respondents and more than 83 billion dollars of annual cloud spend, found 78 percent of these teams now report to a CTO or CIO, an 18 point rise against 2023. Cost has become an engineering metric rather than a finance one.

The biggest line item is usually capacity sitting empty

In Datadog's data, Kubernetes clusters run at an average of 10 percent CPU and 20 percent memory utilization. Of the 83 percent of container spend that goes to idle resources, 54 percent is cluster idle (over-provisioned node capacity) and 29 percent is workload idle (resource requests larger than the workload needs). Containers account for 35 percent of EC2 spend in the same dataset.

The mechanism is simple, which is exactly why it goes unnoticed. Kubernetes provisions nodes against the number in your requests field, not against what your pods actually consume. On most teams that number is written once, during the push to production, by taking the highest peak anyone has seen and adding headroom. It is never revisited. So you buy nodes for capacity that stays empty. The fix starts in the same place: pull the p95 from a few weeks of real usage, move CPU requests close to it, and keep memory limits where they are, because memory pressure ends with a killed process rather than a slow one. Cut CPU too far and you hit throttling, so watch latency before and after the change. Autoscaling handles growing and shrinking capacity on demand; it does not correct a wrong requests value, it replicates it faster.

Commitment discounts are cheap money in the wrong order

The headline numbers are attractive. AWS Compute Savings Plans go up to 66 percent off on-demand pricing, EC2 Instance Savings Plans tied to a specific instance family reach 72 percent, and Spot pricing goes as deep as 90 percent for workloads that tolerate interruption, in exchange for accepting a two-minute interruption notice.

The trap is sequencing. Commit to an oversized fleet for three years and you have made the waste permanent. The order that works: fix sizing, let it settle for two or three weeks, commit your steady baseline, and leave the variable part on on-demand and Spot. In the same Datadog dataset, 67 percent of organizations use commitment-based discounts (down from 72 percent the year before) and only 29 percent hold commitments covering more than half of eligible spend. There is a second, architectural trap. If Arm is anywhere on your roadmap, a three-year lock to an x86 family makes that migration expensive. AWS states that Graviton-based instances cost up to 20 percent less than comparable x86 instances and use up to 60 percent less energy for the same performance. Datadog measured Arm instances reaching 18 percent of EC2 compute spend, double the previous year.

Network traffic is the half of the bill nobody reads

Data transfer shows up as a single line on the statement, so it gets skipped. Open it and you are looking at the price of your architecture. On AWS, the first 100 GB of outbound internet traffic per month is free across all services and regions, then it runs 0.09 dollars per GB up to roughly 10 TB and 0.085 dollars for the next 40 TB. Traffic between availability zones inside the same region costs 0.01 dollars per GB in each direction. That looks like a rounding error. In Datadog's data, 98 percent of organizations pay it and cross-AZ traffic makes up nearly half of all data transfer cost.

NAT Gateway sits on top of that: 0.045 dollars per hour in each availability zone plus 0.045 dollars per GB processed. Every dependency your private subnet pulls from a package registry has a price attached. The concrete fixes: keep chatty service-to-service and database replica traffic inside a single zone where your availability target allows it, define gateway-type VPC endpoints for S3 and DynamoDB since those carry no hourly or data processing charge, and put static assets behind a CDN. None of this is a setting in the billing console. All of it is architecture.

Storage is a lifecycle decision, not a price-class decision

Moving object storage to a cheaper class is not automatically a saving. Standard-IA and One Zone-IA bill a 30 day minimum storage duration, Glacier Instant and Flexible Retrieval bill 90 days, Deep Archive bills 180 days. A lifecycle rule that pushes millions of small objects into an archive class when those objects get deleted after a week raises the bill, once you add transition requests to the minimum duration charge. Look at your object size distribution and actual retention before writing the rule.

Block storage is where free money is still on the table. gp3 costs about 20 percent less per GB than gp2 and the conversion happens without downtime, yet Datadog still measured gp2 at 58 percent of EBS spend. Then there are the orphans: volumes left detached after an instance was deleted, snapshots from projects that shut down last year, a 400 day log retention policy nobody has read. They all keep billing at full price.

The small items with no owner

Since February 1, 2024, AWS charges 0.005 dollars per hour for every public IPv4 address, whether it is attached to a service or sitting idle. That is roughly 3.65 dollars per month per address. If 200 of them are left over from old projects, you are paying something like 8,700 dollars a year for nothing.

In the same bucket: load balancers with no healthy targets behind them, test clusters that were never torn down, development environments running through the weekend. A week has 168 hours. If the dev environment is genuinely used for 50 of them, shutting it down outside working hours removes about 70 percent of that line item's hours. The nice thing about this kind of cleanup is that it touches no architecture, so the risk is near zero. The bad thing is that it is one-off: the list refills within six months, which is why it belongs in a recurring monthly check rather than a one-time project.

AI spend is the new waste category

State of FinOps 2026 reports that 98 percent of practitioners now manage AI spend, against 63 percent in 2025 and 31 percent in 2024. The single most requested capability across that whole survey is granular visibility into AI spend at the level of tokens, model requests and GPU utilization, and the report is direct about commercial tooling not delivering it at scale. Datadog measured GPU instances at 14 percent of EC2 compute spend.

The practical consequence: your provider will not give you a per-feature breakdown, so put the measurement inside the application. On every model call, log the model name, input and output token counts, the feature, and the tenant id. Build the report from that. The levers that lower the number are the familiar ones: cache repeated prompts, route easy work to a smaller model, and cap retries. This is the billing-side version of the instrumentation problem we covered in observability, SLOs and error budgets.

Design decisions turn into monthly line items

Past a certain point, a cost review is an architecture review. The framing that works is unit cost rather than total spend: how much per customer, per order, per thousand requests. That number changes product decisions too, because it is usually the first time anyone can see which customers are profitable.

The connections are specific. In a multi-tenant SaaS architecture, the marginal cost of a separate deployment per customer is nothing like the marginal cost of a shared schema. On the database side, a missing index appears on the invoice as a larger instance type, and fixing the query is both cheaper and more durable than adding hardware. In the monolith versus microservices decision, every service boundary is a network hop, and that hop is billable once it crosses a zone. These are free to change on a whiteboard and expensive to change in production.

Exit cost binds you less than it used to

The bargaining position shifted over the last two years. Google Cloud in January 2024 and AWS in March 2024 both announced that they would stop charging egress for customers migrating off the platform, subject to conditions and an approval process, and Microsoft published a comparable arrangement for leaving Azure.

The regulatory side is sharper. The EU Data Act (Regulation (EU) 2023/2854) became applicable on 12 September 2025, and during the transitional period providers may only pass on the costs they actually incur for a switch. From 12 January 2027, all switching charges, egress included, are prohibited outright. Standard service fees and early termination penalties fall outside that, and providers may still charge for services beyond the minimum obligation, such as converting data into a specific format. For companies serving the EU or contracting with EU providers, the practical reading is to keep portability cheap in your design without sacrificing architecture to a fear of lock-in. Zero-egress object storage is also a real option now; Cloudflare R2 lists egress as free and standard storage at 0.015 dollars per GB-month.

The same inventory appears on your security list

Cost cleanup has a security by-product. A server with no owner does not get patched, a snapshot from a dead project holds production data somewhere with no access review, and an object store accidentally left public both leaks data and bills you for the egress. Both jobs start with the same question: what do we have, and whose is it? Produce that inventory once and you have filled in half the checklist on the cloud misconfiguration and shared responsibility side.

Five things you can do this month

One: run a tag coverage report and find out what share of spend has an owner. Below 80 percent, none of the other steps are measurable. Two: list the ten largest line items from the last 30 days and ignore everything else, because the hundred items in the tail are a small fraction of the total and a large fraction of your time. Three: before touching any commitment, spend two weeks putting requests next to actual usage. Four: make exactly one network fix, either moving a chatty cross-zone pair into the same zone or adding a gateway endpoint for S3. Five: put monthly spend per environment on the same dashboard as latency and error rate.

Those five steps will not halve the bill by themselves. What they do is more useful: they turn spend into an engineering number. Wedevit runs this review remotely: we attach every line item to an owner, order the sizing and network fixes by impact, and leave the commitment decision for last. We sit in no provider's sales channel, so the only test a recommendation has to pass is your invoice. After that it behaves like measuring and prioritizing technical debt, which is fitting, since a large share of any cloud bill is the monthly installment on last year's deferred decisions.