Most waste on an AWS bill is not the big obvious line items. It is the small stuff nobody remembers, still billing month after month. We have cleaned up our own bills and keep hitting the same patterns. Writing them down so you step on fewer of them.
1. You deleted the EC2 instance but forgot the EBS volume
This is the most common one. You terminate a box, think you saved the money. But if you did not tick "delete volume", that 100 GB gp3 disk keeps sitting there, billing every month. We have seen a volume from a dead instance two years ago, still there, nobody knew.
Safe move: when you terminate, confirm Delete Volume is ticked. Then regularly filter Cost Explorer by idle EBS and list every volume with no attached instance. Check them one by one.
2. Staging and demo boxes get turned on Monday, forgotten Friday
Staging, demo, QA boxes drift into permanent residence. Nobody watches them like production, but they run at production spec. One m5.large left running 24/7 for a month is roughly a hundred dollars gone for nothing.
Safe move: put an auto stop schedule on non production environments, off at night, on in the morning. Or tag them temporary and sweep on a calendar.
3. A NAT gateway quietly climbs into your top 3 line items
Someone routed traffic through a NAT gateway for a debug session, then never changed it back. NAT bills by the hour on traffic. A few weeks later it has silently crept into the top of your bill. It does not show clearly in Cost Explorer, you have to look at VPC flow.
Safe move: periodically check what is sourcing traffic to each NAT gateway. Confirm every route is intentional.
4. Lambdas and cron jobs nobody remembers writing
A year ago someone wrote a Lambda for a temporary need. The need is long gone, the function still runs every minute. Or an EventBridge rule fires a process that should have been retired. Each one is cheap alone, but they add up across years.
Safe move: sort functions by last modified plus invocation count. Anything with zero or near zero calls for a long stretch, confirm whether it can go.
5. Oversized RDS and orphaned elastic IPs
RDS was sized for peak two years ago, traffic dropped, nobody resized it. An elastic IP with no instance attached still holds a slot. These are not cheap per unit, and they sit outside daily monitoring, so they get ignored.
Safe move: use Trusted Advisor idle checks, or a small script that scans for RDS with CPU under 5 percent for a long window.
Why this is hard to do alone
The hard part is not knowing what to delete. It is not knowing whether deleting it breaks production. Every team is afraid of touching the wrong thing and getting paged at 2am. So what actually helps is not a tool that deletes for you. It is a tool that tells you what to delete, in what order, and what to check before you touch it.
We built a small free tool around exactly that idea. You export your AWS bill CSV, it runs in your browser, nothing leaves your machine, and it gives you a safe delete list ranked by risk. If you are cleaning up your own bill, run it and see which of these five you stepped on.
Top comments (0)