Before recommending any architecture changes, our FinOps reviews start with the same checklist. These four line items alone typically account for a meaningful share of avoidable cloud spend, and none of them require touching the architecture — just cleanup and commitment planning. If you want a rough sense of where your own bill might be leaking money before you call anyone, start here.
1. Idle or Orphaned Storage Volumes
Volumes left behind after an instance is terminated, or storage that was provisioned and never fully attached, are pure waste. Nobody notices because nothing breaks when they sit there unused — they just quietly accumulate on the bill, month after month. A quarterly sweep for orphaned volumes is one of the fastest ways to find spend with zero performance tradeoff, because by definition nothing is using them.
2. Oversized Compute Instances Running Below 20% Utilization
This is almost always the single largest line item in a FinOps review. Instances get provisioned for a peak load that never fully materialized, or resized once during a migration and never revisited since. The fix isn't complicated — rightsize to actual observed utilization rather than the original estimate — but it requires someone to actually pull the utilization data and act on it, which is the step that gets skipped once a system is stable and nobody wants to touch it.
3. Unattached IP Addresses
Reserved IP addresses no longer attached to a running resource are billed whether you're using them or not. They're one of the easiest savings to miss, because they don't show up in compute or storage dashboards — only in the billing detail, usually as a small line item that looks too minor to investigate. Individually small, but they accumulate across a large environment.
4. On-Demand Pricing on Stable, Predictable Workloads
Any workload that's been running steadily for months, with predictable resource needs, is a candidate for reserved capacity or a savings plan instead of on-demand pricing. Paying on-demand rates for workloads that never actually scale down is one of the most common — and most fixable — sources of overspend we see, because the commitment decision often just never got revisited after the workload matured past its experimental phase.
Why These Four, Specifically
None of these four require an architecture review, a redesign, or a migration. They require someone to pull the utilization and billing data and actually look at it — which is exactly the step that gets deprioritized once an environment is stable and "not on fire." That's also why they recur: a system that was clean six months ago accumulates orphaned volumes and unattached IPs again, quietly, unless someone's checking on a cadence.
FAQ
How often should we check for these four issues? Quarterly, at minimum, for any environment above a moderate size. Orphaned resources accumulate continuously, not in one dramatic event, so a one-time cleanup drifts back toward waste within a couple of quarters if nobody's re-checking.
Will rightsizing oversized instances hurt performance? Not if it's done against real utilization data rather than guesswork — that's the entire point of measuring before changing anything. The risk isn't rightsizing itself; it's rightsizing based on assumptions instead of actual usage patterns.
Do these four items apply the same way across AWS, Azure, and Google Cloud? The specific tooling differs, but the pattern is identical across all three, and across most FinOps tooling in general. Every major cloud has an equivalent for orphaned storage, idle compute, unattached IPs, and commitment discounts.