The Idle Resource Problem: Paying for Capacity Nobody Uses
Cloud bills for what is provisioned, not for what is useful. Idle resources are the gap between the two.
An idle cloud resource is one that is provisioned, and therefore billed, but is doing no useful work. Cloud waste is the broader term for spend that produces no business value; idle resources are its most direct form, because the fix does not require changing what an application does, only what is left running or left behind.
The problem persists for a structural reason. Creating a resource is one API call and has an immediate benefit to the person making it. Removing it has no benefit to that person and a small risk that something breaks. Without a process that makes idle capacity visible and owned, it accumulates.
Four kinds of idle
It helps to separate idle by pattern, because each needs a different response:
| Pattern | Example | Typical response |
|---|---|---|
| Idle by the clock | A test environment used 9 to 6 on weekdays, running all week | A recurring start/stop schedule |
| Idle all the time | A VM or database with no meaningful load for weeks | Confirm with the owner, then stop or delete |
| Underused | An instance whose peak load would fit a smaller size | Rightsizing |
| Left behind | An unattached disk, an old snapshot, an unassociated public IP | Delete after a waiting period |
The first and third keep the resource; the second and fourth remove it. Treating everything as “delete candidates” is how cleanup campaigns cause outages, and treating everything as “leave it” is how waste grows.
What counts as evidence
Low CPU on its own is weak evidence. A bastion host, a message consumer waiting for work, or a standby replica can all look idle on CPU while being essential. Stronger signals combine several measurements over a long enough window:
- CPU and network together, since steady network traffic on a quiet CPU suggests the resource is still serving something.
- Connections or requests for databases, caches, and load balancers.
- Attachment state and time since detachment for disks and IPs.
- Recent control-plane activity: who last changed the resource, and when.
The providers’ own recommenders illustrate how conservative the thresholds are. Azure Advisor, for example, recommends shutting down a VM only when P95 of maximum CPU across all cores is below 3%, P100 of average CPU over the last three days is at or below 2%, and outbound network is below 2% over seven days, with a default seven-day lookback that can be changed to 14, 21, 30, 60 or 90 days. Google Cloud’s idle VM recommendations and AWS Compute Optimizer play similar roles on their clouds.
Acting without breaking things
- Prefer reversible actions first: a schedule or a stop before a delete.
- Snapshot or back up stateful resources before removal, and know what that snapshot will cost to keep.
- Give owners a notice period, and record the decision either way.
- Require approval for destructive actions.
How ZopNight handles idle
ZopNight’s recommendations separate these patterns into categories, including idle, schedule, rightsizing, and orphan. Idle compute is turned into a recurring off-hours schedule rather than a one-shot stop, because a stop is an outage, not a cost lever. Schedule recommendations are generated only from recent, continuous metrics, at least 18 days of history in a 21-day window. Where a delete is the right lever, the remediation workflow includes an admin-approval step for destructive operations, and a blast radius check shows what connects to the resource first. Read-only accounts receive the recommendations; acting on them needs read and write access.
Go deeper on the billing side in infrastructure idle costs, on resizing in rightsizing methodology, or follow the step-by-step idle detection guide.
Questions we get a lot.
If yours isn't here, email us and we'll answer directly.
Is low CPU enough to call a server idle?
No. Combine CPU with network, connections or requests, and recent activity over a window of weeks. Azure Advisor's shutdown rule, for example, requires low CPU and low outbound network together.
Should idle resources be deleted?
Only the ones that are idle all the time or left behind, and only after owner confirmation and a backup where state matters. Resources idle only outside working hours are better handled by a schedule.