Most cloud cost programmes start with a dashboard and end with a spreadsheet nobody updates. The savings that stick come from a small number of structural changes, not from continuous vigilance.
What follows is ordered by return on effort for a typical mid-sized estate.
1. Commitments on the stable baseline
Every estate has a floor — the compute that runs continuously regardless of load. Paying on-demand rates for that floor is the single largest avoidable cost in most bills.
Reserved instances and savings plans typically reduce that spend by 30–50% in exchange for a one or three-year commitment. The analysis is straightforward: look at the minimum compute running over the last 90 days, commit to somewhere around 70–80% of it, and leave the rest flexible.
The usual objection is uncertainty about future architecture. Flexible commitment types that apply across instance families largely address this, and a three-year commitment at a 50% discount pays for itself even if you only use two years of it.
2. Non-production scheduling
Development, staging and test environments typically run 168 hours a week and are used for about 50. Shutting them outside working hours saves roughly 65% of their cost for a day’s automation work.
The implementation is simple — a scheduled job that stops instances at 8pm and starts them at 7am, with a manual override. The resistance is cultural rather than technical, and it dissolves once someone shows the finance team the number.
Non-production is commonly 20–40% of total spend in an engineering-heavy organisation, which makes this one of the highest-return items available.
3. Right-sizing, done with data
Instances are usually provisioned by guess and never revisited. Average CPU utilisation under 10% across a fleet is extremely common.
Pull two to four weeks of utilisation metrics, identify instances where peak CPU and memory stay well below provisioned capacity, and resize down one step. Repeat quarterly. The discipline that matters is using peak rather than average — resizing on averages produces incidents.
Do this after a migration has settled, not during. Our cloud migration checklist covers why the first fortnight’s metrics are not representative.
4. Storage tiering and lifecycle rules
Object storage accumulates. Logs, backups, build artefacts, old database dumps and user uploads from customers who left years ago all sit on expensive hot storage because nobody wrote a lifecycle policy.
Lifecycle rules that move data to infrequent-access tiers after 30 days and archive tiers after 90 reduce storage cost substantially with no application changes. Add an expiry rule for anything genuinely temporary — build artefacts, old log files — and the saving compounds.
The one caution is retrieval cost and latency on archive tiers. Data you might need urgently should not be archived, and backups you need to restore from quickly belong in a tier you can actually restore from quickly.
5. Orphaned resources
Unattached storage volumes, idle load balancers, unused static IP addresses, old snapshots, forgotten test clusters. Individually trivial, collectively often 5–10% of a bill.
These accumulate faster than any manual process can clear them, so the answer is automation: a weekly report of resources with no attachment and no recent activity, and a policy that anything untagged and idle for 30 days is deleted after a warning.
Enforced tagging is what makes this possible. Without an owner tag, nobody dares delete anything.
6. Data transfer
Egress charges and cross-zone traffic are invisible in architecture diagrams and material in bills. Common culprits: services chatting across availability zones unnecessarily, backups written to a different region, a CDN that is not caching what it should, and logs shipped to a third-party tool in bulk.
Review the data transfer lines in your bill specifically — they are usually aggregated into something unhelpful by default. Co-locating chatty services in the same zone, caching aggressively, and compressing log shipping each tend to produce immediate reductions.
7. Managed service tier review
Managed databases, caches and search clusters are frequently provisioned at a size chosen during an initial load test and never revisited. They are also frequently running in high-availability configurations in non-production environments, which doubles their cost for no benefit.
Check each one for: appropriate sizing against current load, whether multi-AZ is needed in that environment, whether the storage allocation has grown automatically and never shrunk, and whether a newer instance generation offers better price-performance.
Making savings stick
Most cost programmes deliver a one-off reduction and then drift back within two quarters. Three practices prevent that.
Allocate cost to teams. A bill nobody owns is a bill nobody manages. Tag by team or service, report monthly, and make the number visible to the people who can change it.
Put cost in the deployment path. A pull request that provisions infrastructure should show its estimated cost. Decisions made at build time are far cheaper to influence than decisions reviewed six months later.
Set a unit metric. Cost per customer, per transaction, per thousand requests. Absolute spend should rise as the business grows; unit cost should fall. Reporting only absolute spend makes growth look like failure and hides genuine inefficiency.
What not to optimise
Two cautions. Engineering time is more expensive than most savings — spending three weeks to save $400 a month is a poor trade, and teams under cost pressure make this trade repeatedly.
And optimisation that reduces reliability is not optimisation. Removing redundancy, cutting backup retention below your recovery requirement, or stripping monitoring to save on log ingestion all save money until the incident that costs more than a year of the saving. Our notes on disaster recovery planning cover where the floor should be.
A sensible first 30 days
Week one: enforce tagging, turn on detailed billing, and identify the stable compute baseline. Week two: schedule non-production shutdowns and delete orphaned resources. Week three: apply storage lifecycle rules and review data transfer. Week four: buy commitments on the baseline and set up a monthly cost review with team-level allocation.
That sequence typically takes 20–35% off a previously unmanaged bill, and most of it holds without further attention.
Building a cost-aware engineering culture
The difference between organisations that control cloud spend and those that do not is rarely tooling. It is whether engineers see cost as part of their craft or as somebody else’s problem.
Three things move that. Make the cost of each service visible to the team that owns it, weekly, without anyone having to ask. Discuss cost in design reviews alongside latency and reliability, so the trade-off is made at the point of decision. And celebrate reductions the way you celebrate performance improvements — a 40% cost reduction on a service is a genuine engineering achievement and is usually treated as housekeeping.
What does not work is an annual cost-cutting exercise driven from finance. It produces a one-off reduction, some resentment, and no change in how the next system gets built.
Reading the bill properly
Most teams look at the total and the top three line items. Three other views are more useful.
Cost by tag, not by service. Knowing you spend a lot on compute is not actionable. Knowing which team or feature drives it is.
Month-over-month change by line. The absolute bill is dominated by things that have always been expensive. The interesting number is what grew, and by how much, since last month.
Cost per unit of business value. Spend divided by customers, requests or transactions. This is the only view that distinguishes growth from waste, and almost nobody builds it.
Frequently asked questions
How much can a typical organisation save?
An estate that has never been optimised commonly has 20–40% of avoidable spend. One already under active management may find 5–10%.
Are savings plans better than reserved instances?
Savings plans are generally more flexible, applying across instance families and sometimes across services, at a slightly smaller discount. Reserved instances can be better for genuinely fixed, long-lived workloads.
Should we use spot or preemptible instances?
For fault-tolerant, interruptible work — batch processing, CI runners, stateless workers — yes, and the discounts are large. For anything that cannot survive a two-minute termination notice, no.
Is a third-party cost tool worth buying?
Usually only above a certain spend, perhaps $50,000 a month, or in multi-cloud estates where native tools do not aggregate. Below that, native tooling plus enforced tagging covers most of the value.
