GCP Orphaned Resources: How to Find and Safely Clean Up Cloud Waste

Google Cloud Platform teams routinely discover 15–25% of their monthly bill comes from resources nobody uses. The waste is easy to miss because orphaned resources keep billing after the workload they supported is gone. Unattached disks, forgotten snapshots, unused IPs, stale images, and abandoned storage can accumulate across projects long after teams think an environment has been torn down.

This guide covers the 13 most common orphaned resource types and their typical costs, explains how to find them using GCP's native tools and billing exports, provides a decision framework for safe deletion, and outlines preventive architecture patterns that stop orphans from accumulating in the first place.

What Are Orphaned Resources in GCP?

An orphaned resource in Google Cloud is a billable resource that has been detached from its parent workload but continues to generate charges. Unlike idle resources — which are attached and running but unused — orphaned resources serve no function and can often be deleted immediately.

Orphaned resources — detached from any active workload but still accruing charges — represent one of the highest-ROI cleanup opportunities in cloud cost optimization, yet most FinOps teams lack a systematic approach to detect and remediate them.

How Orphaned Resources Accumulate

Orphaned resources appear in common scenarios such as:

Deleted VMs leaving persistent disks behind. Persistent disks configured to be preserved can remain after a Compute Engine VM is deleted and continue accruing charges.

Torn-down environments with incomplete cleanup. A staging environment gets decommissioned, but the IaC script misses three Cloud SQL read replicas, two load balancers, and a dozen static IPs.

Abandoned experiments and proof-of-concept projects. An engineering team tests a new ML pipeline, provisions GPU-attached persistent disks, generates 500 GB of training data snapshots, and moves on to production.

Failed IaC applies leaving partial state. A Terraform apply fails midway through creating a regional managed instance group. The instance template, health check, and backend service get created; the autoscaler configuration fails. Terraform marks the apply as failed, but GCP keeps billing for the partial deployment.

Why Orphaned Resources Are Invisible in Most Cost Reports

Billing dashboards aggregate spend by project or service. An "orphaned disk" line item reads identically to an "active disk" line item — both show as Compute Engine > Storage PD Standard. Without resource-level tagging and cross-referencing against active workloads, cost reports cannot distinguish between a 500 GB disk attached to a production database and a 500 GB disk left over from a deleted test VM.

GCP's Active Assist surfaces recommendations for certain idle and underutilized resources and can be scoped at the project, folder, or organization level.

The GCP Orphaned Resource Inventory

The table below summarizes the most common GCP resources that can become orphaned and what to do about them.

Unattached Persistent Disks

Persistent disks configured with autoDelete=false can remain after a Compute Engine VM is deleted, continuing to accrue storage charges until someone explicitly removes them. Boot disks have autoDelete enabled by default, while the behavior of other attached disks depends on the attachment's autoDelete setting. This can quietly work against teams during manual cleanup, bulk console deletions, and scripted teardowns that account for instances but never check disk state.

To find them, query billing exports for sku.description containing "Storage PD," then cross-reference against the Compute Engine API for disks where users is empty — an empty users field means nothing is attached to it anymore. The cost adds up fast: a single 500 GB Standard PD runs about $20/month at $0.04/GB, so 50 forgotten disks quietly burn $1,000/month.

Before deleting, check two things: whether the disk has any snapshots, and whether it's documented as a disaster recovery artifact. If it has neither, it's safe to remove. If it belonged to a stateful workload — a database, a file server — and no one ever took a snapshot, treat it as higher risk and dig into why before pulling the trigger.

Orphaned Disk Snapshots and Snapshot Chains

Snapshots can remain after their source disk is deleted, and manually created snapshots remain until someone explicitly deletes them. For snapshots created by a snapshot schedule, what happens after source-disk deletion depends on the schedule's source-disk deletion policy: existing snapshots may be retained indefinitely rather than continuing to age out under the normal retention policy.

Finding them:

• Billing exports list snapshot costs under Snapshot Storage
• Cross-reference each snapshot's source disk against currently active Compute Engine disks via the API
• Flag anything past your retention window — 90 days is typical for compliance, 365 days for long-term backup — as a candidate for review
• Standard snapshot storage in many US regions runs about $0.05/GiB/month, so a large snapshot footprint can add up quietly

Before you delete: GCP manages snapshot dependencies automatically. When you delete a snapshot that later snapshots depend on, the data required to restore those snapshots is moved forward rather than simply breaking the chain. Confirm the snapshots aren't tied to a disaster recovery plan or referenced in an IaC rollback strategy first.

Reserved Static IP Addresses Not in Use

A reserved static external IPv4 address that isn't being used still costs $0.01/hour — roughly $7.30/month at 730 hours — and it's an easy thing to lose track of. Teams reserve IPs ahead of a launch that gets delayed, or a DNS record gets repointed and nobody releases the old address. Twenty forgotten IPs across a project adds up to roughly $1,750/year, which is a small number until you multiply it by every project that's accumulated a few.

The Compute Engine API will show you addresses where status=RESERVED and users is empty — that's your candidate list. Just check DNS records and firewall rules before releasing anything, since a few will legitimately be sitting in a DR runbook or hardcoded into a partner's config.

Idle Load Balancers and Forwarding Rules

Cost-wise, HTTP(S) load balancers run $18–$22/month; network load balancers are cheaper but still accumulate across a large fleet. The math is simple, but the judgment call — is this genuinely dead, or is it a failover path that's supposed to sit idle — is where teams get it wrong.

Stopped VMs Still Holding Attached Storage

Stopping a VM saves on compute, but the attached persistent disks keep billing — and that's by design, not a bug. The problem is intent decay: someone stops an instance meaning to restart it "next month," and next month never comes. Months later, the disk is still billing for a VM nobody remembers the purpose of.

The fix isn't technical, it's organizational: filter the Compute Engine API for status=TERMINATED instances, total up their attached disk costs, and compare the list against whatever inventory of intentionally-stopped VMs your team keeps (if one exists). Anything on the list with a clear reason to restart, leave alone. Anything nobody can explain, snapshot it and delete the disk.

Unused Cloud SQL Instances and Read Replicas

Cloud SQL bills 24/7 regardless of whether anything is actually connecting to it. A $200/month PostgreSQL instance sitting at zero connections for 30 days is dead weight — and read replicas are a common variant of this problem, often spun up for a read-heavy workload that later migrated elsewhere and left the replica running.

Pull cloudsql.googleapis.com/database/network/connections from Cloud SQL monitoring over a 30-day window; zero active connections is your signal. This one deserves more caution than most: verify there's no scheduled ETL job hitting it quietly, no backup-only access pattern, and no disaster recovery dependency. When in doubt, export the data before you touch anything.

Stale GKE Node Pools and Released Persistent Volumes

Two different problems get lumped together here, so it's worth separating them:

• Empty node pools (minNodeCount=0, currentNodeCount=0) cost nothing to keep around — they're pure configuration clutter, not a billing issue. Low-stakes cleanup.
• Released PersistentVolumes (reclaim policy = Retain) are the real cost problem: once the pod using them is deleted, the underlying disk keeps billing indefinitely unless someone explicitly removes it.

Find empty pools via the GKE API (zero nodes, no scheduled workloads) and released PVs via the Kubernetes API (status=Released), then cross-reference the latter against GCP disk billing to size the impact. If you want cost allocation that goes deeper — attributing GKE cluster spend down to the pod and namespace level — that generally means using Kubernetes resource requests and usage data together with GKE billing and resource-label data. VPC Flow Logs can supplement this for network-cost attribution.

Abandoned Cloud Run Revisions and Container Images

Cloud Run revisions receiving no requests generally consume no resources and aren't billed, although revisions configured with minimum instances can continue generating charges even without incoming traffic. The more common persistent storage cost sits in Artifact Registry, where every container image from every CI/CD push can accumulate at $0.10/GB/month, and many pipelines push on every commit without ever cleaning up.

Two API calls get you there: Cloud Run for revisions with zero requests over 30 days, and Artifact Registry for images older than 90 days with no pulls. Revisions with confirmed zero traffic are safe to remove outright. Images need a second look first — check that nothing in a rollback script or release note still points to them.

Old Custom Machine Images

• Build pipelines generate a new Compute Engine image on every release
• Without a lifecycle policy, they never get cleaned up — and standard image storage in many US regions costs about $0.05/GiB/month
• A 200 GiB image runs about $10/month; 50 accumulated images quietly cost around $500/month
• To find candidates: list images older than 90 days via the Compute Engine API, then cross-reference against active instance templates and MIGs
• Anything unreferenced anywhere is safe to remove; anything named in a documented rollback procedure needs a second look first

Buckets with Non-Current Object Versions and Incomplete Uploads

Two separate leaks hide in the same bucket. Object versioning keeps every prior version of a file every time it's overwritten, and without a lifecycle policy those old versions never age out. Separately, multipart uploads that were started but never finalized just sit there — indefinitely, by default.

The Cloud Storage API can query objects with noncurrentTime set (sum the size to see the damage). For XML API multipart uploads, use the multipart-upload listing operation to identify uploads that have been initiated but not completed or aborted. Incomplete uploads older than a week are almost never going to be resumed — safe to clear out. Non-current versions need a quick check against the bucket's retention policy and any compliance requirements before you delete historical data.

Unattached GPUs and Reserved Capacity

This is the one category where "just delete it" doesn't apply. GPU commitments and reservations bill on their own schedule, whether or not any workload is actually consuming them — a 1-year A100 commitment runs into the thousands per month regardless of utilization.

Commitment utilization reports will show you anything running under 50% utilization, and the Reservation API surfaces reserved GPUs with no attached instances. The catch: committed spend can't be canceled early without a penalty, so there's often nothing to do there except confirm the workload really has ended. Reservations (as opposed to commitments) can be released — but only once you're confident the workload isn't coming back. Teams managing this across multiple clouds typically want reserved-instance tooling that tracks utilization continuously and flags underused capacity before it becomes a sunk cost, rather than catching it after months of waste.

How to Find Orphaned Resources: Strategic Approaches

GCP provides multiple detection paths depending on whether you prioritize cost quantification, automation, or cross-project coverage.

Billing Exports for Cost-First Detection

BigQuery billing exports contain every GCP charge with SKU, project, resource labels, and cost attached — which makes them the single source of truth for what GCP actually charges, rather than just what resources technically exist. That distinction matters: billing exports let you start from "which resources cost the most" instead of wading through an inventory of everything running.

In practice, that means exporting billing data to BigQuery, filtering SKUs down to storage and networking (the two categories where orphaned resources cluster), and joining against the relevant resource APIs to surface anything with zero usage but non-zero cost.

Active Assist Recommendations for Low-Hanging Fruit

Google's Active Assist Recommender already does a version of this detection work for you — it surfaces recommendations for unattached disks, idle VMs, and underutilized commitments directly in the console.

• Access it: enable Recommender API access, then pull recommendations with gcloud recommender recommendations list
• Prioritize by: savings impact, since each recommendation ships with a cost estimate attached
• Trust level: recommendations are generated from resource usage and configuration data using heuristics or machine learning, but they should still be reviewed before action
• The catch: Active Assist can be scoped to an organization, folder, or project, but coverage varies by recommender and large organizations may still prefer API- or BigQuery-based aggregation for analysis and automation

Asset Inventory for Cross-Project Resource Discovery

Recurring Audits with Automated Reporting

A one-time audit catches waste once. It doesn't stop teams from spinning up the same kind of orphaned resource next quarter — that requires something ongoing, not a single cleanup pass.

The setup is straightforward: a Cloud Function running weekly, querying billing exports, Asset Inventory, and the Recommender API in the same pass, aggregating the results, and posting a summary to Slack or email. Tag resources as you clean them up so they're excluded from future runs — otherwise you'll keep re-flagging things your team already reviewed and decided to keep. Done this way, detection stops being a project and becomes infrastructure.

Deleting Safely: The Part Most Guides Skip

Deleting orphaned resources requires balancing speed (high-cost orphans should go quickly) against risk (disaster recovery dependencies, compliance holds, undocumented rollback plans).

Snapshot Before You Delete

For stateful resources such as persistent disks and database instances, create a snapshot or export before deletion when the recovery value justifies the additional storage cost. Snapshot storage is often cheaper than retaining the original resource.

A good practice is to snapshot disks and export databases before deletion if the resource is >90 days old or >100 GB. For newer or smaller resources, document the deletion in a shared log and proceed.

Checking for Dependencies and DR Implications

Orphaned resources sometimes have hidden dependencies: a disk detached from a VM but referenced in a disaster recovery runbook, a static IP not attached to a load balancer but hardcoded in a partner integration, a snapshot chain where deleting the parent consolidates children.

Checklist:

• Is this resource documented in any DR plans, runbooks, or architecture diagrams?
• Does this resource have dependent resources (snapshot chains, DNS records pointing to an IP, IaC templates referencing an image)?
• Was this resource tagged with an owner or purpose label? Contact the owner before deletion.

Which Resources Are Safe to Auto-Delete vs. Warning Period

In general, auto-delete resources with zero external dependencies, low data-loss risk, and easy recreation. These can be flagged for automatic deletion after a grace period.

Manually approve resources with potential disaster recovery implications, data compliance requirements, or unclear ownership. These require a ticket, owner sign-off, or team review before deletion.

Staging Cleanup Across Dev, Staging, and Production

Orphaned resources appear in all environments, but deletion risk varies:

Dev/sandbox environments: High tolerance for aggressive cleanup. Delete unattached resources >30 days old without approval.

Staging: Medium tolerance. Require team notification 7 days before deletion.

Production: Low tolerance. Require explicit approval from resource owner or engineering lead.

Getting Owner Sign-Off Without Stalling the Project

Cleanup initiatives stall when ownership is unclear. The fix is to flip the default from opt-in to opt-out.

Tag every candidate with deletion-candidate=YYYY-MM-DD, then post one Slack summary instead of dozens of individual asks: "We identified 45 orphaned disks costing $2,200/month. Deletion scheduled for [date]. Reply in thread to claim ownership or object." Give it a 7-day window and make silence the approval — most of these resources genuinely belong to no one, and treating each one as guilty-until-claimed is what gets cleanup projects unstuck.

That said, silence-as-approval only works for the low-stakes majority. Anything touching production, or costing more than $100/month, should require an actual sign-off — a Google Form or a Jira ticket, something with a name attached. Non-response there just delays that specific resource; it doesn't hold up the rest of the batch.

What Google's Native Tools Do and Do Not Catch

GCP provides three native tools for orphaned resource detection: Active Assist Recommender, Cloud Asset Inventory, and billing export analysis. Understanding their gaps helps teams decide whether to build in-house tooling or adopt third-party platforms.

Active Assist and Recommender

What it does well:

• Surfaces high-confidence recommendations for unattached disks, idle VMs, overprovisioned instance types
• Includes cost estimates and recommendation priority
• Available via console, API, and Terraform
• No setup required beyond enabling the Recommender API

What it misses:

• Coverage is recommender-specific — there isn't an orphan-cleanup recommender for every GCP service or resource type
• No dedicated cleanup recommendations for patterns such as stale Artifact Registry images, incomplete multipart uploads, or accumulated non-current object versions
• Detection isn't real-time: for example, Compute Engine idle disk, IP, and custom-image recommendations begin after 15 days and refresh about once every 24 hours
• Recommendations evaluate supported resource patterns individually; teams still need their own policies and workflows for ownership, approvals, exceptions, and remediation

The Gaps: Coverage, Continuous Enforcement, Manual Actioning

Organization-wide visibility is available in Active Assist, although very large organizations may still use BigQuery exports or the API for more scalable analysis and automation. Coverage also varies by recommender, so not every orphaned-resource pattern is surfaced natively. Other missing capabilities include:

• Coverage: Active Assist only detects conditions covered by a supported recommender, leaving teams to build their own detection for orphan patterns outside that catalog
• Detection latency: Recommendations are generated on defined observation windows and refresh cycles rather than immediately when a resource becomes orphaned
• Continuous enforcement: A recommendation identifies an optimization opportunity, but it doesn't by itself enforce an organization's cleanup policy every time that condition occurs
• Workflow and remediation: Some recommendations can be applied directly, but broader approval flows, owner notification, exception handling, and automated cleanup still require additional tooling or custom automation

Third-party platforms fill these gaps by continuously monitoring all projects, prioritizing findings by cost impact, and providing one-click or automated remediation workflows. For teams managing multiple clouds, multi-cloud cost optimization platforms extend orphaned resource detection across AWS, Azure, and GCP from a single interface.

Preventing Orphans in the First Place

Detecting and cleaning up orphaned resources is reactive. Preventing them from accumulating requires changing team behavior, adding automation to IaC pipelines, and designing architecture patterns that default to cleanup.

Tagging and Labelling Standards That Survive Teardown

Resource labels provide metadata that cleanup automation can use to identify ownership, environment, and intended lifetime.

A best practice is to use GCP Organization Policy to require labels on new resources. Block resource creation if required labels are missing.

Recommended labels for supported GCP resources:

• owner: Email or Slack handle of the team responsible for the resource
• environment: dev, staging, production
• created-by: CI/CD pipeline name or user ID
• expires-after: ISO date (e.g., 2026-10-15) for non-production resources
• project-id: Application or service name (distinct from GCP project for multi-project apps)

TTLs and Auto-Expiry on Non-Production Environments

Dev and staging environments rack up orphaned resources fast because people experiment and don't clean up — so build expiry in rather than relying on memory. Label every dev resource with expires-after at creation (30 days for dev, 90 for staging), and run a daily Cloud Function that checks Asset Inventory for anything past its date and deletes it or queues it for review. The resource disappears by default unless someone actively extends it, instead of sitting there until someone remembers.

IaC Lifecycle Rules and Cleanup in CI/CD

Infrastructure-as-code tools (Terraform, Pulumi, Deployment Manager) track resource state. When a resource is removed from IaC configuration, the tool can delete it automatically — but only if teams remember to run terraform destroy or remove the resource block from configuration.

You can add post-teardown hooks to CI/CD pipelines that verify all resources provisioned during a build or test run are cleaned up.

Example CI/CD cleanup hook:

1. Pipeline provisions a test GKE cluster + attached disks + Cloud SQL instance

2. Tests run

3. Pipeline executes terraform destroy targeting the test project

4. Post-destroy script queries Asset Inventory for any resources in the test project created in the last hour but not deleted

5. If orphans exist, script logs them and either auto-deletes (for low-risk resources) or alerts the team

Cleanup becomes part of the automated workflow rather than a manual step easily forgotten.

Ownership and Regular Waste Reviews

Even with automation, orphaned resources slip through. Regular waste reviews — monthly or quarterly — catch the gaps. A sample process might look like:

1. Engineering manager pulls a "top 50 orphaned resources by cost" report from billing exports + Asset Inventory

2. Team reviews the list in a 30-minute standup, identifies legitimate vs. orphaned, assigns deletion owners

3. Orphans are deleted within 7 days; legitimate resources are re-labeled to exclude from future reports

This works by adding visibility + accountability. Teams don't clean up waste they can't see or don't own. For automated anomaly alerts when orphaned resource costs spike unexpectedly, cloud cost anomaly detection systems analyze historical spend patterns and flag deviations before they compound.

Reducing GCP Costs with nOps

Cleaning up orphaned resources removes waste that no longer supports a workload, but it’s only one layer of GCP cost optimization. nOps helps teams continuously surface cost-saving opportunities while keeping visibility, allocation, and commitment strategy connected across their cloud environment.

• Unified visibility: Get all of your spending from GCP, AWS, Azure, AI, and SaaS in one place, with cost allocation by application, customer, team, or business unit to understand what is driving spend and where optimization will have the greatest impact.
• Commitment Management: Automatically maximize discounts and minimize commitment risk across eligible cloud infrastructure supporting your GCP workloads. Customers typically save ~20% by switching to nOps — and with results-based pricing, you pay only when you get better results.

We’ve talked to companies that can save millions on their cloud bills by switching to nOps from competitors. Book a free savings analysis to quantify exactly how much more you could save across the infrastructure supporting GCP and the rest of your cloud environment.

nOps manages $5B+ in cloud spend and was recently rated #1 in G2’s Cloud Cost Management category.

Demo

AI-Powered Cost Management Platform

Discover how much you can save in just 10 minutes!

Book a Demo

FAQ