Cloud cost reduction has a reputation problem. Half the advice is trivially safe and rarely applied; the other half quietly trades away reliability in ways that only become visible during an incident, months after whoever made the change has moved on.

The useful skill is telling those two categories apart. This article works through the savings that are genuinely free, the ones that carry real trade-offs, and the structural changes that matter more than any individual optimisation.

First, find out where the money goes

Before changing anything, get an accurate picture. Most organisations cannot answer “which product or team is responsible for this line of the bill?” — and without that, cost reduction becomes guesswork applied to whatever looks large.

Three things to put in place:

• A tagging policy that is actually enforced. Every resource tagged with owner, environment and service. Enforced at provisioning time through policy, not through a quarterly clean-up that never happens.
• Cost allocated back to teams. Not to punish anyone, but because a team that cannot see its own spend has no feedback loop. Visibility alone changes behaviour before any policy does.
• Anomaly alerting. A misconfigured job or a runaway autoscaling group should page someone within hours, not appear on next month’s invoice.

Skipping this step is why cost programmes stall. You cut the obvious things, spend returns to trend within two quarters, and nobody can explain why.

Savings that are genuinely free

These reduce spend with no meaningful reliability cost. Do all of them before considering anything in the next section.

Delete what nobody uses

Unattached storage volumes. Old snapshots kept by a retention policy no one has reviewed. Idle load balancers. Reserved IP addresses attached to nothing. Development environments running at full size overnight and at weekends. Databases provisioned for a project that was cancelled.

This is unglamorous and it is consistently the largest source of easy savings in environments that have been running for a few years. Run the audit; the results are usually uncomfortable.

Fix storage tiering

Object storage that has not been read in a year sitting in the hot tier is pure waste. Lifecycle policies that move data to infrequent-access and archive tiers on a schedule are set up once and save continuously.

The one caution: check retrieval costs and latency against your actual access patterns before archiving. Archive tiers are cheap to store and expensive to read in a hurry. Data you might need during an incident should not be in deep archive.

Commit to baseline capacity

If you have been running a stable baseline of compute for a year, you are paying on-demand rates for capacity you demonstrably always need. Committed-use discounts and reserved capacity exist for exactly this and represent a substantial reduction on that portion of the bill.

Commit only to your genuine floor, not your average. Commitments made against optimistic growth forecasts become a liability when growth arrives later than planned.

Stop paying for data to cross boundaries unnecessarily

Egress and cross-zone traffic charges accumulate quietly and are frequently the result of architectural accident rather than intent — a service in one zone chatting constantly to a database in another, a cache placed on the wrong side of a boundary, backups routed through the public internet.

Map your traffic flows against your zone and region topology. The fixes are often small and the savings ongoing.

Right-size against measured usage

Instances are typically sized by an initial guess and never revisited. Compare provisioned CPU and memory against actual utilisation over a representative period — including peaks, not just averages.

Right-sizing is only free if you keep genuine headroom for spikes and for failover. Sizing to p99 utilisation with nothing spare is not right-sizing; it is the next section.

Savings that cost you something

These are legitimate choices, but they are trades. Make them consciously, document the reasoning, and make sure the person who owns the service agrees.

Reducing redundancy

Dropping from multi-region to single-region, or reducing replica counts, cuts cost immediately. It also changes what happens during a regional outage from “degraded” to “down”.

This can be entirely correct for an internal tool where several hours of downtime is tolerable. It is rarely correct for a revenue-generating path. The mistake is not making the trade — it is making it without anyone stating the new expected recovery time out loud.

Spot and preemptible capacity

Interruptible instances are dramatically cheaper and excellent for fault-tolerant batch work, CI runners and stateless workers that can be rescheduled.

They are a poor fit for stateful services, anything with a long start-up time, or workloads where a mid-run interruption means losing hours of progress. Using them well requires the workload to genuinely tolerate interruption — which is an engineering property, not a configuration setting.

Shortening retention

Logs, metrics, traces and backups all cost money to keep. Cutting retention saves money and reduces what you can investigate later.

The asymmetry matters: the value of a log line is near zero until the moment you are debugging a production incident or responding to a security question, at which point it is very high. Before shortening retention, check your regulatory obligations, then ask how far back your last few investigations actually needed to look.

A reasonable middle path is tiered retention — full-fidelity data for a short window, aggregated or sampled data for longer.

Aggressive autoscaling

Scaling down faster and further saves money between traffic peaks. It also increases the chance of being under-provisioned when a spike arrives faster than the scaler reacts, and cold starts are paid for by users.

Tune scale-down more conservatively than scale-up. The cost of being briefly over-provisioned is money; the cost of being under-provisioned during a spike is customers.

The structural changes that matter more

Individual optimisations plateau. Sustained improvement usually comes from architecture and process rather than from settings.

• Fix the expensive query before adding hardware. A missing index or an N+1 query pattern can be responsible for a large fraction of database spend. Scaling up hides it and pays for it monthly, forever.
• Cache deliberately. A well-placed cache in front of an expensive computation or a chatty API reduces both cost and latency. This is one of the rare cases where the cheap option is also the fast one.
• Match the compute model to the workload. Spiky, event-driven work is often cheaper serverless. Steady, high-throughput work is usually cheaper on committed instances. Many bills contain workloads on the wrong side of that line, placed there by a platform decision made years ago for different traffic.
• Make cost visible at design time. The most effective control we have seen is including a rough cost estimate in architectural review. It is much cheaper to question a design than to re-platform it.

A sensible sequence

1. Establish tagging, allocation and anomaly alerting so you can measure results.
2. Take every free saving in the section above.
3. Fix the two or three most expensive inefficiencies in code and queries.
4. Commit to your genuine baseline capacity.
5. Only then evaluate the trade-off savings, service by service, with the service owner in the room.
6. Re-measure quarterly, because cloud spend regresses without attention.

Getting help with it

Our web and cloud engineering team runs cost and reliability reviews that produce a prioritised list separating the free savings from the ones that carry a trade, with the reliability impact stated for each. Where the root cause is in application code rather than infrastructure, our software engineering team can address it directly.

Get in touch if your cloud bill is growing faster than your traffic.