Where cloud bills actually go wrong

The first move is always attribution, not optimisation. Tag every resource by service, environment, and owner, then produce a breakdown of what each part of the system actually costs.

This step regularly overturns assumptions. Teams arrive convinced their compute is the problem and discover that half the bill is a managed database provisioned three sizes too large, or a logging pipeline nobody has looked at since launch.

Set a budget alert while you are in there. A surprising share of runaway bills are a misconfiguration — a runaway job, a recursive function, a debug log level left on in production — that a threshold alert would have caught on day one instead of at month end.

This is the most common easy win and it is almost always available. Development, staging, and QA environments typically run 168 hours a week to serve perhaps 50 hours of actual use.

Scheduled shutdown outside working hours cuts those environments by roughly 65% to 70% with no engineering compromise whatsoever. On a bill where non-production is a third of spend, that is a meaningful reduction for an afternoon of automation.

The related habit is orphaned resources: unattached volumes, idle load balancers, old snapshots, unused static IPs, abandoned test clusters. Nobody deletes these because nobody is certain they are unused, which is precisely why tagging by owner pays for itself.

Over-provisioning is the largest structural cost in most environments we review. Instances and databases are sized for an imagined peak, then never revisited, and utilisation sits in the low teens.

Look at actual CPU and memory utilisation over a month, not at the sizing decision made at launch. Sustained utilisation under 20% is a clear signal, and in most cases a size reduction is safe when autoscaling can absorb genuine spikes.

Once utilisation is honest and steady, commit. Reserved instances and savings plans discount predictable baseline load by roughly 30% to 60% depending on term and flexibility. The correct sequence matters: right-size first, then commit, because committing to an oversized baseline locks in the waste for a year or three.

Managed services deserve a specific look. The convenience premium is often worth paying, but a managed cluster left at launch-day capacity for two years is the single largest avoidable line item we encounter.

Egress is the cost that most often surprises teams, because compute pricing is visible while transfer pricing is buried and charged per gigabyte.

Cross-zone and cross-region chatter is a frequent culprit. A service in one availability zone talking constantly to a database in another generates charges for traffic that looks internal in an architecture diagram. Co-locate components that talk frequently.

For anything media-heavy, serve assets through a CDN rather than from origin. Beyond the performance benefit, CDN egress is materially cheaper than origin egress, and cache hit rate directly reduces the bill.

This matters disproportionately for teams serving Australia and South Africa from EU or US regions, where inter-region transfer accumulates quietly. It is often a strong argument for a regional edge presence on cost grounds alone, quite apart from latency.

Logging, metrics, and tracing platforms charge by ingestion or retention, which means cost scales with how verbose your application is rather than how valuable the data is.

Debug-level logging left on in production is the classic case. So is retaining everything for a year when nobody has queried beyond the last fortnight. Set retention by usefulness, sample high-volume traces rather than capturing all of them, and drop the log lines nobody has ever searched.

Do this carefully, though. Cutting observability to save money is a false economy if it lengthens incident resolution — a shorter outage is usually worth more than the logging bill. Trim volume, keep signal.

Tag and attribute, and set budget alerts. Nothing sensible happens before this.

Schedule non-production shutdown and delete orphaned resources — fast, safe, and immediately visible on the next bill.

Right-size against real utilisation, then buy commitments against the corrected baseline.

Address egress and observability, which usually need small architectural changes rather than configuration alone.

Then stop. Cloud cost work has diminishing returns, and past a certain point engineering hours spent shaving percentages are worth more spent on the product. We aim to make the bill proportionate and predictable, not minimal.