“Our AWS bill keeps creeping up every month.” “We don’t even know what we’re paying for.” This situation is not unusual. Because AWS charges for what you use, resources left running when they’re not in use quietly pile up costs. This article explains the billing items to look at first, the seven typical reasons bills get high, and the practical steps for cutting them.
Look first at “the per-service breakdown in Cost Explorer”
The first step in cutting costs is finding the culprit. Open Cost Explorer in the AWS Management Console and look at the last three months from these two angles.
- By service — Which services top the list: EC2, RDS, data transfer, NAT Gateway, and so on. In many cases, the top three services account for 70–80% of the total.
- Monthly trend — Which items keep increasing. Items that stay flat at a fixed amount are resources that have become fixed costs; items climbing steadily are costs tied to data volume or access.
Once you can say “what we’re paying for” at this point, you’re halfway to deciding on cuts.
Seven typical reasons bills get high
- Unused EBS volumes and Elastic IPs — Even after you delete an instance, its EBS and EIP remain and keep being charged. EBS volumes in the “available” state and EIPs not associated with anything are the very first items to check.
- Over-provisioned instances — An EC2 or RDS whose CPU utilization is constantly under 10% can very likely be dropped one or two sizes. Judge by looking at the past month’s utilization in CloudWatch.
- NAT Gateway transfer charges — NAT Gateway charges by the hour plus by the volume of data processed. In configurations where a private subnet accesses S3 heavily, simply switching to a VPC endpoint can greatly reduce transfer charges.
- Continued use of older-generation instances — In many cases, simply moving to a new generation with equivalent performance (e.g. t2→t3 or later, m4→m5 or later) lowers the unit price.
- Accumulation of snapshots and AMIs — Without generation management for automatic backups, years’ worth of snapshots pile up. Decide how many generations to retain and clean out the old ones.
- Dev and test environments running 24/7 — Environments used only during business hours left running overnight and on weekends. Running them only on weekday daytime cuts operating hours to about one-third.
- No storage class set on S3 — Data that’s now accessed infrequently is left in the standard class. Use lifecycle rules to automatically move it to infrequent-access or archival classes.
Practical steps for driving down costs
| Step | What to do | Risk |
|---|---|---|
| 1. Take inventory | List “what costs how much” using Cost Explorer and the resource list | None |
| 2. Delete unused resources | Clean up unattached EBS/EIPs and old snapshots | Low (confirm backups before deleting) |
| 3. Optimize operating hours | Schedule overnight shutdown of dev environments | Low |
| 4. Review size and generation | Downsize and modernize low-utilization instances | Medium (performance testing needed) |
| 5. Review configuration | VPC endpoints, S3 lifecycle, etc. | Medium |
| 6. Apply long-term discounts | Purchase RIs / Savings Plans | Medium (see below) |
The key is to start in order of lowest risk. Just deleting unused resources and shutting down overnight can often account for a 10–20% reduction overall.
Consider RIs and Savings Plans “last”
Reserved Instances (RIs) and Savings Plans give you a discount in exchange for committing to 1–3 years of continued use, and used well they can bring big savings. But there are caveats.
- Don’t buy before reviewing sizes — Locking into a long-term contract while over-provisioned just cements the waste. Always consider this after steps 4 and 5.
- Don’t try to cover the whole thing — It’s safer to target only the base portion that will certainly run all the time, and leave the variable portion on-demand.
- Confirm planned configuration changes — If you have plans within a year to containerize or overhaul the architecture, either choose the more flexible Savings Plans or decide to hold off on buying altogether.
Mechanisms to prevent recurrence｜Budget alerts and tagging
Even once you cut costs, without countermeasures they’ll be back to where they were within months. The two most effective ways to prevent recurrence are:
- Budget alerts with AWS Budgets — Set a monthly budget and get an email notification when actual or forecast spending exceeds a set proportion (e.g. 80%, 100%). Setup takes minutes and costs almost nothing extra. It’s the minimum insurance against the “we only notice when the invoice arrives” state.
- Resource tagging rules — Making tags for “project name,” “environment (production/dev),” and “creator” mandatory lets you aggregate by tag in Cost Explorer and prevents “resources nobody knows the owner of.” Retrofitting tags onto existing resources is hard work, so it’s worth deciding at least the rules early.
In addition, making a habit of 15 minutes once a month to “compare the per-service breakdown against last month” helps you notice abnormal increases early.
Summary｜Cutting costs isn’t a one-off—it’s “a habit of visibility”
Cutting AWS costs works better as “a habit of glancing at the per-service breakdown every month” than as a single spring cleaning. Waste always recurs. SHANNON handles the building and operation of AWS environments, and in cost diagnostics we cover everything from analyzing billing data to implementing reduction measures and continuous monitoring afterward. Feel free to consult us even at the stage of “we don’t even understand the breakdown of our bill.”