Somewhere in your cloud account right now, there are resources billing you every hour for doing absolutely nothing. They were created with a purpose, that purpose ended, but no one hit delete.
The term sounds dramatic, but the concept is straightforward. A zombie resource is any cloud asset that is still running, still billed, but no longer attached to any active workload or business purpose. It was alive once. Now it just costs money.
They are not always obvious. Unlike a VM sitting at 0% CPU, some zombie resources appear to be doing something. They might have low but non-zero utilization, a name that implies importance, or sit inside an account that no one checks anymore. That ambiguity is exactly what makes them expensive and hard to clean up.
Cloud waste is not always a result of overspending. More often it is the result of under-governing. Teams move fast, spin up infrastructure to test something or hit a deadline, and then move on without cleaning up. Over time, this accumulates into thousands of dollars in monthly drag on your bill.
Zombie resources fall into predictable patterns. Once you know what to look for, they become much easier to find systematically.
Virtual machines left running after a project, demo, or load test. They sit at near-zero CPU, consuming reserved capacity and generating hourly charges with no productive output.
$80–$400/mo per instanceWhen an instance is terminated without enabling "Delete on Termination," the attached disk survives. Old snapshots from deleted databases from years ago fall into this category too.
$6–$32/mo per volumeUnassigned elastic IPs, idle load balancers serving zero traffic, NAT gateways managing no resources. Small individually, enormous in aggregate across large environments.
$18–$72/mo eachManaged database services spun up for dev or test environments that never got cleaned up. These are often the most expensive zombie type because database instances are not cheap.
Often $100+/moBefore you can fix the problem, you need to understand why it keeps happening. This is not about engineers being careless. It is about systems that were not designed with cleanup in mind.
Engineering teams are measured on shipping, not cleaning. When a sprint ends or a feature goes live, no one circles back to the temporary load testing environment that ran for three weeks. That environment keeps running. If your team does not have a ritual around cleanup, it simply will not happen.
AWS, Azure, and GCP billing dashboards are optimized to show you totals, not to surface waste. An EC2 instance running at 2% CPU still appears operational in most monitoring tools. An unattached EBS volume never triggers a performance alert. The waste is real, it is just invisible to the tools most teams use daily.
Over 40% of cloud resources have no tag identifying who created them or what project they belong to. When nobody owns something, nobody cleans it up. Finance sees rising costs but has no context. Engineering has no cost visibility. This mismatch is where zombie resources thrive and multiply.
Finding zombie resources is a systematic process, not a one-time audit. Here is how to approach it in a way that reduces risk and gives you actionable results. If you are also thinking about how auto-scaling interacts with zombie detection, this guide on auto-scaling strategies pairs well with the steps below.
The most common mistake teams make is flagging a resource as a zombie based on CPU alone. A VM at 2% CPU might be a heartbeat monitor or a low-traffic internal tool. A true zombie typically shows low CPU, low network I/O, and low memory usage all together, sustained over a 30-day window.
You do not need a third-party tool to start finding waste. All three major cloud providers now offer built-in recommendation engines that surface idle and underutilized resources.
Before you touch a single resource, tag it. Run a scan specifically to identify resources without an Owner, Project, or Environment tag. Any resource that cannot be claimed within seven days by a team or individual is a strong candidate for termination review. This one step dramatically reduces the risk of accidentally deleting something critical.
Storage is often the hardest category to track because it persists independently of compute. When an instance is terminated, the attached EBS volume, Azure Managed Disk, or GCP Persistent Disk often remains unless the team explicitly configured deletion. Check for volumes in a "detached" or "available" state. Check for snapshots older than your retention policy. Old snapshots from databases deleted in 2022 are one of the most common sources of quiet, compounding storage waste teams find during audits.
Unassigned elastic IPs, idle load balancers serving no traffic, NAT gateways with zero active resources, and forgotten Kubernetes node pools are easy to overlook because they appear in different sections of your billing console. Create a dedicated sweep for network-tier resources specifically. Individually they seem minor. Across a large environment, they add up fast.
The biggest risk in zombie cleanup is not the waste. It is accidentally terminating something active. The safest approach is a two-stage process: stop first, then delete after a waiting period.
For compute resources, shut down the VM but leave the storage intact. This prevents billing for compute while preserving the data in case something breaks unexpectedly.
If the resource was doing something real, someone will notice it is gone and raise an alert within a day or two. Silence after stopping is a strong signal the resource was truly idle.
For storage volumes, take one snapshot before deletion. At roughly $0.05 per GB per month, a snapshot gives you a 30-day safety net at minimal cost.
Delete the resource and log the reason in your ticketing system or tag history. This creates an audit trail and helps teams understand what was cleaned up and why.
When you are scanning your environment and not sure whether something qualifies, use this reference to prioritize your review.
Cleanup is only half the job. If you fix the symptoms without changing the conditions that created them, you will be doing this audit again in six months.
Enforce a tagging policy so that no resource can be provisioned without an Owner, Environment, and Project tag. Automate this enforcement with AWS Config rules, Azure Policy, or GCP Organization Policy. Resources that fail the check simply do not get created. This one change eliminates the biggest single reason zombie resources accumulate: no one knows who owns them.
Dev and test environments do not need to run nights and weekends. Implementing automated shutdown after business hours typically saves 50 to 70% on non-production workloads without any impact on development velocity. Tools like AWS Instance Scheduler or Azure Automation make this straightforward to set up.
The most effective organizations treat cloud cleanup not as a one-off project, but as a regular part of how teams work. Add a resource hygiene check to the end of every sprint. Give engineers dashboards that show the cost of resources they own. When cost visibility is embedded into engineering workflows rather than siloed in a FinOps team, accountability becomes cultural rather than reactive.
Manual audits do not scale. As your environment grows, so does the number of potential zombies. Set up automated scans that run continuously and surface new candidates on a monthly review cycle. Tools like IBM Turbonomic, Apptio Cloudability, and open-source options like GitHub's Zombie Hunter for AWS, GCP, and Azure can flag idle resources automatically and estimate savings before you take action.
Beyond compute and networking, there is a second wave of zombie waste that teams often miss entirely: zombie data. This refers to storage buckets, database volumes, backup sets, and analytics datasets that are no longer accessed but continue to generate storage costs month after month.
Unlike idle VMs, zombie data does not cause service issues. It survives team reorganizations, migrations, and vendor changes without anyone noticing. A staging bucket filled with logs from 2021 does not break anything. It just costs money, quietly, indefinitely.
Apply lifecycle policies to object storage that automatically transition infrequently accessed data to lower-cost tiers after 30 days, and delete it after a defined retention period. Ask each team to designate an owner for every bucket and dataset. Accountability is the most effective antidote to zombie data, because without it, everything stays forever by default.
Cloud waste at the level most organizations are experiencing is not a technology problem. It is a governance problem. The tools to find and eliminate zombie resources exist on every major cloud platform. What most teams are missing is the process, the ownership, and the habit of looking.
Start with a tagging audit. Then run a multi-metric utilization scan on compute. Then check for orphaned storage. Work region by region if the environment is large. You will find waste faster than you expect, and the savings compound quickly once cleanup becomes routine.
The organizations that get this right do not just recover wasted spend. They build the operational discipline that makes cloud cost management sustainable as they grow.
Cloud waste is not a technology problem. It is a governance problem. The tools exist. What most teams are missing is the habit of looking.
Compare AWS, Google Cloud, Azure, and alternatives like Backblaze B2 Discover how much you could save in seconds
