Skip to content
All articles
  • 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.

Arsalan SadiqArsalan Sadiq 4 min read
A hand tightening a valve beneath a cloud shape that is leaking glowing particles

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

FixEffortTypical impact
1. Remove idle and forgotten resourcesLowMedium
2. Right-size oversized serversLowHigh
3. Schedule non-production environmentsLowMedium
4. Commit to discounts for steady workloadsLowHigh
5. Set storage lifecycle rulesLowMedium
6. Control log and monitoring volumeMediumMedium
7. Reduce data transferMediumMedium to high
8. Review managed service tiersMediumMedium
9. Tag everything and assign ownersMediumHigh, 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 table

Azure 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.

An office at night with every light off except one desk lamp

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.

Glowing lines arcing between distant points on a dark world map, a few thick lines among many thin ones

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 small team at a whiteboard sorting colour-coded sticky notes into columns

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.