Production VMs that keep passing the reservation break-even test
What does ZopNight detect here?
Committing to a 1-year Reserved Instance only pays off for VMs that actually run, so ZopNight demands 60+ days of observed history, meaningful utilization, and a production signal before recommending one, then prices the saving with a break-even model comparing the RI's 730-hour month against measured on-demand hours.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-211 |
| Category | discount |
| Severity | low |
| Metric | none — pure configuration read |
| Source | reserved_vm.go |
Where it applies
A reservation is a lock-in, treated like one
A 1-year Reserved Instance is an irreversible spend commitment; recommending it casually is how teams end up paying for reservations on VMs they later shut down. ZopNight gates the recommendation on commitment discipline: at least 60 days of observed history, high uptime, and meaningful CPU or memory utilization. A VM that fails those checks is a candidate for rightsizing or scheduling, not for locking in.
Production evidence, not just a name
The workload must look permanent through one of two doors: a production signal (an env-style production tag, or prod, production, prd, live in the name without a dev/test marker), or continuous running with no stop events in the observed state history. Dev/test-named VMs never qualify through the continuous-run door; their cheaper lever is off-hours scheduling.
Break-even math instead of a flat percentage
Where tier rates and measured uptime are available, the rule prices the reservation at a full 730-hour month against on-demand billed on the hours the VM actually ran. A VM up 80% of the time draws a smaller net saving than a true 24/7 workload, and if the comparison says the reservation loses, the recommendation is withheld entirely. Only when break-even inputs are missing does the rule fall back to the ~30% one-year planning estimate with an uptime gate.
Four automatic disqualifiers
Already covered by a Reservation or Savings Plan; carrying a reserved=true tag; belonging to a VM Scale Set (capacity there is elastic by design); or being a Databricks-managed worker whose lifecycle belongs to the workspace. Each of these ends evaluation before any pricing.
Shortlist your own candidates
az vm list -d --query \ "[?powerState=='VM running'].{name:name, size:hardwareProfile.vmSize, rg:resourceGroup}" \ -o tableCross-check the shortlist against a month of uptime before buying anything.
Buying well
Purchase in the portal under Reservations, matching size flexibility group and region to the running VM. Reader covers discovery, Monitoring Reader utilization, and Cost Management Reader the billing view that proves which VMs are still on pay-as-you-go rates.