Why nobody deletes anything

In most cloud accounts, the person who created a resource has moved on, the documentation is out of date and the name says nothing. Deleting it feels like a risk with no reward: if you are right, nobody notices, and if you are wrong, everybody does. So the resource stays, and the bill goes up a little each month.

The answer is not courage. It is a routine that makes a wrong delete recoverable, so that the risk is small enough to take.

Six steps before delete

1. Prove it is unused. Collect evidence over a window long enough to cover your slowest cycle, usually 30 to 90 days: no connections, no traffic, no logins, no reads. Write down what you checked and when.

2. Find the dependents. What uses it, or what would notice if it vanished? Check attachments, network rules, scheduled jobs, infrastructure code and other projects that reference it.

3. Ask the owner. If a label or a name points to a person or team, ask them. If nobody owns it, say so in the ticket, and let the team that pays for it decide.

4. Keep a way back. Before anything changes, take a snapshot or an export. For a disk:

gcloud compute disks snapshot DISK_NAME --zone=ZONE --snapshot-names=DISK_NAME-before-delete

5. Quarantine. Make it harder to use without destroying it: stop the VM, detach or restrict access, and label it with a removal date so everyone can see what will happen.

gcloud compute instances stop VM_NAME --zone=ZONE
gcloud compute disks add-labels DISK_NAME --zone=ZONE --labels=delete-after=2026-12-15

Then wait. Two to four weeks is typical. If something breaks, you will hear about it, and you can undo a stop in seconds.

6. Delete, and write it down. After the quarantine, delete the resource, remove it from your infrastructure code so it does not come back, and record the saving. Keep the snapshot for a retention period you chose in advance.

Score the blast radius

Not every deletion needs the same care. A reserved IP that is attached to nothing has almost no blast radius. A database with a dozen dependents has a large one. Give each candidate a simple score based on three questions:

  • How sure are we that it is unused? (the quality of the evidence)
  • What breaks if we are wrong? (how many dependents, how critical)
  • How easily can we get it back? (a snapshot, an export, an infrastructure definition)

Start with the safe ones. A few quick, uneventful wins build the trust you need for the harder ones.

After the delete

Closing the loop matters as much as the delete. Write down what you removed, what it cost per month and who approved it. Track the saving on the next bill, so you can show that the work paid off. And fix the cause: if zombies keep appearing from the same source, such as test environments with no expiry, add a rule that stops them, like an automatic removal date label.

If you want to look at where your own waste sits first, start with our list of six places your cloud bill leaks money and find the candidates in nine kinds of zombie resources. On Google Cloud, reCloud builds that candidate list for you and rates how safe each delete is. When you would rather have a second pair of eyes, our FinOps consulting for cloud waste reduction builds the routine with your team.