Cloud spending grows for a rational reason: the cost of provisioning is near zero at the moment of decision, and the consequence appears weeks later on a bill nobody reads line by line. The fix is not austerity. It is attribution, sequencing and a small number of recurring rituals.
Model your savings stack
Layer 1 — eliminate, before you optimise
- Unattached storage volumes and old snapshots, often years of accumulated forgotten disks.
- Idle load balancers, NAT gateways and reserved IPs attached to nothing.
- Non-production environments running 168 hours a week to serve a 40-hour team.
- Abandoned experiments in forgotten regions — audit every region, not just the main one.
- Log and metric retention measured in years where compliance requires months.
Fastest single winSchedule non-production environments to stop outside working hours. Running dev and staging 45 hours instead of 168 removes roughly 70% of their cost, and no customer notices.
Layer 2 — rightsize with real utilisation data
Instance sizes are chosen once, under uncertainty, and never revisited. Pull 30 days of CPU, memory and I/O utilisation. Anything peaking below 40% is a candidate to drop a size — a change that typically saves 30–50% per instance.
Two traps to avoid: sizing to the absolute peak of a once-a-quarter batch job, and ignoring newer instance families that deliver more performance per dollar. Migration to a current generation is frequently a 15–20% saving with no architectural change.
Layer 3 — commit only to a stable baseline
| Commitment | Typical discount | Flexibility | Best for |
|---|---|---|---|
| 1-year, no upfront | ~20–30% | Good | Growing workloads |
| 3-year, all upfront | ~50–60% | Poor | Genuinely stable baseline |
| Compute savings plan | ~25–45% | High — spans families | Most teams |
| Spot / preemptible | ~60–90% | Interruptible | Batch, CI, stateless jobs |
Two metrics, not oneCoverage measures how much usage sits under a commitment. Utilisation measures how much of your commitment you actually consume. High coverage with low utilisation means you prepaid for capacity you are not using — worse than paying on demand.
Target roughly 60–75% coverage of your stable baseline. Leave the variable top layer on demand or spot. Commit in tranches rather than all at once so renewal dates stagger.
Layer 4 — storage and data transfer
- Apply lifecycle policies: hot for 30 days, infrequent access to 90, archive thereafter.
- Delete incomplete multipart uploads — an invisible, permanent charge on many accounts.
- Keep chatty services in the same availability zone; cross-zone traffic is metered.
- Put a CDN in front of anything served repeatedly. Cache hits eliminate origin egress.
- Compress logs and reduce cardinality on metrics; observability bills often rival compute.
Layer 5 — architecture
The biggest reductions come from design, not settings. Common patterns: replacing always-on workers with queue-driven autoscaling, moving spiky batch work to spot capacity, adding a caching layer in front of an over-queried database, and consolidating three under-utilised clusters into one.
Managed services deserve honest accounting. They cost more per unit and less in engineering hours. Compare fully loaded, including the on-call burden of self-hosting.
Layers 6 and 7 — attribution and ritual
- Tag everything, enforce itTeam, environment, service, customer tier. Without tags, cost conversations are opinions.
- Publish cost per team monthlyVisibility alone reduces spend. Nobody wants to own the anomaly on the slide.
- Track cost per customer and per transactionTotal spend rising while unit cost falls is healthy growth. Both rising is a problem.
- Set anomaly alertsA 30% day-over-day jump should page someone the same day, not surface in next month's invoice.
- Run a monthly 45-minute reviewEngineering and finance together, three actions, owners assigned. Consistency beats intensity.
Limits, errors and borders of the standard advice
Critical reviewCloud cost advice comes from the providers themselves, who publish genuinely useful guidance that never recommends leaving, and from cost-management vendors paid a share of savings. Both frame the problem as optimisation rather than architecture.
"Buy reserved capacity or committed-use discounts — the savings are large."
The claimCommitting to multi-year usage substantially reduces unit costs.
Where it breaksYou are selling flexibility, and the discount is the price. Commitments are made against a forecast, and architectures change faster than the commitment term — a migration to a different instance family, a rewrite, or a workload that disappears leaves you paying for capacity you cannot use. The discount also locks you to a provider precisely when you might want leverage in a renegotiation, and it removes the incentive to reduce consumption, since the capacity is already paid for. Providers promote these instruments because predictable revenue is worth more to them than the discount costs.
The borderCommit to the stable baseline you are confident about — steady-state production with a known shape — and cover the variable layer on demand. Right-size and eliminate waste before committing, or you will lock in the current inefficiency for years.
"Autoscaling means you only pay for what you use."
The claimElastic scaling matches capacity to demand, eliminating waste.
Where it breaksAutoscaling manages compute capacity and most surprising bills are not compute. Data transfer between zones and out to the internet, storage that accumulates because nobody owns deletion, idle managed services, logging and observability volumes, and per-request charges on serverless components frequently dominate — and autoscaling does nothing about any of them. Aggressive scaling can also increase cost by thrashing, and scale-to-zero often has latency costs paid by users rather than the budget. The phrase encourages the belief that architecture no longer needs cost thinking.
The borderAutoscaling is genuinely valuable for variable request-driven workloads. Instrument cost by service and by team before assuming it is the answer, and look at transfer, storage and observability lines first — that is usually where the money is.
"Serverless is cheaper — you pay nothing when idle."
The claimPer-invocation pricing eliminates the cost of idle capacity.
Where it breaksCheaper at low and spiky volume, and frequently far more expensive at sustained high volume, where per-request pricing crosses over dedicated capacity — often by a wide margin. The comparison also ignores the surrounding costs that serverless architectures tend to add: managed gateways, per-message charges, more chatty inter-service traffic, and observability spend that rises with invocation count. Operational cost is real too, since debugging distributed event flows is harder and engineering time is the most expensive line in most budgets.
The borderServerless wins for low, spiky or unpredictable workloads, glue code and genuine event processing. Model the crossover point against provisioned capacity at your expected sustained volume, and revisit it as volume grows — the correct answer changes as you scale.
"Cloud is cheaper than running your own infrastructure."
The claimEliminating capital expenditure and operations staff makes cloud economically superior.
Where it breaksTrue for variable workloads, early-stage companies and anything needing geographic reach quickly. It is much weaker for large, predictable, steady-state workloads at scale, where several well-documented repatriations have produced substantial savings. The comparison also usually omits the cloud staffing it creates — platform and cost-engineering roles are not free — and treats egress fees as a line item rather than what they are: a switching cost that grows with your data. Reserved commitments plus egress pricing means the flexibility premium is paid indefinitely.
The borderCloud is the right default for early-stage, variable and globally distributed workloads. Re-examine it once you have a large, stable, predictable base load — and price egress as a strategic constraint rather than an operating cost.
We quote no prices, because provider pricing changes frequently and varies by region and negotiated agreement — which means every crossover calculation we recommend has to be run with your own numbers. Our repatriation point also applies to a minority of organisations with genuine scale and engineering depth; for most teams it is a distraction, and reading it as a recommendation would be a costly misinterpretation. And this is a domain where the specifics move faster than most published guidance, including ours.
Frequently asked questions
Will optimisation slow the team down?
Only if you make engineers request approval for resources. The effective model is guardrails: automatic tagging, environment schedules, budget alerts and default instance sizes. Constraints applied by policy cost no meeting time.
Are third-party FinOps tools worth it?
Above roughly $50k monthly spend, usually yes — they pay for themselves through commitment optimisation alone. Below that, native cost tools plus a tagging discipline capture most of the benefit.
Should we consider leaving the cloud?
Occasionally justified for large, stable, predictable workloads. Include the full cost: hardware refresh, data-centre contracts, networking, security and the engineers to run it. For most companies below serious scale, the answer remains no.
How much can we realistically save?
An unoptimised environment typically yields 25–45% within a quarter without architectural change. After that, further savings require design work — which is where the durable gains live.
The bottom line
Delete waste, rightsize against real utilisation, then commit to the stable baseline — in that order. Tier storage, tame egress, tag everything and publish cost by team. Finally, move the conversation from total spend to cost per customer, because that is the number that tells you whether growth is compounding or just expensive.
Revision log. Jul 2026: added the seven-layer savings model and refreshed commitment discount ranges. Reviewed twice yearly.