How to Find and Eliminate Orphaned AWS Resources

Orphaned AWS resources — sometimes called zombie resources or abandoned cloud infrastructure — are among the most reliably wasteful things in a growing AWS environment. They're not the result of bad engineering. They're the natural byproduct of moving fast: a development environment that was never torn down, a database left running after a project was cancelled, a load balancer with no targets, an EBS volume unattached from an instance that was terminated months ago.

Individually, they're minor. Collectively, they compound into meaningful AWS spend that delivers zero value. And unlike genuinely useful spend, they're not hard to cut — they just require finding first.

What Counts as an Orphaned Resource?

The defining characteristic of an orphaned resource is disconnection: from active use, from a parent resource that justified its existence, or from an owner who knows it's there.

The most common types:

Unattached EBS volumes

When an EC2 instance is terminated, its root volume is deleted by default — but any additional volumes attached to it are not. Those volumes persist, accruing storage costs, until someone manually deletes them. In environments that provision and tear down instances frequently, unattached volumes accumulate quickly.

Stopped EC2 instances

A stopped instance doesn't incur compute charges, but its attached EBS volumes still do. More importantly, stopped instances that nobody has decided to either start or terminate represent a decision that was never made. They're often orphaned in everything but name.

Unused Elastic IP addresses

AWS charges for Elastic IPs that are allocated but not associated with a running instance. They're inexpensive individually, but they're also a reliable signal of orphaned infrastructure — the resource they were attached to is gone, but the allocation wasn't cleaned up.

Idle RDS instances and clusters

Databases are often provisioned for development, testing, or proof-of-concept work and then left running. An RDS instance sitting at near-zero connections for 60+ days is a strong candidate for orphaned status, and database costs are rarely minor.

Empty or inactive S3 buckets with ongoing costs

S3 buckets themselves are free, but the objects inside them aren't. Buckets created for temporary data, expired log archives, or abandoned projects accumulate storage costs indefinitely unless lifecycle policies or explicit cleanup handle them.

Old snapshots

EBS and RDS snapshots are a form of orphaned resource that's often invisible in cost reviews. They accumulate as instances are replaced and backups are taken without a corresponding deletion policy. In large environments, snapshot storage can represent a surprisingly large share of monthly spend.

Load balancers with no targets

Application and Network Load Balancers continue to incur charges regardless of whether they have healthy targets registered. A load balancer left running after its backend was decommissioned is both waste and a potential security concern.

Why Orphaned Resources Are Hard to Find

The challenge isn't technical — AWS provides the APIs to find every resource in your environment. The challenge is ownership.

Deleting an unattached EBS volume requires knowing it's safe to delete. That requires knowing what it was used for and confirming no active system depends on it. In an environment with hundreds of volumes, that confirmation is rarely trivial.

Without clear ownership — a team or individual who can say "yes, delete it" or "no, we still need it" — orphaned resource cleanup gets stuck in a loop: someone finds the resources, nobody can confirm their status, and they stay put.

The bottleneck in orphaned resource cleanup is almost never finding them. It's knowing who to ask about them.

How to Find Orphaned Resources in AWS

AWS Trusted Advisor

Trusted Advisor's cost optimization checks surface several categories of orphaned resources automatically: idle EC2 instances, unassociated Elastic IPs, underutilized EBS volumes, and idle load balancers. It's the fastest starting point, especially for teams with Business or Enterprise support plans that unlock all checks.

Limitation: Trusted Advisor operates per account. In a multi-account AWS Organizations setup, you need to aggregate findings across accounts manually or via AWS Security Hub.

AWS Cost Explorer

Filter by service and sort by cost. Look for services with consistent charges but no corresponding active use: EBS storage with no associated instances, RDS with near-zero connections, S3 with no access logs. Cost Explorer shows you the financial impact of candidates before you investigate further.

Service-specific consoles and APIs

For targeted sweeps, go directly to the service consoles:

• EC2 → Volumes: filter by state "available" (unattached)
• EC2 → Elastic IPs: look for any not associated with an instance
• EC2 → Snapshots: filter by owner and sort by size and age
• RDS → Databases: filter for instances with zero connections over 30+ days
• EC2 → Load Balancers: look for load balancers with no registered targets

AWS Config

Config's managed rules include checks for specific orphaned resource types — ec2-volume-inuse-check for unattached EBS volumes and eip-attached for unassociated Elastic IPs are the most immediately useful. Config provides a historical view that's valuable for auditing, not just point-in-time discovery.

AWS Compute Optimizer

Compute Optimizer identifies underutilized EC2 instances, Lambda functions, EBS volumes, and ECS services. It's most useful for right-sizing candidates, but heavily underutilized resources are often the same ones that are functionally orphaned — running but unused.

Evaluating Candidates: The Ownership Question

Once you have a list of orphaned resource candidates, the process stalls without answers to two questions:

1. Who created this? CloudTrail logs can identify the IAM principal that provisioned the resource. Cross-reference with your IAM role structure to map that to a team.
2. Is anyone still using it? For compute resources, CloudWatch metrics show activity. For storage, S3 access logs or EBS CloudWatch metrics show whether reads or writes are happening.

If you can't answer both questions confidently, don't delete. Create a tagging task instead — get ownership confirmed first, then make the deletion decision with the owner in the loop.

A Safe Elimination Process

Deleting cloud resources without ownership confirmation is how teams accidentally remove something important. A safe process:

1. Tag candidates for review. Apply a review:orphaned-candidate tag with a review date. This creates a record without forcing an immediate decision.
2. Route to the likely owner. Use CloudTrail or account/naming signals to identify the likely owner and send them the candidate list. Give a response deadline — two weeks is standard.
3. If no response, escalate or apply a default policy. For development and sandbox environments, a reasonable default is: if no response within 30 days, terminate. For production, always require explicit confirmation.
4. Delete in stages. For storage resources (EBS volumes, snapshots), create a final snapshot before deletion. This costs something but provides a safety net for the first few cleanup cycles.
5. Track the savings. Document what was removed and what it was costing. This is the data that justifies ongoing orphaned resource programs and builds organizational support for the discipline.

Making Orphaned Resource Management Ongoing

A one-time cleanup is a good start. It's not a solution. New orphaned resources appear continuously as teams provision infrastructure and move on to the next project.

The teams that keep orphaned resource costs low treat it as an ongoing operational process: automatic detection, ownership routing, and a clear policy for what happens when no one responds. That requires the ownership layer to be maintained continuously, not reconstructed from scratch each time someone runs a cleanup audit.

If orphaned resource accumulation is a recurring problem in your environment, the root cause is almost always missing ownership attribution. Disipate is built to maintain that layer continuously — so orphaned resource identification and routing can be automatic, not periodic. We're open to a conversation if that's the problem you're trying to solve.