How to Find and Safely Delete Orphaned Google Cloud Resources

Google Cloud bills rarely spike from one big mistake. They creep up from small, forgotten resources that keep billing long after anyone needs them — and because GCP resources are scattered across projects, regions, and zones, those orphans hide where nobody is looking. A persistent disk detached in us-central1 and a static IP stranded in europe-west1 never show up on the same screen.

The most common Google Cloud orphans

• Unattached persistent disks — a Compute Engine VM is deleted but its data disks linger, billing per GB-month whether or not anything is attached to them.
• Reserved static IP addresses with nothing behind them — a reserved external IP that is not attached to a running resource bills hourly. A handful of stranded addresses is a silent recurring charge.
• Old snapshots and custom images — disk snapshots and the images built from them pile up with no retention policy, each billing for storage indefinitely.
• Idle load balancers — forwarding rules and target pools bill even when there are no healthy backends behind them.
• Stopped (TERMINATED) VMs — stopping an instance stops the CPU charge, but its attached persistent disks keep billing. "Stopped" is not "free."
• Forgotten Cloud SQL instances — a non-production database left running keeps charging for its instance and allocated storage, plus backups.
• Abandoned GKE node pools — a cluster kept around for one test workload can hold an entire node pool of VMs billing around the clock.

Why finding them by hand is painful

The Cloud Console shows you resources, but it does not tell you which ones are *unused* — and it scopes them by project, region, and zone. To find orphans by hand you have to sweep every project, cross-reference which disks are attached and which IPs are in use, check Cloud Monitoring for activity, and confirm nothing depends on a resource before you delete it. Across an organization with dozens of projects, that is hours of tedious work — and one wrong delete can take down production.

Google Cloud billing gotchas that make orphans worse

A few GCP-specific traps catch teams repeatedly: a stopped VM still bills for its persistent disks; a reserved static IP that is not attached bills hourly while an ephemeral one would have been free; deleting a disk is not the same as deleting its snapshots; and a committed use discount keeps billing whether or not you are still running the resources it was meant to cover. Each is small on its own, which is exactly why it survives — no single line item is big enough to investigate.

A faster, safer approach

This is exactly what CloudRift was built for. It connects with a read-only service account and uses Cloud Asset Inventory to scan your project — Compute Engine instances, persistent disks, snapshots, external addresses, load balancers, Cloud Storage, Cloud SQL, and GKE — flags the resources with explicit orphan signals (an unattached disk, a reserved-but-unused address, a terminated instance still holding storage), joins each to its real cost from your BigQuery billing export, and runs a dependency check before anything is deleted.

You connect, run a scan, and within minutes you have a prioritized list of wasted spend with the dollar amount attached to each item — and a confidence signal behind every flag, so you know which ones are safe to action today.

The bottom line

Orphaned resources are the lowest-risk, highest-confidence savings in any Google Cloud project. Sweep every project, clean up the unattached disks and stranded static IPs first, put labels and snapshot-retention policies in place, and re-scan on a schedule so they never pile up again.