Unused infrastructure is rarely obvious from a billing invoice alone. A persistent disk may be detached but intentionally retained for recovery, an address may support a future cutover, and a quiet google cloud platform project may still contain an important integration. The practical answer is not an aggressive deletion script. It is a read-only workflow that turns resource signals into reviewable evidence before anyone changes production.
This workflow combines inventory snapshots, automated recommendations, ownership metadata, billing context, and a human approval queue. It gives platform teams a repeatable way to identify candidates while keeping deletion as a separate, accountable decision.
Why unused resources need an evidence trail
Resource cleanup is a reliability and business decision, not merely a command-line task. A resource can appear inactive because it is a standby dependency, a migration remnant awaiting sign-off, or an asset whose workload is seasonal. Google Cloud’s cost-optimization guidance emphasizes continuous visibility and collaborative cost management, making a reviewable process more appropriate than blanket remediation. Google Cloud Architecture Framework: Cost optimization
A useful operating principle is simple: discovery can be automated, while destruction requires evidence and approval. This lets a platform team move quickly on visibility while preserving application-team authority over services they understand best.
For teams adopting controlled access patterns, the same mindset behind read-only Looker access through MCP applies here. Give people enough information to investigate and decide without granting a reporting workflow the ability to alter live infrastructure.
A read-only workflow for google cloud platform cleanup
The workflow has five stages: inventory, signal enrichment, ownership assignment, review, and approved remediation. Each stage produces an artifact that can be inspected later. That matters when a resource owner asks why an item was flagged or finance needs to understand whether an apparent saving was realized.
1. Build a point-in-time inventory
Start with Cloud Asset Inventory rather than a collection of service-specific scripts. It can export asset metadata across an organization, folders, and projects to BigQuery, creating a queryable snapshot of resource metadata. The export can include resource names, types, ancestry, labels, and tags, which provide the basis for an inventory record. Export asset metadata to BigQuery | Cloud Asset Inventory
Keep this first pass read-only. Schedule snapshots at a cadence that fits the environment, retain enough history to compare changes, and record the snapshot timestamp. A current-state export tells you what exists; a series of snapshots can reveal whether an asset remains detached, unowned, or unchanged over time.
At minimum, create an inventory table with the resource identifier, asset type, project, folder or organization ancestry, region or zone where available, labels and tags, discovery timestamp, and lifecycle status. Do not infer that a missing label means an asset is safe to delete. Treat it as an ownership-data gap.
2. Add recommendation and utilization signals
Inventory identifies candidates; it does not prove waste. Add signals from Active Assist and Recommender. Google documents exporting recommendations to BigQuery through BigQuery Data Transfer Service, including recommendations for idle VM instances, unattached persistent disks, idle IP addresses, and unattended projects. The exported data can also include cost impact and observation information for analysis. Export recommendations to BigQuery | Recommender
Keep the original recommendation payload or a stable reference to it. The resource, recommendation subtype, observation period, estimated impact, and export date should remain attached to each queue item. This avoids presenting a team with a vague claim that something is unused without a way to assess why.
For example, a detached disk can be a strong candidate when it has no known recovery requirement, no owner response, and a sustained recommendation signal. A low-traffic service is less conclusive. A google cloud run service may be intentionally scaled down between event-driven workloads, so its lifecycle, deployment history, and business owner need review before cleanup.
3. Resolve ownership before assigning blame
Cost allocation is the bridge between technical inventory and a decision that someone can responsibly make. The FinOps Foundation describes cost allocation as assigning cloud costs to accountable stakeholders through mechanisms such as accounts, tags, labels, and hierarchical groupings. FinOps Framework: Cost Allocation
Use a clear precedence model for ownership. First, accept an explicit resource owner label or tag. Next, derive responsibility from a project-level owner or cost-center label. Then use folder-level defaults. Finally, send unresolved records to a platform-owned exception queue. An unlabelled asset becomes a data-quality task, not an invitation to delete it.
Define a small required label contract for new workloads: application, team, environment, cost center, and lifecycle or expiry where appropriate. The values do not need to be perfect on day one. Consistent ownership metadata is more valuable than a sprawling taxonomy nobody maintains.
Use a confidence model instead of a delete list
Classify findings by the strength of their evidence and the impact of being wrong. This creates a shared language between platform engineering, FinOps, security, and application teams. A recommendation is a valuable input, but it should not automatically become an action.
| Confidence level | Typical evidence | Required next step |
|---|---|---|
| Low | Missing owner, no clear utilization history, or ambiguous lifecycle | Improve metadata and ask the project owner to classify it |
| Medium | Inventory shows a detached or idle asset and a recommendation supports review | Create an approval item with owner, rationale, and proposed action |
| High | Persistent unused signal, identified owner, documented retention review, and no dependency objection | Schedule approved remediation with an auditable change record |
Estimated savings should remain decision support, not a promise. Associate each candidate with its billing account or attribution path, cost center, and recent cost data where the billing export and data model support that connection. Show the source and period for every estimate, then use billing data to validate the outcome after remediation.
Join technical evidence to billing context
BigQuery is a practical meeting point for inventory and recommendation exports, but a useful cleanup record also needs financial context. Present cost with the resource’s ownership and recommendation evidence so the reviewer can evaluate operational risk alongside potential savings.
The FinOps Framework’s usage-optimization capability emphasizes ongoing identification and optimization of cloud usage in collaboration with stakeholders. That supports a recurring process rather than an annual resource purge. FinOps Framework: Usage Optimization
A good queue item answers five questions in one view: what is the resource, why was it flagged, who owns the decision, what cost or utilization context is available, and what action is proposed? Add links to the source asset record, the recommendation record where applicable, and related change or retirement tickets.
For an unattended google cloud project, expand the evidence beyond an inactive-service signal. Review project IAM, billing linkage, recent audit activity, network dependencies, organization policy implications, and known migration work. Project deletion can affect multiple google cloud services, so it should be treated as a deliberately approved lifecycle event rather than a cleanup shortcut.
Design the approval queue around real decisions
The approval queue should be intentionally boring: predictable fields, a clear owner, an expiry date for the request, and recorded outcomes. Route candidates to the team that owns the application or project, not simply to the person who holds broad administrative access.
Possible outcomes are retain, investigate, schedule removal, remove after a defined date, or mark as incorrectly detected. The last option is important because it improves rule quality without forcing teams to use informal side channels to dispute a finding.
Spotify’s engineering team has described building cost-engineering tooling that gives teams visibility and context around cloud spending. Its example reinforces a useful organizational lesson: cost responsibility works better when engineers can understand and act on their own context. Managing Clouds from the Ground Up: Cost Engineering at Spotify
When an approved item reaches remediation, use existing change-management controls. State the exact resource, approved action, executor, timing window, recovery consideration where relevant, and verification to perform afterward. Cleanup automation may execute the change later, but it should consume an explicit approval record rather than independently decide that a resource is expendable.
Where policy-as-code fits safely
Policy-as-code is useful for consistent discovery and notifications. Cloud Custodian supports Google Cloud policies and documents dry-run or inform-oriented approaches, allowing teams to evaluate policies and send findings without immediately remediating resources. Cloud Custodian documentation for Google Cloud
Begin with policies that emit findings only. Run them with the narrowest permissions needed to inspect the resource types in scope, publish results to the queue, and compare them with inventory and Recommender data. Tune exclusions for managed resources, approved retention, temporary environments, and migration windows before considering any action mode.
This is especially useful for technical founders who need stewardship without a large FinOps function. It also pairs well with a cloud image validation checklist: both practices convert risky operational assumptions into evidence, review, and repeatable controls.
Implementation checklist for the first 30 days
- Choose a pilot scope, such as one folder, business unit, or non-production estate.
- Export a Cloud Asset Inventory snapshot to BigQuery and document the fields your team will retain.
- Export relevant Recommender insights to BigQuery and preserve their recommendation context.
- Define ownership precedence and a minimum resource-label contract.
- Create a review queue with evidence links, owner, confidence level, proposed action, and expiry date.
- Review findings with application owners before setting any removal date.
- Record retained and false-positive outcomes to improve future rules.
- Only after a stable review cycle, consider automation that executes already approved actions.
This approach is also a practical answer to what is google cloud platform from an operating-model perspective. Beyond a collection of managed products, it is an environment whose services, projects, identities, costs, and ownership signals need to be managed together. Whether your team is learning through google cloud skills boost, planning for google cloud next, or running mature workloads, that shared view makes cost control safer.
For organizations that need help aligning cloud governance with delivery priorities, Mohamed Chami’s professional tech services in Morocco page provides broader service context.
Sources
- Export asset metadata to BigQuery | Cloud Asset Inventory
- Export recommendations to BigQuery | Recommender
- Google Cloud Architecture Framework: Cost optimization
- FinOps Framework: Cost Allocation
- FinOps Framework: Usage Optimization
- Cloud Custodian documentation for Google Cloud
- Managing Clouds from the Ground Up: Cost Engineering at Spotify
FAQ
How do I find unused Google Cloud resources without deleting anything?
Export resource metadata with Cloud Asset Inventory, add Recommender findings, and send candidates to an approval queue. Keep discovery identities and policies read-only until a specific cleanup action has documented approval.
Can Recommender prove that a resource is safe to remove?
No. Recommender provides useful optimization signals and context, but service dependencies, recovery requirements, and business timing still require an owner review before removal.
Which resources should a cleanup pilot examine first?
Start with resource types that have clear signals, such as idle VM recommendations, unattached persistent disks, idle IP addresses, and unattended projects. Keep the pilot limited enough that owners can review every finding.
What labels help assign ownership for cloud cleanup?
Useful labels commonly identify the application, responsible team, environment, cost center, and lifecycle or expiry date. Define precedence between resource, project, and folder metadata so unresolved ownership is visible.
When should cleanup automation be allowed to make changes?
Allow it only after the discovery rules, exclusions, ownership mapping, approval process, and recovery expectations have been validated. The automation should execute a recorded approval, not replace the approval decision.
Editorial note: AI assisted with research and drafting. Sources were selected for verification.
Full-Stack Developer & Solutions Architect · Casablanca, Morocco
8+ years building Java/Spring Boot/Angular enterprise solutions. Former Senior Software Engineer at NTT Data and Satec. Authorized Google Workspace and Microsoft 365 Partner for Morocco.