Cloud Cost Creep: A Practical Checklist for AWS & Azure Housekeeping

No one decides to waste money on cloud infrastructure. It happens gradually: a test environment that was supposed to be temporary, a database sized for a launch spike that never got downsized after, a snapshot policy nobody revisited. Individually, each one is small. Together, they’re often 20-30% of a cloud bill doing nothing useful.

Here’s what we check first during a maintenance pass on a client’s AWS or Azure environment.

1. Orphaned storage and snapshots

Unattached EBS volumes, old AMIs nobody boots from anymore, snapshot chains going back years with no retention policy - storage is cheap per-GB but it adds up fast when nothing is ever deleted. A retention policy that actually gets enforced (not just documented) is the single highest-leverage fix here.

2. Right-sizing compute after the fact

Instances are almost always sized for peak load at launch and never revisited. Pull utilization metrics over the last 30-90 days - if a VM is consistently running at 8% CPU, it’s not “safety margin,” it’s a downsizing opportunity. This is also where reserved instances or savings plans pay off, but only once the baseline sizing is actually correct.

3. Non-production environments running 24/7

Staging and dev environments that mirror production’s uptime are one of the most common sources of avoidable spend. Scheduled start/stop (or scale-to-zero where the architecture allows it) outside business hours alone can cut non-prod compute costs by well over half.

4. Data transfer you didn’t design for

Cross-region and cross-AZ traffic, and traffic routed through a NAT gateway that didn’t need to be, shows up as a diffuse line item that’s easy to miss until you go looking. Architecture decisions made early - like which AZ a database sits in relative to its application tier - often turn into a recurring cost nobody connects back to the original design choice.

5. Alerting on cost, not just on uptime

Most teams have solid uptime and error-rate alerting and no cost alerting at all, so a misconfiguration that spins up unexpectedly expensive resources can run for weeks before anyone notices it on an invoice. A budget alert with a sane threshold catches this in days instead of billing cycles.

None of this requires a rewrite or a migration - it’s housekeeping. But it’s the kind of housekeeping that’s easy to defer indefinitely unless someone is actually looking at it on a regular cadence, which is exactly the gap ongoing cloud maintenance is meant to close.

“Individually, each one is small. Together, they're often 20-30% of a cloud bill doing nothing useful.”

Mateusz Konicki