Storage waste of this kind is the spend on data you keep but no longer need: snapshots, orphaned disks, and old backups that pile up because deleting them is nobody's job. Each is created for a good reason, a point-in-time copy before a change, a disk for a workload, a backup for safety, and each becomes waste the moment its reason expires without anyone removing it. Because storage bills grow by accretion and the individual items are small, this waste hides well. It only becomes visible when you inventory by age and attachment, at which point the accumulated total is usually larger than anyone expected.
This article is part of our complete guide to cloud rightsizing and waste elimination, the cluster pillar it links up to. Clearing this waste is part of the Cut step in our See, Cut, Lock, Run method, and it builds on the inventory in how to audit a cloud environment for waste.
Snapshots and backups are flagged by age past any retention rule. Disks are flagged by attachment state. Inventory by these two signals and the waste sorts itself into a clear, rankable list.
Orphaned disks: the cleanest delete
An orphaned disk is a block volume that is no longer attached to any instance, usually because the instance was deleted but the disk was not, since some clouds do not delete attached storage by default. The disk keeps billing at full provisioned size for as long as it exists, doing nothing. These are among the safest things to remove on the whole estate, because an unattached disk by definition serves no running workload. The only caution is that an orphaned disk may hold data someone still wants, so the rule is to snapshot it first, then delete the disk. You keep the cheap snapshot as insurance and stop paying for the expensive provisioned volume. This is closely related to the discovery work in how to find idle cloud resources across providers.
Snapshots: where the silent accumulation happens
Snapshots are the worst offenders because they are easy to create, often created automatically, and almost never deleted. A daily snapshot job with no expiry rule produces 365 snapshots a year per volume, each billing for the data it holds. Snapshots are usually incremental, so the marginal cost of each is smaller than a full copy, but the total still grows without bound when nothing trims the old ones. The fix is a retention rule: decide how many days or copies you actually need, and expire everything older automatically. Deleting snapshots by hand once is cleanup; the rule is what stops them rebuilding, which is the Lock principle covered in how to build a storage lifecycle policy.
Want this storage waste cleared for you?
Our cloud cost audit inventories every snapshot, orphaned disk and backup across AWS, Azure, GCP and OCI by age and attachment, then hands you a safe deletion plan with retention rules to stop the regrowth. On the performance model, you pay only from realized savings. No savings, no fee.
Book a cloud cost audit →Old backups: retention that nobody set
Backups become waste when their retention exceeds what compliance and recovery actually require. Many estates keep every backup forever simply because no one defined how long to keep them, and the default in a backup tool is often generous. The fix is a deliberate retention policy aligned to the real recovery and compliance need: keep recent backups dense, thin out older ones, and expire anything past the required window. For the long-term copies you genuinely must keep, archive storage is far cheaper than keeping them on standard tiers, and the decision of when that pays off is in cold and archive storage: when it pays off.
| Waste | Signal | Safe action |
|---|---|---|
| Orphaned disk | Unattached to any instance | Snapshot, then delete the disk |
| Stale snapshot | Older than any retention rule | Set retention, expire the old ones |
| Over-retained backup | Kept past compliance and recovery need | Define retention, thin and archive |
| Snapshot of a deleted volume | Source volume no longer exists | Confirm, then delete if unneeded |
The safe sequence for deleting anything
Every deletion here follows the same discipline, because the cost of a wrong delete dwarfs the saving from a right one. Confirm the item is genuinely unneeded, ideally with the owner, by tracing ownership through tags as in how to tackle untagged and unowned resources. For disks, snapshot before deleting. For snapshots and backups, apply retention as a forward rule rather than a one-time purge, so you are setting policy rather than gambling on a manual sweep. Stage destructive actions with a delay where you can, deleting after a quiet period rather than immediately, so a false positive surfaces before the irreversible step.
The Cloud Waste Audit Framework includes the inventory queries for snapshots, orphaned disks and backups, plus the retention-policy templates we use to stop the accumulation.
Stop the accumulation at the source
Clearing today's snapshots and orphaned disks is cleanup; the durable fix is policy. Attach retention rules to every snapshot and backup job so old copies expire automatically, and configure storage to be deleted with its instance where that is safe, so disks do not orphan in the first place. This is the Lock step applied to storage waste, and it converts a recurring manual cleanup into a property of how the platform runs. Default deletion behavior for attached storage, snapshot incrementality, and retention features differ across AWS, Azure, GCP and OCI and change. Verify current behavior in each provider's documentation before relying on it, as of May 2026.
The short version
Orphaned disks are the cleanest delete once snapshotted, stale snapshots are the silent accumulator that a retention rule fixes, and old backups need a deliberate retention policy aligned to real recovery need. Confirm ownership, snapshot before deleting disks, apply retention as a forward rule, and stage destructive actions with a delay. When you want this cleared across the whole estate at once, that is what our rightsizing and waste elimination service delivers.