# GCP Prod VM Without Committed Use Discount

> 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.

Source: https://zop.dev/integrations/gcp/recommendations/gcp-prod-vm-without-committed-use-discount
Updated: 2026-08-19

---

## 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

```bash
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.