In this article
- 1. See where the money goes
- 2. Delete what nobody uses
- 3. Switch off what only runs in office hours
- 4. Right-size servers and databases
- 5. Move to newer, cheaper types
- 6. Store data in the right class
- 7. Cut data transfer and NAT charges
- 8. Commit to Savings Plans and use Spot, last
- 9. Stop it creeping back
- What about Google Cloud?
To cut an AWS bill without slowing anything down, work in this order: find what you pay for and don’t use, right-size what’s left, fix storage and data transfer, and only then commit to discounts. The discounts are real. AWS says Savings Plans can reduce compute costs by up to 72% and Spot capacity by up to 90%. But committing before you’ve cleaned up just locks in the waste.
These are the nine steps we work through when someone asks why their cloud bill keeps growing. Most need no code changes, and none should make your product slower.
| Step | Effort | Risk to performance |
|---|---|---|
| 1. See where the money goes | Low | None |
| 2. Delete what nobody uses | Low | None, if checked first |
| 3. Switch off what only runs in office hours | Low | None for non-production |
| 4. Right-size servers and databases | Medium | Low, if based on weeks of data |
| 5. Move to newer, cheaper types | Medium | Low, after testing |
| 6. Store data in the right class | Low | Low |
| 7. Cut data transfer and NAT charges | Medium | None |
| 8. Commit to Savings Plans and use Spot | Low | None |
| 9. Stop it creeping back | Low | None |
1. See where the money goes
Open Cost Explorer and group the last three months by service, then by tag. If you can’t say which product or environment a line item belongs to, fix that first: tag every resource with at least its project and its environment (production, staging, development). Then set an AWS Budgets alert slightly above your current monthly spend, so the next surprise reaches you as an email instead of an invoice.
2. Delete what nobody uses
Almost every account we look at carries some of these:
- Storage volumes no longer attached to any server
- Old snapshots and machine images nobody will restore
- Load balancers with nothing behind them
- Public IP addresses that aren’t in use
- Test environments from a project that ended months ago
Each one is small. Together they add up, and they cost nothing to remove once you’ve confirmed they really are unused. Take a final snapshot of anything you’re unsure about before deleting it.
3. Switch off what only runs in office hours
Development and staging environments rarely need to run through the night and the weekend. An environment that runs 50 hours a week instead of all 168 costs roughly 70% less to run. A simple schedule that stops it in the evening and starts it in the morning is one of the cheapest wins there is.
4. Right-size servers and databases
Servers are usually bought for a peak that never came. AWS Compute Optimizer looks at real usage and recommends smaller sizes, and AWS says right-sizing this way can reduce costs by up to 25%. Look at CPU and memory over several weeks, not a single quiet day, and apply the same thinking to databases, which are often the most oversized thing in the account.
5. Move to newer, cheaper types
Two changes are worth checking in almost every account:
- Graviton servers. AWS says its Graviton-based instances deliver up to 40% better price performance than comparable instances. Most Node.js, Python and Java workloads run on them unchanged, but test yours before you switch production.
- gp3 storage instead of gp2. AWS prices gp3 volumes about 20% lower per GB than gp2 ($0.08 against $0.10 per GB-month in its published pricing), and an existing volume can be changed in place.
6. Store data in the right class
Data that’s rarely read doesn’t need the fastest, most expensive storage. Lifecycle rules can move old files in S3 to cheaper classes automatically, and S3 Intelligent-Tiering does it for data with unpredictable access. Check your logs too: CloudWatch keeps log groups forever by default, so set a retention period that matches how long you actually need them.
7. Cut data transfer and NAT charges
Data transfer is the line item people understand least. A common example: servers in private subnets reach the internet, and often other AWS services, through a NAT gateway, which charges for every gigabyte it processes on top of an hourly fee. In US East (Ohio), AWS lists both at $0.045, per hour and per GB. Traffic to S3 and DynamoDB can go through gateway endpoints instead, which AWS doesn’t charge for. For public traffic, serving files through CloudFront is often cheaper than serving them straight from your servers.
8. Commit to Savings Plans and use Spot, last
Once the account is clean and right-sized, commit to what’s left. Savings Plans trade a one- or three-year spending commitment for a lower price, up to 72% off according to AWS. Commit to your steady baseline, not your peak, so you never pay for capacity you don’t use.
For work that can be interrupted, like batch jobs, build pipelines and workers that can pick up where they left off, Spot capacity costs up to 90% less than standard pricing. It’s the wrong choice for anything that must stay up without interruption.
9. Stop it creeping back
- Keep the budget alerts from step 1, and turn on AWS Cost Anomaly Detection for sudden jumps.
- Require tags on new resources, so nothing turns up on the bill without an owner.
- Review the bill once a month, with the same grouping, and ask about anything that moved.
- Track cost per customer or per transaction, so you can tell healthy growth from waste.
What about Google Cloud?
The same order works on GCP: billing reports grouped by label, idle resource recommendations, then committed use discounts and Spot VMs for the steady and the interruptible parts of your workload. We run both, so the advice above carries over almost one for one.
If your bill keeps growing and nobody can say why, that’s the first thing we look at in a managed cloud engagement: one week reviewing the account, then a written list of what to fix, in this order, with what each change should save.