What a cloud zombie is

A cloud zombie is a resource that still exists, still costs money and still looks alive, but that nobody uses. It was created for a test, a migration or a project that ended, and then nobody dared to delete it. A zombie is not the same as an expensive resource. A big database that serves customers is fine. A small one that nobody has connected to for four months is a zombie.

Zombies matter for three reasons: they cost money every month, they widen the attack surface (an unused service account is still a credential), and they make every review slower, because people have to wonder what each one is.

Nine zombies to look for

1. Unattached disks. Persistent disks with no VM using them. They are billed for their full size. A first look:

gcloud compute disks list --filter="-users:*" --format="table(name,zone.basename(),sizeGb,creationTimestamp)"

2. Old snapshots. Snapshots whose source disk no longer exists, or that are much older than your restore needs. Sort by age and check the source disk:

gcloud compute snapshots list --format="table(name,creationTimestamp,sourceDisk.basename(),storageBytes)"

3. Idle VMs. Machines with very low CPU and network use for weeks, and no logins. Google's idle VM recommender lists candidates for a project and zone:

gcloud recommender recommendations list --recommender=google.compute.instance.IdleResourceRecommender --project=PROJECT_ID --location=ZONE

4. Unused static IP addresses. A reserved external address that is not attached to anything is billed. They are easy to find and safe to review:

gcloud compute addresses list --filter="status=RESERVED"

5. Idle Cloud SQL instances. Databases with no connections and almost no queries for weeks. The connection count in Cloud Monitoring shows it, and so does the Cloud SQL idle recommender (google.cloudsql.instance.IdleRecommender).

6. Idle GKE clusters and node pools. A cluster with a handful of pods, nodes using a small share of their requested CPU, and no deployment for months. It is often the most expensive zombie, so it is worth checking first.

7. Dormant service accounts. Accounts that have not authenticated for a long time. They cost nothing, but each is a key that could be stolen. The service account insights in Google's policy tools show the last authentication.

8. Empty or abandoned projects. Projects with no billable usage, no active resources and no human activity. They hide in folders, and they keep permissions open.

9. Idle load balancers and NAT gateways. Forwarding rules and gateways that process no traffic. They bill by the hour, whether or not anything passes through.

Commands and recommenders change over time, so check Google's documentation for your setup before you rely on them.

Evidence before action

A resource looks idle in many ways, and not every one is a zombie. A quarterly report job runs four times a year. A disaster recovery database has no traffic by design. Before you call something a zombie, collect three things:

  • Evidence of no use over a long enough window, such as 30 to 90 days, long enough to cover your slowest cycle.
  • Dependents. What reads from it, writes to it, or runs on it? A disk with no VM might still be restored by a script.
  • An owner who agrees. A person or a team that confirms it is no longer needed.

Our guide to deleting cloud resources without breaking production covers what to do once you have the evidence.

Start with one hour of work

You do not need a project to start. Run the disk, snapshot and static IP commands above in each project. Sort the results by cost or age and write the top ten into a list with an owner column. That one hour often finds the first savings, and it shows you how much sits behind the ones you cannot see yet.

To skip the commands, reCloud runs a read-only scan of your Google Cloud projects and finds these nine zombies for you, with what each one costs and how safe it is to delete.

To estimate the size of the problem before you dig in, try our free 3C - Cloud Cost Calculator, or tick through the FinOps cloud waste checklist. When you want a number you can rely on across all your projects, our FinOps consulting for cloud cost optimisation audits your accounts and sets up the routine with you.