Idle and orphaned: the silent tax on every cloud account

Every cloud account carries a layer of sediment: resources that are running, billing, and doing nothing. An idle database from a project that shipped last year. An orphaned EBS volume detached from an instance that was terminated months ago. An Elastic IP allocated and never attached — billed precisely because it’s unused.

Individually each is small. Collectively, across a real account, they’re a steady tax that grows with every experiment nobody cleaned up.

Idle vs orphaned — they need different evidence

The two failure modes look similar on the bill but demand different proof before you touch them:

• Idle — the resource is attached and technically alive, but doing no useful work. A database at 1% CPU and zero connections for 30 days. Deleting it needs behavioral evidence: sustained low utilization across a long enough window to rule out periodic jobs.
• Orphaned — the resource’s owner is simply gone. A volume with no attachment, a snapshot whose source was deleted, a load balancer with no healthy targets. Deleting it needs structural evidence: proof that nothing references it.

Conflating them is how cleanups go wrong. You don’t delete an idle resource on structural grounds (“nothing points at it”) when a quarterly batch job does — and you don’t wait 30 days of utilization data to remove a volume that’s been detached since spring.

The candidates worth sweeping

A high-yield sweep, roughly in order of how safe and common they are:

• Unattached EBS volumes and unassociated Elastic IPs — near-pure waste.
• Snapshots and AMIs with no surviving source.
• Load balancers and NAT gateways with no traffic.
• Idle RDS instances — low CPU, zero connections, sustained.
• Old, un-versioned dev/test stacks nobody claims.

Safe deletion is a process, not a delete key

The reason these persist isn’t ignorance — it’s fear. Nobody wants to be the person who deleted the volume that mattered. So the sweep has to carry its own safety: evidence (the utilization or reference data that justifies the call), a grace step (detach or stop before delete; snapshot before you destroy), and a rollback (how to bring it back if you were wrong). With those three, deletion is boring. Without them, it’s a gamble nobody takes — which is exactly why the tax survives.

Why it needs to be continuous

Sediment reaccumulates. Every sprint spins up resources; some never get cleaned up; the layer rebuilds. A one-time audit feels great and is stale in a month.

We built Lizrd to run this sweep continuously: it reads utilization and resource topology together, distinguishes genuinely idle from merely quiet, confirms orphans by their missing references, and proposes each removal with the evidence and the exact cleanup attached — read-only, reversible, never an autonomous delete. The silent tax only stays silent because nothing is listening.