Cloud Cost Optimisation: Five Changes That Matter Most

Cost optimisation guidance usually opens with reservations, savings plans and
commitment modelling. Those matter at scale. For most teams, most of the
available saving is in five much duller changes, and they are available without
committing to anything.

1. Delete what nothing is using

This is first because it is both the largest and the easiest. Go through the
console looking specifically for:

• Volumes not attached to any instance
• Snapshots older than your actual retention requirement
• Reserved IP addresses pointing at nothing, which several providers charge
  for precisely because they are idle
• Load balancers with no healthy backends
• Instances in regions you do not use, usually left over from a test
• Old machine images nobody deploys from any more

There is no downside and no trade-off. The only reason it does not happen is
that nobody looks. Put it in a calendar on a monthly repeat.

2. Right-size what is running

Instances get chosen early, when nobody knows what the load will be, and the
choice is usually generous. Then the load becomes known and the instance never
changes.

Look at CPU and memory utilisation over a few weeks. An instance sitting
consistently below a fifth of its capacity is a candidate to move down a size,
and one size down is typically close to half the price. Be careful with memory:
a process that has never been under memory pressure is not the same as one that
never will be, so leave more headroom on memory than on CPU.

Right-sizing is reversible, which makes it low risk. Resizing back up takes
minutes if you got it wrong.

3. Put a lifecycle policy on storage

Storage only grows. Logs accumulate, backups accumulate, snapshots
accumulate, and all of it bills monthly forever unless something deletes it.

Decide how long you actually need each class of data, then automate the
deletion. Most object storage supports lifecycle rules that move older objects
to cheaper tiers or delete them outright, and most snapshot systems support a
retention count. The decision is a one-off; the saving recurs.

Be deliberate about what retention you genuinely need rather than what feels
safe. “Thirty days of daily snapshots” and “seven days of daily plus four
weeklies” protect against almost the same failures and differ substantially in
cost.

4. Reduce egress at the source

If outbound transfer is a visible line on your bill, the three changes that
move it most are putting a CDN in front of static assets, compressing text
responses, and serving images at the size they will be displayed. None of these
is an infrastructure change and all three improve page performance as a side
effect.

If egress is not a visible line on your bill, skip this entirely. Plenty of
deployments sit comfortably inside an included allowance, and optimising
something that costs nothing is a way of feeling productive rather than being
productive.

5. Turn off what does not need to run at night

Development, staging, test and demo environments usually need to exist during
working hours and almost never need to exist at three in the morning or at the
weekend. Shutting them down outside working hours removes roughly two thirds of
their running hours.

This requires per-second or per-hour billing to be worth doing, so check your
provider’s granularity first. On a flat monthly plan, stopping a server
overnight saves nothing at all, which is covered in
what pay as you go actually
means.

What to do only after these

Once the five above are done and the bill is still larger than you want, then
look at commitment-based discounts. The order matters: reserving capacity you
should have deleted or right-sized locks in the waste for a year. Measure first,
clean up second, commit third. The reasoning behind each pricing model is in
on-demand, reserved and spot.

Make it a habit rather than a project

The teams that keep costs under control are not the ones that run a big
optimisation exercise once. They are the ones where somebody opens the billing
console for ten minutes every month and asks what changed. That habit catches
almost everything on this page before it becomes worth a project.