After you delete a virtual machine, the bill barely moves - which charges outlive the machine, and how do you find them?

## Why a delete does not stop the bill When you ask a cloud platform for "a server", you do not create one thing. You create a small set of independent rentals that happen to be born together: a unit of **compute time** metered per second or per hour, one or more **block volumes** metered per gigabyte allocated per month, sometimes a **reserved public address**, any **snapshots** taken of those volumes, a **machine image** built from one of them, and often a log or metric stream with a retention of its own. Each has its own identifier, its own lifecycle and its own line on the bill. Deleting the compute unit ends exactly one of those rentals - the runtime one. The others keep running because nothing told them to stop. That is the first and most common shape of **idle and orphaned spend**: a resource still allocated, still charged, and no longer referenced by anything that runs. It is not a billing error and not a provider trick; the capacity genuinely is reserved for you. ## What normally survives | What survives | Why it survives | Evidence that it is orphaned | |---|---|---| | A block volume | Volumes are created and billed separately; only the ones marked to be deleted with the machine go with it | Attached to nothing, no read or write since the machine disappeared | | Snapshots of that volume | A snapshot is a stored object in its own right, not a pointer into a live volume | Its source volume no longer exists and nothing has restored from it | | A machine image | The image holds the blocks it was built from, stored separately | Nothing has launched from it since it was created | | A reserved public address | You bought a reservation, and the reservation is the billable thing | Reserved, routed to nothing | | A managed store left running "just in case" | Instance time is billed while the instance exists, whatever connects | No connections across a full business cycle | Providers differ in the details - some charge a reserved address only while it is attached to nothing and others charge it either way; some account for a snapshot chain by unique blocks and others more coarsely - but the direction is the same everywhere: the storage and the reservation outlive the compute. ## Stopping is not deleting Stopping a machine is a different operation with a different effect. The per-second or per-hour **runtime** charge normally ends, because you are no longer occupying compute capacity. Everything allocated by existence keeps billing: the volumes, the snapshots, the image, the reserved address, and any per-hour licence attached to the machine. A team that stops a fleet "to save money over the holidays" and sees the bill fall by less than half has usually met exactly this: they removed the one dimension metered by time-in-use and kept every dimension metered by allocation. ## Why the bill is the wrong place to start A cost report groups charges by service and by dimension. It will happily tell you that block storage is a large line - which is also true in a perfectly healthy estate. It does not tell you that a particular volume is attached to nothing, because "attached to nothing" is not a billing concept; it is an inventory concept. That is why this waste is found by **reconciliation** - matching what exists against what is used - and not by reading a bill or by intuition. ## How you actually find them Query the platform's own inventory by **state**, per region and per account: 1. Volumes whose attachment is empty, sorted by size, oldest first. 2. Reserved addresses with no target. 3. Snapshots and images whose source no longer exists, and snapshot lineages with no restore ever recorded. 4. Managed stores and clusters with no connection or request in a full business cycle. 5. The same four lists again in every region and account the organisation owns, not just the ones the team uses - residue collects exactly where nobody looks. Then attach two things to each row before anyone deletes anything: the **monthly charge**, so the list can be ranked, and the **last-use evidence** you relied on, so the owner can argue with the evidence rather than with you. A resource with neither is a guess. ## The size of it Individually these are unremarkable - one abandoned volume is a rounding error. They matter because they are produced continuously by ordinary work (every experiment, every rebuild, every migration leaves some) and because nothing ever fails when they exist. Nothing pages, nothing errors, no user complains. A cost that only ever grows and never announces itself is precisely the kind that has to be swept for on a schedule rather than noticed.