We take over management of an existing cloud environment every few months. The pattern in the first conversation is almost always the same: the client knows their bill went up, doesn't fully understand why, and has been meaning to look into it for a while.
Usually there's a real explanation that has nothing to do with "your traffic grew." Here are the three we see most often.
Data transfer you forgot was metered
Hyperscalers are generous about compute costs in marketing materials. Egress pricing is much less visible. When a client moves data out of their cloud — backups to an external provider, API responses to users in other regions, logs shipped to a third-party observability service — they're often paying per gigabyte and not tracking it.
The surprise usually hits when traffic grows a bit, because egress scales with it. A service that was moving 400 GB/month of data out might move 900 GB a few months later after a product launch, and nothing in the billing dashboard makes the connection obvious.
The fix isn't always to move everything in-house. Sometimes it's to cache more aggressively, or to run the log aggregation inside the same region. But you can't make that call if you don't know what's being transferred.
Reserved instances that expired
This one is predictable but it still catches people. Reserved instances or committed use discounts run for one or three years. When they expire, the underlying compute continues at on-demand pricing, which can be substantially higher. The instance keeps running; the reservation ends quietly; the bill goes up on the next cycle.
If you set these up two years ago and didn't put a calendar reminder for renewal, you probably forgot. Renewal isn't automatic in most configurations. We've taken over environments where reserved instances had lapsed six months earlier and nobody had connected the billing increase to that specific event.
The remediation is straightforward once you know what happened, but you have to know what to look for.
Snapshots and backups nobody decommissioned
When a developer spins up a test environment, makes snapshots during development, then decommissions the instances — the snapshots often remain. Each one sits in storage accumulating monthly charges that appear as a small line item in a crowded bill.
Individually they're cheap. Collectively, across a few years of development activity, they can represent a meaningful fraction of storage costs. We ran an audit for a client last autumn and found they were paying to store snapshots of machines that had been terminated in 2022. Nobody had cleaned them up because nobody had made it anyone's job to clean them up.
Storage audits are unglamorous work. They're also usually worth a few hundred euros a month once you do one.
What to actually do about this
The billing dashboards on major cloud platforms show you a lot of data. What they don't do well is surface change — they don't make it obvious that egress went up while compute stayed flat, or that a line item that used to be in the bill disappeared because a reservation lapsed and got rolled into a different category.
If you're managing your own infrastructure, the most useful thing you can do is set up budget alerts, look at month-on-month deltas by service category, and schedule a quarterly storage audit to identify things that can be decommissioned. If that sounds like more overhead than you want to carry, it's roughly what a managed environment removes from your plate.