Compute Engine VMs under 40% average CPU that fit one predefined machine type smaller
What does ZopNight detect here?
Compute Engine VMs often run on a predefined machine type sized for a peak that never came. ZopNight flags VMs whose `CPUUtilization` averaged under 40% with a peak under 50% over 30 days, names the next-smaller predefined type in the same family, and prices the move as the hourly rate difference across 730 hours.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-1207 |
| Category | rightsizing |
| Severity | low |
| Metric | CPUUtilization |
| Threshold | average CPU under 40% and peak under 50% |
| Evaluation window | 30d |
| Source | ZopNight |
| Permissions used | compute.instances.list · compute.instances.get · compute.machineTypes.list · monitoring.timeSeries.list |
Where it applies
A size too big is billed every running hour
Predefined machine types come in steps within a family, and one step down usually halves the
vCPUs: e2-standard-4 to e2-standard-2, n2-standard-8 to n2-standard-4. Compute Engine bills
vCPU and memory for every hour the VM runs, so a VM that never uses half its CPU is paying for
the larger step around the clock.
The fix does not require a custom machine type. Moving to the next predefined size is a stop, a machine type change and a start.
Looking at CPU on your VMs
gcloud compute instances list --filter="status=RUNNING" \ --format="table(name,zone,machineType.basename())"Then chart compute.googleapis.com/instance/cpu/utilization for a candidate over 30 days and
note both the average and the highest value. Google describes it as the fraction of allocated CPU
in use, reported by the hypervisor.
Why both the average and the peak matter
A one-step downsize roughly doubles utilization on the target, so ZopNight is deliberately strict. It reads 30 days of CPU and requires the average to be under 40% and the peak to be under 50%, which leaves about twice the headroom after the move. The peak must be backed by at least 7 days of data. A VM that is calm on average but spiky is not downsized.
Machine types it will not step down
No finding appears for custom machine types, GPU families such as a2 and g2, a VM already at
the bottom of its family, or a type ZopNight cannot place on a ladder. It also needs live rates
for both the current and target types and stays silent if the target is not actually cheaper.
Within e2, the ladder continues below e2-standard-2 through the shared-core e2-medium,
e2-small and e2-micro sizes. A VM that is nearly idle belongs to
Idle GCP VM Instance.
Hourly rate difference over a month
saving = (current type hourly rate - target type hourly rate) x 730, capped at the VM's costChanging to the smaller machine type
- Review memory as well as CPU; Compute Engine’s CPU metric says nothing about memory pressure inside the guest.
- Stop the VM. The machine type guide
explains that the change only works once the VM is
TERMINATED. gcloud compute instances set-machine-type VM_NAME --zone=ZONE --machine-type NEW_MACHINE_TYPE- Start the VM and watch CPU and latency for a week.