Cloud Cost Optimization: Where the Money Actually Goes

Most advice on cloud cost optimisation stops at turning on tagging and setting a budget alert. Both are worth doing. Your bill will barely notice.

The things that move a cloud bill are boring and mostly involve deleting resources nobody wants to admit they forgot about. Flexera's 2026 State of the Cloud Report, published in March and based on 753 respondents, put estimated wasted cloud spend at 29 percent, the first increase after five straight years of decline. That is nearly a third of the average bill buying nothing, and the reversal came in a year when FinOps team adoption reached 63 percent. More governance, more waste.

What follows is ordered roughly by how much each item tends to change the number.

Where cloud waste actually comes from

Cloud waste is spend on resources that are running, billing, and doing nothing useful. It accumulates in predictable places.

Idle compute is the largest and the dullest. Development environments provisioned for a sprint that ended in March. Instances running at four percent CPU because someone sized them for a launch that never happened. Staging environments that mirror production twenty-four hours a day so they can be used for two hours a week.

Orphaned storage is next. When an instance is terminated, its attached volumes frequently survive it, and they carry on billing at full rate whether or not anything reads from them. The same applies to snapshots. A retention policy nobody has revisited since it was written will accumulate quietly for years, and because each snapshot is small the total never draws attention until someone finally sorts the storage line item by size.

Then there are the services that bill for existing. A NAT gateway costs roughly $0.045 per hour just to exist, about $32 a month, before it processes a single byte. Run three for multi-AZ redundancy and you are close to $100 a month for gateways that may be serving a dormant subnet. AWS has also charged $0.005 per hour for every public IPv4 address since 2024, attached or not, which turns forgotten Elastic IPs into a slow leak.

We have written about several of these individually, including idle resources and NAT gateway charges, early deletion fees on archived storage, and what happens when free credits run out.

The pattern across all of them is the same. Nothing broke. Nobody made a mistake. The bill grew because cloud resources default to staying alive.

How to run a cloud cost audit

An audit is worth doing before any optimisation, because the ranking of what to fix differs enormously between organisations and intuition is usually wrong about it.

Start with cost by service for the last three months. A single month hides anything with a quarterly billing component and makes seasonal workloads look like anomalies.

Then produce utilisation by workload. You are looking for the shape of demand, not its size. A workload sitting at eighty percent CPU with low variance is a completely different cost problem from one that idles at five percent and spikes twice a day. The first is a candidate for different infrastructure entirely. The second is a candidate for scheduling.

Third, check tag coverage. Tagging saves nothing on its own. It matters because the untagged remainder is where the interesting things hide. Resources created deliberately tend to get tagged. Resources created in a hurry do not, and that is also how they end up forgotten.

Fourth, look at commitment coverage against actual steady-state usage. Flexera found that fewer than half of organisations use even one commitment discount consistently per cloud provider, so the most common finding here is under-coverage.

Finally, sort everything by cost descending and look at the top twenty line items. This sounds too simple to be a step. It is consistently the fastest route to the largest single saving in the estate, because concentration is the norm.

Do this quarterly. Anything less frequent and the estate drifts far enough that the audit becomes a project rather than an afternoon.

Rightsizing without breaking things

Rightsizing produces the largest reliable saving available to most teams, and it is also the thing they avoid, because the failure mode is visible and the saving is not.

The mechanics are simple. Measure utilisation over a window long enough to include your peaks. A week is too short for anything with a monthly cycle. Then reduce in stages, and leave real headroom above the observed peak.

Two things make this go wrong. The first is measuring during an unrepresentative period, which is why month-end batch jobs and seasonal traffic need to sit inside the measurement window. The second is treating memory and CPU as one decision when the constraint is usually only one of them. Plenty of instances are oversized on memory and correctly sized on CPU, and the fix there is a different instance family, not a smaller instance.

Schedule non-production environments while you are in there. A development environment that only needs to exist during working hours can be stopped outside them, which removes roughly two thirds of its runtime cost. This has the highest ratio of saving to effort in the whole exercise and it takes an afternoon.

Reserved instances and savings plans

Commitment discounts trade flexibility for a lower rate. You agree to a level of usage over one or three years, and you pay less per unit.

The range is wide. A one-year Savings Plan with no upfront payment lands around 30 percent off on-demand. A three-year, all-upfront EC2 Instance Savings Plan reaches roughly 72 percent, with Compute Savings Plans slightly behind at around 66 percent in exchange for applying across EC2, Fargate and Lambda regardless of instance family. Reserved Instances reach similar depths and lock you to a specific instance configuration and region to get there.

Vendor material describes one side of this trade. Here is the other. Savings Plans bill against an hourly commitment, and unused commitment does not roll over. Commit to $3.00 an hour, run $2.00 of eligible usage, and the remaining dollar is gone. Multiply that across a year and an over-sized commitment becomes a permanent cost you cannot recover.

The rule most teams land on is to commit to the floor, not the average. Whatever level of usage you are confident will still exist in three years, commit that, and run the variable portion on demand even though the rate is worse. Common practice is covering 60 to 80 percent of the stable baseline and leaving the rest uncommitted.

If you are genuinely torn between one year and three, take one year. The extra 15 to 22 percentage points on a three-year term are only worth having if the workload survives to collect them.

Egress and data transfer charges

Data transfer is the line item people find last, because it does not appear on any architecture diagram.

Three different charges get conflated. On AWS, at US-region list prices:

1. Out to the internet. First 100 GB per month free, then $0.09 per GB for the first 10 TB, $0.085 for the next 40 TB, $0.07 for the next 100 TB, and $0.05 above 150 TB. Most workloads never leave the first tier.
2. Between availability zones in the same region. $0.01 per GB in each direction, so $0.02 for a round trip.
3. Between regions. Typically $0.01 to $0.02 per GB depending on which regions are involved.

Add NAT gateway processing at $0.045 per GB on top of any of the above where the traffic passes through one.

The numbers look small until you apply them to a real architecture. A Kubernetes cluster spread across three availability zones, with services that talk to each other without zone awareness, can generate several terabytes of internal chatter a month at $0.02 per GB round trip. None of that traffic ever leaves the provider's network. It still appears on the invoice.

What makes egress structurally different is that it scales with your product's success, not with your infrastructure decisions. Rightsizing an instance is a choice. Serving more data to more customers is the business working. A media platform, a backup service, or an analytics product with heavy export can find that transfer charges grow faster than revenue, and no configuration change fixes it.

There is a second-order effect that shows up later. Moving a large dataset out costs money in proportion to its size, so the cost of leaving rises as the data grows. Teams tend to discover this at the exact moment they start evaluating alternatives.

The mitigations are narrow, and they work. Serve through a CDN so repeat requests do not re-egress from origin, which on AWS also drops the rate slightly to $0.085 per GB while making the origin fetch free. Keep chatty services inside the same availability zone. Use private IP addresses for internal traffic, since routing internal calls over public IPs triggers charges on traffic that never needed to leave the VPC. And audit cross-region replication that was configured for a disaster recovery plan nobody has revisited.

Storage lifecycle and deletion charges

Archival storage tiers are cheaper per gigabyte and carry minimum storage durations. Delete before the minimum and you pay for the remainder anyway. Retrieve in a hurry and you pay expedited retrieval rates that can exceed what you saved.

We covered a case where moving data to an archive tier to save money produced a four-figure bill instead, in the $1,000 file move.

Lifecycle policies are worth the setup time, with one caution. A policy that transitions objects to a colder tier after thirty days will do exactly that to objects your application reads weekly, and the retrieval charges will quietly exceed the storage saving. Match the policy to the access pattern, not to the calendar.

Forecasting cloud costs

Cloud forecasts fail structurally. Sloppiness has nothing to do with it.

Some services have no upper bound. A misconfigured query, a retry loop, or a traffic spike can produce a bill with no ceiling, which makes the forecast a central estimate with an open-ended tail. Pricing also shifts underneath you, through provider changes and through your own team adopting new services mid-quarter. Flexera's 2026 data points at exactly this: waste rose in the same year that generative AI moved from experiment to production, adding a cost category most teams had no baseline for.

The more useful thing to forecast is cost per unit of business activity. Cost per customer, per transaction, per gigabyte processed. Absolute spend growing thirty percent while customer count grows forty percent is a healthy picture. Absolute spend growing thirty percent while customer count grows five percent is the thing you actually needed the forecast to tell you, and total-spend forecasting will never surface it.

FinOps practices that stick

Most FinOps programmes fail in the same way. Tooling gets bought, dashboards get built, a report circulates, and spend continues to rise. The 2026 Flexera numbers make the point better than any argument: 63 percent of organisations now have a FinOps team, 71 percent operate a Cloud Centre of Excellence, and waste went up.

The reason is that visibility and authority sit in different places. The person who can see the cost is in finance. The person who can delete the resource is in engineering. Until one person holds both, the dashboard is a record of what happened, not a mechanism for changing it.

What tends to work has no glamour in it. Name an owner for every cost centre, with the ability to act and not merely report. Set a cadence, monthly is usually right, and review actual against expected instead of against last month. Give engineering teams a budget they own, including the upside when they come in under it.

When optimisation stops working

There is a point where the exercise runs out of road, and recognising it is worth more than the last five percent.

Public cloud pricing includes a premium for elasticity. You pay more per unit of compute in exchange for the ability to acquire and release capacity in seconds. For a workload with genuine variability, that premium is excellent value. For a workload running at consistently high utilisation with low variance, you are paying for an option you never exercise.

Databases in steady production. Internal applications with fixed user populations. Batch processing on a predictable schedule. Storage that grows monotonically and gets read constantly. These workloads have already been rightsized, already have commitment discounts applied, and are still expensive, because the pricing model itself is a poor fit for their shape.

At that point the lever is placement, not optimisation, and the question becomes which environment each workload belongs in. We wrote about how to make that call in when private cloud beats public cloud, and when it doesn't.

The one thing worth saying plainly is that this is a workload-by-workload decision. An organisation moving everything back out of public cloud is usually making the same category of error as the one that moved everything in.

Where InMotion Cloud fits

Disclosure, since the previous section leads somewhere. We sell managed private cloud on OpenStack, on our own dedicated hardware in US data centres, at a flat monthly rate covering compute, storage, an egress allowance and support in one figure. The invoice does not move when traffic does.

That suits the steady-state workloads described above and does not suit genuinely unpredictable ones, which are better served by the elasticity you are paying a premium for in public cloud.

Our pricing calculator will run the comparison for a specific workload, and our team will do it with you if you would rather talk it through.