Why this matters
Idle resources in Google Cloud rarely look like one big mistake. They look like an unattached persistent disk, a reserved static IP address, a stopped VM with a boot disk, an old snapshot, or a load balancer with no backends. Each item is small. Together they keep charging every month, and nobody owns them.
This work is not the same as rightsizing. Rightsizing changes a machine type or disk size. Idle cleanup removes a resource that no workload uses. You need evidence before you delete, because a quiet resource can still be a dependency.
The aim is to cut waste without breaking a service. A disk can be a backup target. A static IP can sit in a DNS record. A service account can be unused but still bound to a role. Treat every candidate as a change with an owner, a check, and a rollback.
Before you start
Pick a scope. Start with one folder or a small set of projects. Do not start with the whole organization unless you have owners for every project. List the billing account, the projects, and the people who can approve changes.
Get read access first. You need roles such as Cloud Asset Viewer, Monitoring Viewer, Billing Account Viewer, and Recommender Viewer. Give delete rights later, to a smaller group. Use a service account for exports and keep its keys in Secret Manager.
Export the raw data before you judge anything. Use Cloud Asset Inventory to export resource metadata to BigQuery or Cloud Storage. Turn on billing export to BigQuery from the billing account. Both give you a baseline you can query again later.
Agree on a lookback window. Thirty days is a common start, but use a longer window for seasonal workloads. Label candidates with owner, environment, reason, and a delete-after date. Tell support and finance what you are doing so alerts and reports do not surprise them.
How to do it
Run the sweep in layers. First use Google Cloud Recommender and Active Assist, because they report idle VMs, idle persistent disks, and idle IP addresses with a reason. Then use Cloud Asset Inventory for a full list that includes resources the Recommender does not cover. Finally use billing export to rank the list by cost, so you fix the expensive items first.
Do not delete on the first pass. Stage each candidate. Stop the VM, detach the disk, unpromote the IP, or remove the backend. Keep a snapshot or export. Wait through a full business cycle, then delete. This gives you a rollback path and a record of what changed.
Check dependencies before each change. Use Cloud Audit Logs for recent API calls, VPC Flow Logs for traffic, load balancer logs for requests, and DNS records for name references. If another team owns the resource, ask them to confirm. A short message beats a broken integration.
- Export an asset inventory. Use Cloud Asset Inventory to export resource metadata for the selected projects to BigQuery. Include disks, addresses, instances, forwarding rules, snapshots, SQL instances, and clusters. This gives you one queryable list instead of a project-by-project search.
- Turn on billing export and group by SKU. Export detailed billing data to BigQuery and query the SKUs tied to persistent disk, static IP, snapshots, and compute. Rank candidates by cost, not by count. A few large items often matter more than many small ones.
- Review Google Cloud Recommender findings. Open Active Assist and review the idle VM, idle disk, and idle IP address recommendations. Read the reason and the lookback window for each one. Accept only the items where the owner confirms the resource is not needed.
- Validate last use with logs. Check Cloud Audit Logs, VPC Flow Logs, load balancer logs, and DNS records for the candidate. Look for any read, write, or traffic in the lookback window. A resource with no recent activity is a candidate, not a confirmed deletion.
- Stage the change. Label the resource, then stop, detach, or unpromote it. Keep a snapshot or export where policy requires one. Wait through a full business cycle before you delete the resource.
- Remove the whole chain. Delete forwarding rules, target pools, instance groups, disks, snapshots, and addresses together. Orphaned pieces often keep billing after the VM is gone. Check the load balancer and instance group before you close the ticket.
- Set a guardrail. Add budget alerts, labels, and a monthly review. Require owner signoff and a delete-after date for every candidate. This keeps new idle resources from piling up after the cleanup ends.
How to check it worked
Check the bill at the SKU level, not just the total. Query the billing export for the SKUs tied to persistent disk, static IP, snapshots, and idle compute. Compare full months, because partial months hide the change.
Check the inventory again. Count unattached disks, unused addresses, snapshots past retention, and forwarding rules without backends. Open Recommender and confirm the handled insights are marked as claimed or dismissed with a reason.
Watch for service errors. Check Cloud Monitoring uptime checks, load balancer 5xx rates, DNS failures, and support tickets for the week after a change. Confirm that snapshots exist where policy requires them and that retention jobs are running.
Write the result down. Update the owner label, the CMDB, and the cleanup log. Set a monthly review so new idle resources do not pile up. A cleanup that is not repeated becomes a one-time event.
Mistakes to avoid
Do not use average CPU as the only signal. A standby VM can have low CPU and still be required. Use CPU, network, disk I/O, logs, and owner confirmation together.
Do not forget the attached chain. A stopped VM still bills for its disks. Deleting a VM can leave disks, snapshots, and static IPs behind. A load balancer can keep forwarding rules and health checks after the backend is gone. GKE node pools can recreate nodes if autoscaling is still on.
Do not ignore snapshots and images. Old snapshots are easy to forget and can grow for years. Set a retention policy and label snapshots with the source resource. Check custom images and machine images too.
Do not skip approval or shared dependencies. A VPC connector, DNS record, or service account may be shared. Get owner signoff and use a freeze window for production. If you want an outside review, the Cloud cost audit from Cloudverg is a two-week, fixed price $4,500 read-only review that ranks idle resources and other savings. It is one option among several, and it does not replace your own change control.
Frequently asked questions
How do I find idle resources in Google Cloud?
Start with Google Cloud Recommender and Active Assist for idle VMs, disks, and IP addresses. Then export Cloud Asset Inventory to BigQuery and join it with billing export data. Rank candidates by cost and confirm each one with logs and the owner.
Can I delete a stopped VM to save money?
Not directly. A stopped VM still bills for attached persistent disks and reserved IPs. Snapshot or detach what you need, confirm no one uses it, then delete the VM and its disks. Check load balancers and instance groups too.
How long should I wait before deleting an idle resource?
Wait through a full business cycle, often 30 days, after you stop or detach it. Keep a snapshot or export during the wait. Use a longer window for seasonal or quarterly workloads.