Every team we meet has a theory about their cloud bill. Usually it involves a specific service someone has been suspicious of for months. That service is almost never the problem.
Across our last twelve cost engagements, the same six findings kept surfacing. They are ordered roughly by how much they recovered, not by how interesting they are.
1. Non-production environments running around the clock
This is consistently the largest single recovery and the least controversial. Development, staging, QA and demo environments typically run at or near production sizing, twenty-four hours a day, seven days a week. Engineers use them for perhaps forty-five hours a week.
Scheduling non-production to scale to zero outside working hours recovers around sixty-five percent of their runtime. Nobody's workflow changes, because nobody was using them at 3 AM on Sunday.
The objection we hear is that someone occasionally works late. That is solvable with a self-service "wake environment" button that anyone can press, and it costs a fraction of running everything permanently.
2. Provisioning for a peak that happens twice a quarter
Teams size their fleet for the worst day of the year and then pay for it every day of the year. When we pull two weeks of actual utilisation data, the gap between provisioned capacity and observed p99 is usually embarrassing.
The fix is not simply "make everything smaller". It is right-sizing against measured load and then adding autoscaling with genuinely conservative headroom. The autoscaling is what makes the right-sizing safe, and skipping it is why previous cost-cutting attempts caused incidents and got the whole idea banned.
3. Storage that was never tiered
Object storage grows quietly. Logs, backups, user uploads, build artefacts and the export somebody generated in 2023 all sit in the same hot tier at the same price per gigabyte.
Lifecycle policies that move objects to infrequent access after thirty days and to archive after ninety are close to free to implement. The only real work is deciding what must stay immediately retrievable, and that is a conversation with the business rather than an engineering problem.
4. Commitments purchased before right-sizing
This one hurts, because the team was trying to save money. Purchasing Savings Plans or Reserved Instances against pre-optimization usage locks in the waste for one to three years.
The correct sequence is always: right-size first, observe the new stable baseline for a few weeks, then commit against that floor. Committing first is how organisations end up with a discount on capacity they no longer need.
5. Orphaned resources nobody owns
Unattached volumes, idle load balancers, unused elastic IPs, old snapshots, NAT gateways serving a subnet that was decommissioned last year. Individually trivial, collectively a meaningful line item.
These accumulate because nobody owns them. They are the residue of experiments and incidents. A monthly automated sweep that flags resources with no attachment and no traffic for thirty days handles it permanently.
6. Data transfer nobody modelled
Cross-availability-zone traffic, NAT gateway processing charges and egress to the internet rarely appear in anyone's architecture diagram, but they appear reliably on the invoice. Chatty microservices spread across availability zones for resilience can spend more on talking to each other than on compute.
This is the hardest to fix retroactively because it is an architectural property, not a configuration setting. It is also the strongest argument for modelling run cost during design rather than discovering it in month three.
The finding underneath all six
None of these require sophisticated tooling. What they require is attribution: knowing which team, product and environment each rupee belongs to.
Every engagement where we could not answer that question started with tagging enforcement before we proposed a single change. Without attribution, cost reduction becomes a negotiation between people guessing. With it, the conversation becomes specific, and specific conversations get resolved.
If you want the checklist we run on a first engagement, it is on our cloud services page. If you would rather we ran it for you, tell us about your environment.