Most teams do not overspend on cloud infrastructure because of one bad decision. They overspend because dozens of small, invisible decisions compound: an instance that outlived its project, a snapshot policy nobody owns, a database sized for a launch that never came. Respondents to Flexera's annual State of the Cloud survey consistently self-estimate their cloud waste in the 25–30% range, and that number has barely moved in years.
The short version: if you audit five areas — idle resources, over-provisioning, storage lifecycle, inter-zone traffic, and discount coverage — you will find the large majority of recoverable spend, usually within a week of work. The harder problem is not finding waste once; it is noticing it continuously as the infrastructure changes underneath you.
The audit checklist
| # | Waste category | What to look for | First fix |
|---|---|---|---|
| 1 | Idle compute | Instances with CPU utilization under ~5% for 14+ days | Stop, then right-size or terminate after owner confirmation |
| 2 | Over-provisioning | Instance sizes chosen by default or by copy-paste | Match size to observed p95 usage, not peak guesses |
| 3 | Unattached storage | Volumes and snapshots with no attached instance | Snapshot, then delete; set snapshot retention policy |
| 4 | Old storage tiers | Data on premium tiers untouched for 90+ days | Move to infrequent-access or archive tiers |
| 5 | Cross-zone traffic | Chatty services spread across availability zones | Co-locate peers in the same zone where redundancy allows |
| 6 | Missing discounts | Steady on-demand usage with no commitment coverage | Cover the stable baseline with Savings Plans / RIs / CUDs |
| 7 | Orphaned IPs and load balancers | Elastic IPs with no binding, balancers with no backends | Release after a tag-audit sweep |
| 8 | Untagged resources | Anything you cannot map to an owner or product | Enforce tagging at provision time, not after |
1. Idle compute is usually the biggest single line
Every cloud provider exposes CPU utilization metrics per instance, and every provider's default dashboards make it easy to ignore. The pattern worth automating is simple: any instance whose CPU stays under ~5% and network I/O stays near zero for two weeks is a candidate for shutdown. Development and staging environments that run 24/7 are the most common offenders — they need to exist, but not at 3 a.m. on a Sunday.
The catch is ownership. Stopping an instance nobody claims is politically harder than it should be, which is why tag discipline (item 8 in the table) is on the same checklist: you cannot ask an owner a question you cannot route.
2. Right-size against observed usage, not launch-day guesses
Sizing decisions are usually made before an application exists, using rules of thumb, and never revisited. The corrective is boring and effective: take 30 days of utilization percentiles, pick the instance family and size where p95 fits comfortably, and accept that you will revisit it quarterly. A database sized for "the day we get on the front page" that serves a few hundred requests per minute is paying a tax every hour of every day for a scenario that has not happened.
3. Storage does not clean up after itself
Snapshots are cheap, which is exactly why they accumulate: a daily snapshot job with no retention window becomes thousands of snapshots pointing at volumes that no longer exist. The audit questions are concrete. Which snapshots are older than your stated retention policy? Which volumes have been unattached for more than a week? Which buckets hold data that has not been read this quarter? None of these require tooling sophistication to answer — they require someone to be responsible for asking.
4. Commitment coverage is free money you are leaving on the table
Once your baseline is stable for a month or two, the portion of spend that runs around the clock should be covered by a commitment — Savings Plans on AWS, Committed Use Discounts on GCP, Reserved Instances on Azure. The discount for a one-year commitment is meaningful, and the risk is low when you only commit to the baseline you have actually observed. The classic mistake is the opposite extreme: committing too much after a sales conversation, then paying for capacity the workload never used.
Why one-off audits stop working
Every item above is findable with a spreadsheet and a free afternoon. What makes cloud cost hard is that the audit decays immediately: you clean up on Monday, and by Friday a new environment, a new snapshot policy, or a new over-provisioned service has started the accumulation again. That gap — between a static audit and continuous monitoring — is exactly where we built Costmatic, with AI agents that watch utilization and spending patterns continuously and flag waste the moment it appears, before it compounds.
Frequently asked questions
How much of my bill is realistically recoverable? It depends on how long the account has run without an audit. Industry surveys put self-estimated waste around a quarter of total spend; a first serious pass on an unmanaged account often finds more, a well-run one finds low single digits.
Should I start with a cost tool or a manual audit? Start manual. You will learn where your waste actually lives, and you will be able to judge any tool's suggestions instead of trusting them blindly. Tooling earns its keep on the continuous-monitoring side, where manual sweeps cannot keep up.
Is stopping and restarting instances risky? For stateless compute, no — that is the design intent. For anything with local state, snapshot first and confirm the owner before stopping. When in doubt, right-size at the next scheduled maintenance window instead.