Unused Resource Cleanup Workflow
Identify resources with no traffic or reference, verify dormancy with stakeholders, and delete with recovery windows rather than accumulating forever.
Objective
Reclaim cost and attack surface by deleting provably unused resources, with dormancy evidence and a bounded recovery window.
Environment
- Cloud inventory with usage metrics available
- A tagging or ownership system for finding stakeholders
- A deletion policy with recovery (snapshots, soft-delete)
Steps
1. Correlate usage across signals
For each candidate resource, correlate multiple dormancy signals: no traffic, no API references, no log activity, and no recent config changes.
Expected state: A dormancy score exists per resource built from multiple signals.
2. Find the owner or declare orphan
Locate the resource's owner through tags or history; if none responds within the window, mark it orphaned with the evidence attached.
Expected state: Every candidate has an owner response or an orphan declaration with evidence.
3. Verify dormancy with the owner
Ask the owner about seasonal or periodic use cases the metrics window might miss, extending observation where justified.
Expected state: Owners confirm dormancy or the resource exits the cleanup queue.
4. Delete with a recovery window
Snapshot or export state where feasible, then delete, keeping the recovery artifacts for a bounded window with a documented restore path.
Expected state: Deletions carry recovery artifacts with expiry dates.
5. Gate creation to slow re-accumulation
Require owner tags and expiry metadata at resource creation, so the next cleanup starts from a labeled estate rather than another archaeology project.
Expected state: New resources carry owners and expiries from day one.
Expected outcome
A shrinking unused-resource backlog with evidence-based deletion, recovery windows honored, and new resources born labeled to prevent re-accumulation.
Verification
Cost attribution shows the reclaimed spend; no deletion was urgently needed again within its recovery window; new resources carry owner and expiry tags.
Unused is a claim you verify, then delete
Every environment accumulates resources whose purpose died quietly: the test cluster for a cancelled project, the bucket from a two-year-old migration. Multi-signal dormancy, owner verification, and recovery-windowed deletion turn cleanup from risk into routine.
dormancy score (signals, 90d):
traffic: 0 req api refs: 0 logs: 0
config changes: 0 cost: $211/mo
queue (scored):
eks-test-cluster-3 dormant owner: team-C
-> confirmed cancelled project DELETE
s3-migration-2024 dormant owner: NONE
-> orphan declared (2wk notice) DELETE
rds-reporting-rep low traffic (1 conn/d)
owner: finance "month-end use" KEEP
deletion w/ recovery:
snapshot -> delete -> artifact kept 30d
restore runbook attached to deletion ticket
creation gate: tag owner + expiry required
(next cleanup: labeled estate, no archaeology)One signal is never enough
Zero traffic can mean the resource is broken, not unused; zero API references can mean the caller uses a config-indirected name. Requiring several independent signals — traffic, references, logs, changes — makes the dormancy claim strong enough to act on.
The month-end database is why you ask
The resource with one connection a day looks dormant to a 90-day traffic chart but runs the financial close every month-end. Owner verification exists precisely for these patterns, and deleting one of them erases months of accumulated trust in the cleanup program.