Production VMs paying on-demand rates with no committed use discount
What does ZopNight detect here?
Production-named GCE VMs still paying on-demand rates are candidates for 1- or 3-year committed use discounts. ZopNight requires at least 60 days of observed history, derives the discount from live tier rates, and runs a break-even test at 730 hours/month so part-time VMs never get locked in.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-1206 |
| Category | discount |
| Severity | low |
| Metric | none — pure configuration read |
| Source | vm_committed_use.go |
Where it applies
Commitments bill whether you run or not
A committed use discount is a promise to pay for a fixed amount of vCPU and memory in a region for 1 or 3 years. The discount is real, but so is the obligation: a CUD bills every month of its term regardless of whether the committed capacity is actually running. That inversion, the discount instrument itself becoming waste, is why this rule spends most of its logic deciding when not to recommend one.
Discipline gates before an irreversible buy
Only VMs with a production-shaped name are considered, and a VM whose cost data already shows committed coverage is skipped. Then the commitment-eligibility check demands at least 60 days of observed history, high uptime, and meaningful CPU or memory utilization. A VM that runs part-time belongs in a schedule; an underutilized one belongs in rightsizing. Locking either into a multi-year commitment would cement the waste, so the rule abstains for both.
Break-even beats a flat discount claim
The discount fraction comes from live tier rates, never a published-average assumption. On top of that, a break-even comparison prices the commitment at its full 730 hours a month against on-demand billed on the VM’s measured running hours. A VM that is up 80% of the time gets credited far less than the headline percentage, and one below break-even gets nothing. The percentage shown in the recommendation is back-computed from the actual capped saving, so the “why” always matches the dollars.
List existing commitments first
gcloud compute commitments list \ --format="table(name,region,status,plan,endTimestamp)"One caveat worth knowing: GCP applies CUDs at the account/region/family level, not per VM, and the billing pipeline cannot yet attribute that coverage down to individual instances in every case, so a VM already covered by a family-level CUD can still appear here. The commitments list above is the authoritative cross-check before buying more.
Reasons the rule holds back
No recommendation is emitted for non-production names, VMs with visible committed coverage, unknown or zero cost, insufficient history or uptime, missing live tier rates, a derived fraction of zero, or a break-even result that says the commitment loses money.