The cloud bill has a way of growing quietly. A staging environment spun up for a launch is never switched off. A database was sized for a traffic spike that never came back. Logs are kept forever because nobody decided otherwise. Each item is small; together they become a line on the finance review that someone eventually has to explain.
The instinctive response is often a grand plan: move to containers, go serverless, rewrite the data layer. Sometimes that is right. More often, a large share of the savings is available without touching the architecture at all. It simply requires looking carefully at what you are paying for.
Step one: make the bill legible
You cannot optimise what you cannot attribute. Before cutting anything, make sure costs can be broken down by environment, product and team. In practice, that means:
- A consistent tagging scheme applied to every resource, enforced by policy rather than good intentions.
- Separate accounts or projects for production and non-production, so experiments do not hide inside production spend.
- Budgets and alerts that notify a named owner when spend drifts, rather than a shared mailbox nobody reads.
This step alone often reveals surprises: resources nobody recognises, environments belonging to projects that ended, and services running in regions nobody remembers choosing.
Step two: remove what is idle
The fastest savings come from things that are doing nothing. Common culprits include:
- Unattached storage volumes and old snapshots left behind after instances were terminated.
- Idle load balancers and public IP addresses from services that have been retired.
- Development and staging environments running around the clock when they are used during working hours. Scheduling them to stop at night and at weekends is one of the simplest wins available.
- Forgotten test clusters and data pipelines still processing data nobody reads.
None of this changes how your product works. It just stops you paying for things you are not using.
Step three: right-size what remains
Most workloads are provisioned for a worst case that rarely happens. Look at actual CPU, memory and I/O utilisation over a representative period, including your busiest days, and size to that with a sensible margin. Databases, managed caches and search clusters are frequent offenders, because they are expensive and people are understandably nervous about shrinking them.
Newer instance generations and ARM-based options often deliver better price-performance for the same workload, and switching is usually a configuration change rather than a rewrite, provided your software supports it. Test first, then move.
The cheapest server is the one you switched off. The second cheapest is the one sized for the traffic you actually have.
Step four: pay less for what you keep
Once the estate reflects real usage, commit to the steady base. Reserved capacity and savings plans offer meaningful discounts in exchange for a term commitment. The mistake is committing before right-sizing, which locks in waste at a discount.
For interruptible work, such as batch jobs, CI runners and some data processing, spot or pre-emptible capacity can be substantially cheaper, as long as the workload tolerates being stopped and restarted.
Look at storage and data transfer too. Moving infrequently accessed data to cheaper storage tiers, setting lifecycle rules on logs and backups, and serving static assets through a CDN all reduce costs that tend to creep up unnoticed. Data transfer between regions and out to the internet is a particularly common source of confusion on bills.
Step five: keep it from creeping back
Cost optimisation is not a one-off clean-up. Without a habit, the bill drifts back within months. A light routine works well:
- A monthly review of the top cost movers, with an owner for each.
- Infrastructure defined as code, so resources are created deliberately and removed cleanly.
- Cost visibility inside engineering, not only in finance, so the people making choices see their effect.
Only once this is in place does it make sense to ask the architectural questions. By then, you will be looking at a clean baseline and real numbers, and any re-architecture will be justified on evidence rather than frustration.
Notepoint's cloud and DevOps practice offers fixed-scope cost reviews that follow this order: attribution first, then idle resources, right-sizing and commitments, with a written plan your team can carry forward.
