Finding the owner of forgotten cloud resources

Every cloud account collects stopped VMs, unattached disks, idle NAT gateways and snapshots of volumes that no longer exist. Cost tools say they are expensive. They don't say who owns them, what that person answered, or whether a backup exists. And owners rarely say "delete it": they say "we might need it later".

Three questions per resource

• Is it unused? A zombie score from CloudWatch metrics and resource state.
• Who owns it? Tags, people named in Name tags and the CloudTrail creator, combined into a confidence score.
• What should happen? keep, ask-owner, or propose-cleanup.

It cannot change your infrastructure

Every AWS call goes through a guard that only allows Describe, Get, List and Lookup operations; anything else raises before it is sent. There is no delete, stop or tag code in the repository, and a test fails if one is added. propose-cleanup is only a label in a report, and resources tagged production or managed by Kubernetes are capped at ask-owner.

Ownership is evidence, not a guess

Signals are combined as independent evidence, confidence = 1 − ∏(1 − weight): an owner tag counts 0.80, a team or project tag 0.50, a human CloudTrail creator 0.50, a Name tag that mentions a known user 0.45, an automation creator 0.15. If two different people both reach 40%, the finding is flagged as a conflict, because the creator is not always the owner.

Recording what owners say

ownerlens decide i-0123abc --by alice --reason "training box, needed again in Q1" --review-days 90
ownerlens verify-backup --pending

Kept resources stop being nagged about and come back when the review date passes. "Back it up, then delete" is recorded as a condition, and verify-backup checks, read-only, that every volume has a completed snapshot. The tool never deletes or snapshots anything: a person does, after the owner confirms in writing.

Reports people can act on

A scan writes a management summary, a findings CSV/JSON, a triage list of unowned resources, one draft message per owner, and a runbook for agreed deletions. Messages to owners on Slack or email are a dry run unless you pass --send and type to confirm.

GCP and Azure support is experimental and tested against recorded CLI output only. The README lists every known limit.