GCP Orphans: Stopped VMs, Unattached Disks, Old Snapshots
A terminated GCE VM stops charging for CPU and memory, but its disks and addresses carry on until someone deletes them.
Google Cloud bills compute separately from what is attached to it. A VM in the TERMINATED state incurs no CPU or memory charges, but its disks and external IP addresses keep billing for as long as they exist. The GCP orphan rules are built around finding that residual and proving nothing still needs it.
A stopped VM, priced by what it leaves behind
Stopped Standalone GCE VM looks for VMs in TERMINATED state that are not members of a managed instance group or a GKE node pool, whose lifecycle belongs to their parent. It then walks the VM’s attached disks and reserved static IPs, prices each one, and reports their sum. If nothing attached has a cost, the rule does not fire. See the Compute Engine fact sheet.
Disks and snapshots
- Unattached GCP Persistent Disk fires on a ready disk with no users, unattached for at least seven days, and skips disks managed by Kubernetes. Because it can prove that dwell, it is one of the rules the safety gate allows to delete automatically. See persistent disks.
- GCP Old Disk Snapshot fires on snapshots older than 90 days. Age alone does not prove the source disk is gone, so this finding stays advisory and a person decides.
An honest gap: the discoverer rolls snapshots whose source disk has been deleted into a separate aggregate that no GCP rule owns yet, so those do not currently raise a finding.
Vertex AI leftovers
- GCP Vertex AI Notebook Stopped prices the boot and data disks a stopped notebook still holds.
- GCP Vertex AI Model Not Deployed fires on a registered model with zero deployments, priced from its billed storage.
- GCP Vertex AI Vector Search Index Not Deployed covers indexes with no endpoint.
Inside GKE
The Kubernetes workload rules add three orphan checks on GKE: Unbound PVC, Released PersistentVolume and Service With No Endpoints. They sit alongside the node pool findings in GCP GKE.
Deleting safely
Orphan deletes run through the remediation wizard: a precondition check, an admin approval for destructive steps started by non-admins, the delete, then validation. Anything stateful, or without authoritative evidence, is demoted to advisory. Deletes need a read + write connection. More on the workflow in orphan cleanup, other GCP categories in GCP idle findings, and every rule in GCP recommendations.