Idle Cloud Resources: How ZopNight Proves Non-Use
An idle finding needs every traffic signal at zero over a full window, and it always names the lever that recovers the cost.
The idle category covers resources that are running, still billing, and measurably unused. That definition is narrower than “low utilization”: a VM at 3% CPU is a rightsizing question, while a load balancer that forwarded no bytes for a month is idle.
Idle is decided by the lever, not the label
ZopNight’s rules follow one principle for idle compute: a recurring schedule, never a one-shot stop. A stop is an outage, not a cost lever, so an idle VM finding is titled “Schedule … to stop during off-hours” and a pausable service gets “Schedule … to pause”. Only resources that can genuinely be removed get “Delete unused …”, and the word is “unused” rather than “unattached” on purpose: an idle NAT gateway is still attached to its VPC. When a rule cannot resolve any lever, it writes prose instead of borrowing a wrong verb.
What “no use” means on each cloud
Each rule reads the specific signals its service publishes, and requires all of them to be quiet:
- AWS: Idle NAT Gateway needs all five CloudWatch counters (active connections plus four byte directions) at zero for 30 days. Idle Load Balancer reads request, connection, flow, byte and LCU axes by exact name, because an ALB with no targets emits no request datapoints at all. ElastiCache Cluster Idle needs four metric axes covered for 30 days. See AWS idle findings.
- GCP: GKE Idle Load Balancer and GCP Idle Global Load Balancer require every present traffic axis below a small floor on both average and peak. GCP Memorystore Instance Idle requires zero connections, with ops per second as a corroborating veto. See GCP idle findings.
- Azure: Azure Redis Cache Idle needs both connected clients and operations below floor on average and maximum. Azure Load Balancer with No Backends checks the backend pool and byte counts. Idle Azure App Service Plan fires when a plan hosts zero apps. See Azure idle findings.
A missing metric series is treated as a data gap, not as idleness, so an uninstrumented resource abstains instead of being flagged.
Acting on an idle finding
Idle findings with a delete lever, such as an idle EFS file system or an idle Azure Event Hub, can run through the remediation wizard with its precondition and approval steps. Idle compute routes to a schedule instead: see resource scheduling for how start/stop windows, overrides and notifications work, and idle detection for the wider workflow. Some idle rules are advisory by design. Idle RDS Instance, for example, still reports its saving but has no one-click stop, because a single stop cannot deliver a saving priced on removal.
Every idle resource check ZopNight runs has its own page, with the reason it fires and the fix: see the idle resource checks in the ZopNight rule catalogue.
Questions we get a lot.
Why was my quiet resource not flagged?
Idle rules abstain whenever a required metric is missing or does not cover the full window. A resource with no monitoring data is never assumed idle.
Will ZopNight stop an idle VM automatically?
No. One-shot stops on compute are demoted to advisory by the safety gate. The recommended fix for idle compute is a recurring schedule you create and control.