Seven ways small teams overspend on AWS (and how to check yours)
Almost every small team we talk to has the same feeling about their AWS bill: it used to make sense, and now it doesn't. Nobody did anything reckless. The bill just crept up, one reasonable decision at a time.
The good news is that overspending on AWS is rarely mysterious. It comes from a short list of ordinary habits. Here are the seven we see most often, and how to check each one yourself in under an hour.
1. Servers sized for a launch that never needed them
When a product first goes live, people size servers for the worst case. That's sensible. What's less sensible is leaving them that size for three years after the traffic settled down.
How to check: In the EC2 console, look at the average CPU use of each instance over the last 30 days (the Monitoring tab shows it). If a server rarely goes above 20 to 30 percent, it's probably at least one size too big. AWS Compute Optimizer, which is free to turn on, will make specific suggestions.
2. Paying on-demand rates for steady workloads
On-demand pricing is the most expensive way to run something that's on all the time. If your baseline usage has been steady for months, Savings Plans or Reserved Instances can cut that part of the bill substantially in exchange for a one- or three-year commitment.
How to check: Open Cost Explorer and look at the Savings Plans recommendations. It will show what you'd save based on your actual usage history. Start with a one-year, no-upfront plan covering only your steady baseline, not your peaks.
3. Storage nobody remembers creating
Disks (EBS volumes) keep costing money after the server they were attached to is gone. Snapshots pile up. Old S3 buckets full of exports and logs sit there indefinitely. None of it is visible unless you go looking.
How to check: In the EC2 console, filter volumes by the state "available". Those aren't attached to anything. Then sort your snapshots by date and ask whether you really need the ones from 2021. For S3, the Storage Lens dashboard shows which buckets are largest and growing fastest.
4. Everything in the most expensive storage tier
S3 Standard is designed for data you read often. Backups, logs and old exports are usually read rarely or never, and cheaper storage classes exist for exactly that.
How to check: Pick your three largest buckets and ask, honestly, how often anyone reads that data. If the answer is "almost never", a lifecycle rule can move older objects to Infrequent Access or Glacier automatically. Set it once and forget it.
5. Test environments that never sleep
A staging or development environment used during office hours doesn't need to run at 3 a.m. or on Sunday. Running it around the clock means paying for roughly three times the hours you use.
How to check: List what's in your non-production environments and when people actually use them. A simple schedule that stops these resources in the evening and starts them again in the morning is one of the fastest wins available.
6. Data transfer charges hiding in plain sight
Moving data out of AWS, between regions, or through NAT gateways is charged separately, and it's easy to miss because it doesn't show up as a "server" on the bill. A chatty service or a misconfigured backup can quietly add hundreds of dollars a month.
How to check: In Cost Explorer, group costs by usage type and look for anything containing "DataTransfer" or "NatGateway". If those lines are a meaningful share of the total, it's worth understanding where that traffic comes from.
7. No one is watching the bill
This is the habit behind all the others. When the bill isn't anyone's job, small increases go unnoticed until they've become large ones.
How to check: Do you have an AWS Budget set with an email alert? Does anyone look at Cost Explorer monthly? If not, set a budget at about 10 percent above last month's spend today. It takes five minutes and turns surprises into early warnings.
Where to start
Don't try to fix everything at once. Start with whatever is cheapest to change and safest to undo, usually unused storage and test environments that run overnight. Then look at right-sizing, and only commit to Savings Plans once your baseline is clear.
And keep a short note of what you changed and why. The next person to look at the account, which may be you in a year, will thank you.
If you'd rather have someone go through all of this for you, our AWS Health Check is a fixed-price review that produces a prioritized savings report with an estimate for every item, plus a security score, in about two weeks.