Cloud
A week-long audit, seven categories of waste and the order we tackled them in. Most of it was not the compute you would expect.
A logistics client asked us to look at a cloud bill that had grown 140% in eighteen months while traffic grew 20%. One week of audit, seven categories of waste, and a 43% reduction with no user-visible change. Here is the order we worked in and why that order matters.
Before touching anything, tag everything. Most out-of-control bills are out of control because nobody can attribute cost to a team, service or environment. We spent day one enforcing a tagging policy and backfilling tags on existing resources.
The first attribution report answered the question immediately: 38% of spend belonged to non-production environments.
The cheapest possible win. Unattached storage volumes from instances terminated years ago. Load balancers with no targets. Snapshots of systems that no longer exist. Three NAT gateways in a region with nothing running in it.
Nothing here required a decision from anyone. It required someone to look.
Development and staging ran 24×7 for a team that worked 09:00–19:00 on weekdays. A scheduled shutdown outside working hours cut those environments by roughly 70% with a manual override button for anyone working late.
The objection we always hear — “someone might need it” — is answered by the override, not by leaving everything running.
Memory-optimised instances running CPU-bound workloads, chosen years earlier and never revisited. Right-sizing based on two weeks of actual utilisation data, not on the original guess, closed most of this gap.
The discipline that keeps it closed: a quarterly right-sizing review with utilisation data attached, treated as a normal maintenance task.
Nine terabytes of logs and backups sitting in hot storage, none of it read after the first week. Lifecycle policies moving objects to infrequent-access after 30 days and archival after 90 handled it permanently. Setting the policy took an afternoon; the saving recurs every month.
Cross-availability-zone chatter between services that had no reason to be in different zones, and an internal API being reached over the public internet because of a DNS default set during a migration. Both were architectural accidents, invisible until we drew the traffic map.
Deliberately last. Committing to a baseline before you have right-sized is how you lock in your own waste for three years. Once the steady-state footprint was known, savings plans on the genuinely stable portion were straightforward — and we committed conservatively, at about 70% of baseline.
A database cluster sized for a peak that had never occurred, and a cache tier with a 4% hit rate that was quietly doing nothing at all. The cache was removed entirely.
Buy commitments last. Every hour spent right-sizing before you commit multiplies the value of the commitment.
A cost audit that is not followed by a control loop decays within a year. Three things keep the number honest: cost attribution visible per team in a dashboard they actually see, a budget alert that fires on anomalous daily spend rather than monthly totals, and a cost estimate attached to infrastructure pull requests. None of them are heavyweight, and together they have held this client's spend flat through two years of traffic growth.
Keep reading
Most breaches trace back to a design decision, not a coding mistake. Here is the two-hour session we run at the start of every build — and the template we use.
We rebuilt six sites this year. The same four fixes accounted for most of the gain every time — and image budgets were not the biggest one.
Demos are easy. Evaluation harnesses, grounding, injection defence and cost ceilings are what separate a prototype from a product.
Need this done, not just read?
If any of the above sounds like a problem you have, a thirty-minute call with the engineer who wrote it is free.
