Where your cloud bill actually leaks

When a founder tells me their cloud bill “keeps growing”, the first question I ask is: growing because of customers, or growing on its own?

Growth that follows usage is fine. That’s the business working. The money I look for is the other kind: spend that rises while nobody is using more, because things get created and nothing gets removed.

Here’s where it usually hides.

1. Environments that never sleep

Development, staging, demo and test environments often run 24 hours a day, 7 days a week. Your team uses them maybe 50 hours a week.

Schedule non-production environments to stop outside working hours, or build them on demand from code and tear them down after. If your infrastructure is defined as code, recreating an environment is one command, so there’s no reason to keep it running “just in case”.

2. Servers sized for a guess

Instances are usually sized once, at launch, based on what someone thought the load might be. Then nobody looks again.

Pull a few weeks of CPU and memory metrics. A server that never goes above 15% CPU is paying for capacity it doesn’t use. (Right-sizing safely deserves its own post, so I wrote one: right-sizing without breaking production.)

3. Things that outlived their purpose

Every cloud account collects leftovers:

• Disks from servers that were deleted
• Old snapshots and machine images nobody will restore
• Reserved IP addresses attached to nothing
• Load balancers in front of nothing
• Test databases from a spike two quarters ago

Each one is small. Together they’re often a noticeable share of the bill, and they never shrink on their own.

4. Logs and backups kept forever

Retention is easy to set once and forget. Logs kept for years in expensive storage, backups with no expiry, and buckets with no lifecycle rules all grow every single day.

Decide how long you actually need each kind of data, write it into the configuration, and move older data to cheaper storage tiers.

5. Traffic you didn’t know you were paying for

Data moving between regions, out to the internet, or through a NAT gateway is billed separately, and it surprises people. A chatty service in the wrong region, or a backup job copying data across zones, can quietly cost more than the servers.

6. Plans that upgrade every few months

Managed platforms that price by usage are great early on. But if you’re moving up a plan every two or three months, look at the curve. On one healthcare platform, moving off a managed backend to a dedicated server stopped those regular upgrades, and the platform got faster at the same time.

That isn’t always the right call. It should be a decision, not something that happens to you.

7. Nobody owns the bill

This is the root of most of the above. If a resource has no owner, nobody notices when it stops being needed.

The fix is boring and effective:

• Tag everything with an owner, project and environment
• Create resources only through code, so every resource has a commit and an author
• Review the bill monthly, grouped by tag, with the people who own each line
• Set budget alerts, so a spike is a notification this week, not a surprise next month

What I don’t start with

Commitment discounts and savings plans can cut costs a lot, but I do them last. Committing to a year of capacity before you’ve removed waste just locks the waste in.

How I run a cost review

1. Pull the last few months of the bill, broken down by service and tag
2. Find the top spend lines and ask “who uses this, and how much?” for each
3. List leftovers, idle resources and oversized servers
4. Show each proposed saving line by line, with the risk, before changing anything
5. Make changes through code, one at a time, and watch the metrics after each

The goal isn’t the cheapest possible bill. It’s a bill where every line has a reason and an owner.