Why an owner comes first

You cannot decide whether a resource is still needed without someone who can say so. That is why ownership comes before cost, and before any clean-up. A disk that costs little but has no owner is a bigger problem than a large database that a named team stands behind, because nobody can ever approve its removal.

If you have not mapped what you run yet, start with how to map your cloud. This post covers the next step: a name next to every line.

Six signals that point to an owner

When the team label is empty, the evidence is usually still there. Work through these in order:

  1. Other labels. An env, app or cost-center label often leads to a team even when team is missing.
  2. Who created it. The audit logs record the account that created the resource and when. A person's name or a pipeline's service account is a strong lead.
  3. The service account it runs as. A VM that runs as billing-worker@... belongs near the billing code.
  4. Its name. Names such as orders-db-copy or sa-temp-john carry a product or a person, even if sloppily.
  5. What it connects to. The network, the subnet and the resources next to it show which application it sits in.
  6. What depends on it. A load balancer that points to a VM, or a disk attached to one, tells you the VM's owner is the disk's owner.

For one disk, the creator lookup can be as short as this:

gcloud logging read 'protoPayload.methodName="v1.compute.disks.insert" AND protoPayload.resourceName:"old-data-disk"' --limit=1 --format="value(protoPayload.authenticationInfo.principalEmail)"

Audit logs have a retention period, so an old resource may no longer show its creator. Treat a missing answer as information, not as an error.

Ask in the open

Private detective work is slow. A short public list is faster. Post the resources you could not match in the team channel, with the name, the type, the project, the monthly cost and the best guess so far, and ask for a reply by a date. People who ignore a long audit will answer "that is mine" to a single line with their team's name in it.

Keep the tone neutral. The goal is to put a name next to each line, not to find someone to blame.

When nobody answers

Some resources will stay unclaimed. Do not leave them in limbo, and do not delete them on the spot either. A routine that works:

  1. Label it owner=unknown and add a review date.
  2. Take a snapshot or a backup, so that a deletion can be undone.
  3. Quarantine it: stop the VM or remove its public access, and watch for complaints.
  4. If nobody objects by the review date, remove it.

The details of each step are in how to delete cloud resources without breaking production.

Keeping everything owned

The cheapest owner to find is the one recorded at creation time. Make the team label required in your infrastructure code, and report on label coverage every week: the share of resources that carry an owner, and a list of the ones that do not.

That is what the ownership view in reCloud is for. It lists the resources that have no owner label, shows the labels next to every resource, and lets you assign a name before anything is deleted. It is in early access for Google Cloud, and you can read how it works.