How to Find and Clean Up Unused GCP Resources Safely

Simple explanation

“Unused resources” are cloud infrastructure components that are still provisioned and billing but are no longer doing useful work. They get left behind through normal development activity: someone deletes a VM but forgets the disk, a test environment stays running after the sprint ends, or a static IP address outlives the service it was attached to.

Cleaning up is not just about deleting things. The real workflow is: find candidates, verify ownership, protect data, remove or downsize, and record your savings. Skipping the verification step is how teams accidentally delete production data. Skipping the recording step is how cleanup efforts lose organisational support.

When to use this

• Your monthly bill is higher than expected and you want to find quick wins
• You have just finished a project, sprint, or proof of concept and need to tear down temporary resources
• Your team is doing a quarterly cost review as part of a FinOps practice
• You received a billing budget alert and need to reduce spend
• You are onboarding to a project and want to understand what is actually in use

How it works

Safe cleanup follows a consistent workflow regardless of the resource type:

1. Identify candidates. Use gcloud list commands, Active Assist recommendations, or billing exports to find resources that appear unused.
2. Verify ownership. Check resource labels for team and environment information. A stopped VM may be intentionally paused for a seasonal workload.
3. Protect data if needed. Create a snapshot or export before deleting any resource that holds data. Snapshots are far cheaper than the original disk and act as a safety net.
4. Delete or downsize. Remove the resource entirely or rightsize it if it is still needed but over-provisioned.
5. Record savings. Note what was removed and its estimated monthly cost. This builds the case for continued cleanup investment.
6. Schedule the next review. Set a recurring calendar reminder or automate candidate detection so waste does not accumulate again.

What to clean up first

Not all unused resources cost the same. This table ranks the most common types by how easy they are to find, how safely they can be removed, and their typical cost impact. Start at the top.

Cloud Asset Inventory vs Active Assist vs billing export

GCP offers several tools for finding unused resources. Each has different strengths, and most teams benefit from using more than one. Use this table to decide which to start with.

Safe cleanup checklist before deleting anything

Run through this checklist before deleting any resource. It takes two minutes and prevents the most common cleanup mistakes.

1. Check the resource’s labels for env, team, and owner information
2. Verify when it was last used. Check lastDetachTimestamp for disks, lastStartTimestamp for VMs, or connection logs for databases
3. Confirm with the owning team that the resource is no longer needed
4. If the resource holds data (disk, database, bucket), create a snapshot or export first
5. If the resource has a static IP, decide whether the IP needs to be preserved for DNS or firewall rules
6. Delete the resource and note its name, type, and estimated monthly cost
7. Set a reminder to delete the safety-net snapshot after 30 days if no one has asked for the data

Unattached persistent disks

A persistent disk is the virtual hard drive attached to a VM. When you delete a VM without specifying —delete-disks=all, the disk stays behind and continues to bill at the full per-GB rate for its disk type. Unattached disks are one of the most common and most costly forms of cloud waste because they are easy to create accidentally and invisible unless you look for them.

For a deeper understanding of disk types and their pricing tiers, see Storage Cost Optimisation.

List all unattached persistent disks across your project:

gcloud compute disks list \
  --filter="users.len()=0" \
  --format="table(name,zone,sizeGb,type,lastDetachTimestamp)"

Sort by detach time to find the oldest (most likely to be forgotten):

gcloud compute disks list \
  --filter="users.len()=0" \
  --sort-by=lastDetachTimestamp \
  --format="table(name,zone,sizeGb,type,lastDetachTimestamp)"

Create a snapshot before deleting:

gcloud compute snapshots create backup-DISK_NAME \
  --source-disk=DISK_NAME \
  --source-disk-zone=ZONE

Delete the unattached disk after confirming the snapshot exists:

gcloud compute disks delete DISK_NAME --zone=ZONE

Reserved static IP addresses

A static external IP address is a fixed public IP you can assign to a VM or load balancer. When you delete the VM or load balancer without releasing the IP, it stays reserved in your project and bills at an hourly rate. Individual IPs are relatively cheap, but teams that provision infrastructure frequently can accumulate dozens of orphaned IPs.

For more on how GCP networking costs work, see GCP Pricing Models.

Find all static IPs in RESERVED state (not attached to anything):

gcloud compute addresses list \
  --filter="status=RESERVED" \
  --format="table(name,region,status,address,creationTimestamp)"

Find global reserved IPs that are not in use:

gcloud compute addresses list \
  --global \
  --filter="status=RESERVED"

Release an unused regional static IP:

gcloud compute addresses delete IP_NAME --region=REGION

Release an unused global static IP:

gcloud compute addresses delete IP_NAME --global

Stopped VMs and idle running VMs

A stopped (TERMINATED) VM does not bill for compute, but its attached persistent disks, any reserved static IP addresses, and certain licences continue to charge. A VM that has been stopped for months is almost certainly forgotten. An idle running VM (one with consistently low CPU and network usage) is even more wasteful because it bills for compute on top of everything else.

If a running VM is genuinely needed but over-provisioned, consider rightsizing it instead of deleting it. For VMs that only need to run at specific times, see Compute Engine Cost Optimisation for scheduling patterns.

Find all stopped VMs:

gcloud compute instances list \
  --filter="status=TERMINATED" \
  --format="table(name,zone,status,lastStartTimestamp)"

Use Active Assist to find idle running VMs with low utilisation:

gcloud recommender recommendations list \
  --project=PROJECT_ID \
  --location=ZONE \
  --recommender=google.compute.instance.IdleResourceRecommender \
  --format="table(description,primaryImpact.costProjection.cost.units)"

Delete a stopped VM and all its attached disks (after snapshotting):

gcloud compute instances delete INSTANCE_NAME \
  --zone=ZONE \
  --delete-disks=all

Old disk snapshots

Disk snapshots are point-in-time copies of a persistent disk. They are cheaper than the original disk, but they are not free. Snapshots created as backups or safety nets during previous cleanup rounds can accumulate indefinitely if no one sets a retention policy. Over time, the aggregate cost of hundreds of old snapshots becomes significant.

For details on how snapshot storage and incremental snapshots work, see Snapshots Explained.

List all snapshots sorted by age (oldest first):

gcloud compute snapshots list \
  --sort-by=creationTimestamp \
  --format="table(name,diskSizeGb,creationTimestamp,storageBytes)"

Find snapshots older than a specific date (adjust the date to your retention window):

gcloud compute snapshots list \
  --filter="creationTimestamp < '2026-01-01'" \
  --format="table(name,diskSizeGb,creationTimestamp)"

Delete a specific old snapshot after confirming it is no longer needed:

gcloud compute snapshots delete SNAPSHOT_NAME

Unused Cloud SQL instances

A Cloud SQL instance in RUNNABLE state bills continuously for its provisioned vCPUs, memory, and storage, even if nothing is connecting to it. Dev and test databases are the most common culprits because they are created for a specific task and forgotten when that task ends.

List all Cloud SQL instances and their current state:

gcloud sql instances list \
  --format="table(name,state,databaseVersion,settings.tier,settings.activationPolicy)"

Check recent connection activity using Logs Explorer via the CLI:

gcloud logging read \
  'resource.type="cloudsql_database"
   AND resource.labels.database_id="PROJECT_ID:INSTANCE_NAME"' \
  --limit=10 \
  --order=desc

Delete an unused Cloud SQL instance after exporting data:

gcloud sql instances delete INSTANCE_NAME

Orphaned load balancer components

A GCP load balancer is made up of several components: forwarding rules, target proxies, URL maps, and backend services. When a service is decommissioned, these components are sometimes deleted out of order or only partially removed. The remaining forwarding rules continue to bill even when they point to backend services with no backends.

List all forwarding rules to find potential orphans:

gcloud compute forwarding-rules list \
  --format="table(name,region,IPAddress,target,portRange)"

List global forwarding rules (used by HTTPS load balancers):

gcloud compute forwarding-rules list \
  --global \
  --format="table(name,IPAddress,target)"

Check whether a backend service has any backends attached:

gcloud compute backend-services describe BACKEND_SERVICE_NAME \
  --global \
  --format="value(backends)"

If the output is empty, no backends are attached. The backend service is orphaned and can be safely deleted along with its forwarding rule.

Automating cleanup safely

Manual cleanup works for small teams, but as your environment grows, automating the detection and notification process saves significant time. The key principle is: automate detection and notification, but keep deletion as a deliberate human action until you have high confidence in your automation.

A common pattern uses Cloud Scheduler to trigger a Cloud Run function on a weekly or monthly schedule. The function runs the same gcloud list commands shown on this page, filters for candidates, and sends a summary to your team’s Slack channel or email list. No resources are deleted automatically.

If you want to progress to automated deletion, use an opt-in label approach:

• Only resources with a label like auto-cleanup=true are eligible for automated deletion
• Resources without the label are flagged for manual review but never auto-deleted
• The automation logs every action and sends a summary notification after each run
• Include a dry-run mode so you can verify what would be deleted before enabling real deletion

If you manage your infrastructure with Terraform, cleanup can be as simple as removing the resource from your configuration and running terraform apply. Terraform handles the deletion order and dependency resolution for you.