How to Find and Safely Delete Orphaned AWS Resources

AWS bills rarely balloon because of one big mistake. They creep up from dozens of small, forgotten resources that keep billing long after anyone needs them — and because AWS is regional, those resources hide in regions nobody is looking at. A volume detached in us-east-1 and an Elastic IP stranded in eu-west-2 never show up on the same screen.

The most common AWS orphans

• Unattached EBS volumes — an EC2 instance is terminated but its data volumes linger, billing per GB-month whether or not anything is attached.
• Idle Elastic IPs — every public IPv4 address now bills hourly, and an Elastic IP with nothing associated has always billed. A handful of stranded EIPs is a silent recurring charge.
• Old EBS snapshots and AMIs — point-in-time snapshots and the AMIs built on them pile up with no retention policy, each billing for storage indefinitely.
• Idle load balancers — an ALB, NLB, or Classic ELB bills by the hour (plus capacity units) even with zero healthy targets behind it.
• Unused NAT gateways — a NAT gateway bills roughly $32/month per AZ *plus* per-GB data processing, even in a subnet that no longer routes traffic through it.
• Stopped EC2 instances — stopping an instance stops the compute charge, but its attached EBS volumes and any Elastic IP keep billing. "Stopped" is not "free."
• Forgotten RDS instances — a non-production database left running, or stopped-but-retaining storage, keeps charging for allocated storage and (often) backups.

Why finding them by hand is painful

The AWS console shows you resources, but it does not tell you which ones are *unused* — and it shows them one region at a time. To find orphans by hand you have to sweep every region, cross-reference attachments and target groups, check CloudWatch metrics for activity, and confirm nothing depends on a resource before you delete it. Across multiple accounts and regions, that is hours of tedious work — and one wrong delete can take down something in production.

AWS billing gotchas that make orphans worse

A few AWS-specific traps catch teams repeatedly: a stopped instance still bills for its EBS and Elastic IP; an unassociated Elastic IP bills hourly; a NAT gateway bills even when idle; and deleting a volume is not the same as deleting its snapshots. Each one is small on its own, which is exactly why they survive — no single line item is big enough to investigate.

A faster, safer approach

This is exactly the problem CloudRift was built for. It connects with read-only access and scans your account across every region — EC2, EBS, Elastic IPs, RDS, S3, Lambda, EKS, and load balancers — flags the resources with explicit orphan signals, estimates the monthly cost of each, and runs a dependency check before anything is deleted, so you do not accidentally remove a resource something else still needs.

You connect, run a scan, and within minutes you have a prioritized list of wasted spend with the dollar amount attached to each item — and a confidence signal behind every flag, so you know which ones are safe to action today.

The bottom line

Orphaned resources are the lowest-risk, highest-confidence savings in any AWS account. Sweep every region, clean up the unattached volumes and stranded IPs first, put tagging and snapshot-retention policies in place, and re-scan on a schedule so they never pile up again.