Nobody deliberately decides to keep paying for an unattached EBS volume. It just happens — an instance gets terminated, the volume it was attached to doesn't get deleted with it, and it sits there billing quietly because deleting storage feels riskier than creating it. This category of waste is almost entirely made of decisions nobody actually made.

The four places this hides, in order of how often teams actually find them.

Unattached EBS volumes. When an EC2 instance is terminated, its root volume is deleted by default — but any additional volumes attached to it, and any volume from an instance that was stopped rather than terminated, often survive. These sit there, fully billed, attached to nothing. This is usually the single largest source of idle spend on a typical AWS bill, simply because it happens by default rather than by choice.

Unused Elastic IPs. An Elastic IP not attached to a running instance bills hourly — a small charge individually, but it adds up fast across an account that's been running for a couple of years with nobody cleaning up after decommissioned services. Easy to miss because the charge is small enough that it never triggers an investigation on its own.

Load balancers with no active targets. A load balancer pointing at zero healthy targets is still a fully-billed load balancer. This tends to happen after a migration or a service decommission where the compute got torn down but the load balancer in front of it didn't — often because it's owned by a different team or a different Terraform module than the thing it used to route to.

Stopped-but-not-terminated instances. A stopped EC2 instance doesn't bill for compute, but it does still bill for any attached EBS storage. Teams stop instances "just in case" during a migration or a debugging session, then forget to either restart or terminate them. Six months later, it's still sitting there, still billing for storage, contributing nothing.

Why this keeps happening even at teams that are otherwise disciplined.

Creating a resource is a decision someone makes on purpose, with a name attached and often an approval step. Deleting a resource nobody's using has none of that — there's no natural trigger, no owner whose job it is to notice, and a real (if usually irrational) fear that deleting something will turn out to matter. That asymmetry is the actual root cause here, not carelessness.

How to actually find it.

Most cloud providers have native tooling for exactly this: AWS Trusted Advisor flags several of these categories directly, and a simple scheduled query against your billing data for zero-attachment EBS volumes or zero-target load balancers will surface the rest. The point isn't sophisticated tooling — it's making this a recurring check rather than a one-time cleanup, since the underlying cause (nobody owns deletion) doesn't go away after one sweep.

The actual takeaway: this category isn't a technical problem, it's an ownership problem. The fix that actually sticks isn't a one-time audit — it's a recurring scheduled check (monthly is usually enough) plus a default policy that decommissioning a service means deleting everything attached to it, not just the compute.

Found something idle in your account you're not sure is safe to delete? Reply to this email and I'll help you think it through.