Always-on production Compute Engine VMs paying on-demand rates
What does ZopNight detect here?
Production Compute Engine VMs are flagged when 60 days of history show at least 70% uptime and CPU or memory averaging 30% or more, with no committed purchase already recorded for them. Resource-based commitments bought with `gcloud compute commitments create` discount vCPUs and memory by up to 55% for most machine types.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-1206 |
| Category | discount |
| Severity | low |
| Metric | compute.googleapis.com/instance/cpu/utilization |
| Threshold | 70% uptime and 30% average CPU or memory |
| Evaluation window | 60d |
| Source | ZopNight |
| Permissions used | compute.instances.list · compute.commitments.list · monitoring.timeSeries.list |
Where it applies
How resource-based commitments price a steady VM
A resource-based commitment is a promise to pay for a fixed amount of vCPU and memory of one machine series in one region for one or three years. Google’s commitment guide puts the discount at up to 55% off on-demand for vCPUs and memory on most machine types, and up to 70% on some. The commitment becomes active at midnight Pacific time the day after purchase, and it cannot be cancelled: it stays active, and billed, until its end date.
That makes the decision simple in principle: commit to the capacity that is always running, and leave anything that scales up and down on demand.
Looking at what is already committed
Start by checking existing commitments so you do not double-buy:
gcloud compute commitments listThen compare with the VMs you consider always-on, for example by charting
compute.googleapis.com/instance/cpu/utilization over 60 days for your production instances and
grouping them by machine series and region.
Evidence ZopNight requires first
- The VM’s name marks it as production: it contains
prod,productionorlive. - No committed purchase type is recorded against the VM.
- There are at least 60 days of history, with the VM running at least 70% of the time.
- Measured CPU or memory utilisation averages at least 30%.
- The VM has a known cost and Google’s live rates show a positive commitment discount.
Where ZopNight says nothing
Any failed gate means no finding, as does a VM with no utilisation measurements at all. A break-even test compares a commitment billed for all 730 hours of a month with on-demand for the hours the VM actually ran, and suppresses the finding when the commitment would cost more. Commitments are regional rather than tied to a VM, so check the list above before buying. Labels are not used to detect production here; only the name is.
The saving figure
saving = on-demand cost for measured running hours - commitment cost at 730 h/monthfallback without running-hour data: saving = monthly cost x live commitment discountThe recommendation quotes the resulting percentage for that VM.
Committing to the baseline
- Confirm the workload will stay in this region and machine series for the term.
- Total the vCPUs and memory that stay running across similar VMs in the region.
- Buy a commitment for that baseline, for example:
gcloud compute commitments create prod-n2-1y --plan=12-month --type=general-purpose-n2 --resources=vcpu=16,memory=64GB --region=us-central1. - Leave bursty or short-lived capacity on demand, or use a Spot option where it fits.