A cloud bill doesn’t usually explode overnight. It creeps up step by step: one forgotten server here, one oversized machine there, and one month you notice the bill is double what it was a year ago, with nobody able to say exactly why. The good news is that most leaks are common and well known. Here are the nine places I find them most often.
1. Instances running that do nothing for anyone
A staging environment spun up for one demo and left running. An old project that ended, but whose server kept living. Every running instance costs money whether or not anyone is using it. Review every running instance once a quarter and ask, for each one: who uses this, and when was the last time?
2. Instances bigger than they need to be
A common habit is picking a larger instance type “to be safe” than the workload actually needs, then forgetting about it. Look at real CPU and memory usage over the last month. If it consistently sits around 10–20%, the instance is oversized for its job.
3. Auto-scaling that scales up but not down
Adding servers automatically as load grows usually works fine. But if the rules aren’t configured properly, the fleet doesn’t shrink overnight or on weekends when traffic is low. The result: you pay peak-load prices even when there’s barely anyone visiting.
4. Forgotten volumes and old snapshots
A deleted server’s disk (volume) doesn’t always disappear automatically with it. Old backup snapshots also pile up over the years: nobody needs them anymore, but nobody deletes them either, just in case. Each one is cheap on its own, but hundreds of them add up to a noticeable line on the bill.
5. Data transfer costs between regions and services
Data coming into the cloud is usually free, but leaving it, or moving between regions or services, costs money. If your application and database sit in different regions, or content is served directly from a server instead of through a content delivery network, that cost repeats with every single request.
6. Storage that’s never been tiered to cold storage
Object storage (like S3) has different pricing tiers: hot, infrequent access and cold archive. If everything, including five-year-old logs and backups, sits in the most expensive hot tier, you overpay every month. Lifecycle rules that automatically move older content to a cheaper tier are one of the easiest wins available.
7. Paying hourly rates for steady, long-term workloads
If one server runs steadily all year round, the standard hourly or per-second rate is the most expensive option for it. Prepaid plans (reserved instances, savings plans) deliver the same capacity for a noticeably smaller bill when load is predictable and stable.
8. A database sized for peak load, not average load
Databases often get sized around the busiest moment (a Black Friday sales spike, say) and then stay that size for the rest of the year. Check whether read replicas, a smaller primary instance, or auto-scaling could deliver the same reliability more cheaply.
9. Nobody watches costs until the bill arrives
The biggest leak on this list isn’t technical, it’s organisational: if nobody looks at cloud spend before the month ends, none of the problems above get caught in time. Billing alerts and a simple monthly breakdown of where money goes by service and project are the cheapest fix on this whole list.
Where to go from here
Most companies don’t need a full infrastructure rebuild, they need a proper cost audit: go through the nine points, measure what actually costs the most, and fix whatever gives the biggest win for the smallest risk. If you want to know exactly where your company’s bill is leaking, see the cloud and DevOps service or send me your latest bill. I’ll review it and tell you where to start.