Explanation
Why the waste happens and who it affects.
Typical sources are VMs left over from finished projects, migrations, proofs of concept, debugging sessions and one-off jobs, and replacement VMs whose predecessors were never removed. A running VM bills for its vCPUs and memory every second regardless of utilization, and attached GPUs, premium OS licenses, disks and external IPs add to the cost.
This is a different problem from an oversized VM. Rightsizing an idle VM to a smaller machine type still pays for a machine nobody uses; the fix is to stop or delete it.
Billing model
The pricing dimensions that drive this cost.
Rates depend on machine series, region and any discounts.
- vCPU and memory
- Billed per second (one-minute minimum) while the VM is in the RUNNING state, regardless of utilization
- GPUs and premium images
- Billed while the VM runs, on top of vCPU and memory
- Attached disks and IPs
- Durable disks and external IP addresses are billed while they exist, whatever the VM state
- Stopped VM
- A VM in the TERMINATED state stops vCPU and memory charges, but attached disks and addresses keep billing
How to detect
4 checks to find it in your estate.
- Review the Idle VM recommender (google.compute.instance.IdleResourceRecommender, "Remove unused VMs") in Active Assist or with gcloud recommender recommendations list --recommender=google.compute.instance.IdleResourceRecommender --location=ZONE; it classifies VMs as idle from CPU and network usage over an observation period of 14 days by default (configurable from 1 to 14 days)
- Use the costProjection in each recommendation to rank idle VMs by estimated monthly savings
- Cover the VMs the recommender skips - instances with local SSDs or GPUs/TPUs - with metrics: compute.googleapis.com/instance/cpu/utilization and instance/network/received_bytes_count and sent_bytes_count staying near baseline for weeks (GKE, Dataflow and App Engine flexible VMs are also excluded and should be handled in those services)
- Check owner labels, last deployment and last login to separate forgotten VMs from standby machines with a real purpose
How to fix
4 ways to remove the waste.
- Confirm with the owner, then delete VMs that are no longer needed; take a snapshot of the disks or create a machine image first if the state might be needed again
- Applying the idle VM recommendation stops the VM; stopping ends vCPU and memory charges, but attached disks and IP addresses keep billing, so follow up with deletion for VMs that will not return
- For VMs needed only occasionally, stop them or suspend them (suspended VMs keep billing for memory while suspended and can stay suspended for up to 60 days) and use an instance schedule for predictable usage
- Require owner and environment labels so idle recommendations can be routed to the right team
Documentation
Vendor references for pricing and configuration.