- Cloud & DevOps
- Cost Optimization
- AWS
- Azure
Why Is Our Cloud Bill So High? 9 Fixes I Check First
Cloud costs rarely explode overnight. They creep. Here are the nine places I look first when a company asks why its AWS, Azure or Google Cloud bill keeps climbing, starting with the quick wins.

Nobody decides to waste money on cloud. It happens one reasonable decision at a time: a bigger database "for the launch," a test environment someone forgot about, logs kept forever because nobody set a limit.
When a company asks me to look at its bill, I start with the same nine checks. Most take an afternoon. Here they are, roughly in the order they pay off.
The short version
| Fix | Effort | Typical impact |
|---|---|---|
| 1. Remove idle and forgotten resources | Low | Medium |
| 2. Right-size oversized servers | Low | High |
| 3. Schedule non-production environments | Low | Medium |
| 4. Commit to discounts for steady workloads | Low | High |
| 5. Set storage lifecycle rules | Low | Medium |
| 6. Control log and monitoring volume | Medium | Medium |
| 7. Reduce data transfer | Medium | Medium to high |
| 8. Review managed service tiers | Medium | Medium |
| 9. Tag everything and assign owners | Medium | High, over time |
The impact depends heavily on your setup, so treat the last column as a guide rather than a promise.
1. Remove idle and forgotten resources
Every account I review has some: unattached storage volumes, old snapshots, load balancers pointing at nothing, IP addresses reserved for servers that no longer exist. Each one is small. Together they add up.
On AWS, this lists storage volumes that aren't attached to anything:
aws ec2 describe-volumes \
--filters Name=status,Values=available \
--query "Volumes[].{ID:VolumeId,SizeGiB:Size,Created:CreateTime}" \
--output tableAzure Advisor and Google Cloud's recommender show the same kind of waste. Check each item before deleting it, take a final snapshot if there's any doubt, then remove it.
2. Right-size oversized servers
Servers get sized for the worst day anyone can imagine, then never revisited. If a machine averages 10 percent CPU for months, it's too big. All three major providers have right-sizing recommendations built in. Start with the largest instances, because that's where the money is.
3. Schedule non-production environments
Development, testing and staging environments rarely need to run at night or on weekends. Shutting them down outside working hours cuts their running time by more than half, and most teams only notice the difference on the invoice.

4. Commit to discounts for steady workloads
If a workload runs all day, every day, paying on-demand prices leaves money on the table. Savings plans, reserved instances and committed-use discounts trade some flexibility for a lower rate. Commit only to the baseline you're confident about, and review it every quarter.
5. Set storage lifecycle rules
Object storage is cheap per gigabyte, which is exactly why it grows without anyone watching. Move older data to cheaper storage tiers automatically, and delete what you're not required to keep. Backups in particular pile up with no expiry date.
6. Control log and monitoring volume
Logging everything at debug level in production is expensive and rarely useful. Decide what you actually need, set retention periods, and sample high-volume, low-value logs. The same goes for custom metrics, which are often priced per series.
7. Reduce data transfer
Data transfer is the line item that surprises people most. Traffic between regions or availability zones, and traffic out to the internet, can cost more than the servers sending it. Keep services that talk constantly close together, put a CDN in front of public content, and look at where your largest transfers actually go.

8. Review managed service tiers
Managed databases, queues and search services are worth paying for, but their tiers get chosen once and never revisited. A high-availability database running in a test environment is a common example. Match each tier to what that environment actually needs.
9. Tag everything and assign owners
This one doesn't save money on day one. It's what stops the savings from disappearing. When every resource has a team, project and environment tag, you can see who is spending what, and cost becomes a normal planning topic instead of a quarterly surprise. That shared ownership of cloud spend is the core idea behind FinOps.
What I wouldn't cut: backups you've actually tested, security tooling, and redundancy for systems your customers rely on. Saving money by making an outage more likely isn't saving money.

A 30-day plan
Week 1. Turn on cost reporting by service and by tag. Find your ten most expensive resources.
Week 2. Clean up idle resources and right-size the biggest offenders.
Week 3. Schedule non-production environments, and set storage and log retention.
Week 4. Review commitments for steady workloads and agree on a tagging standard.
By the end of the month you'll have real savings and, more importantly, a habit that keeps them.
If you'd like someone to go through your AWS, Azure or Google Cloud account with you, let's talk. I'll start with the checks above and give you a prioritized list you can act on.
Views here are my own and don't represent any current or past employer or client. This is general information, not professional advice for your situation. Full disclaimer
Working on something similar?
I help businesses and founders design and build software like this. Book a free call or send a few details about your project.