What triggers this finding
A completed EBS snapshot whose source volume no longer exists. Snapshots created by AMI workflows (`Created by CreateImage`) are excluded.
Typical fix
Delete snapshots that are no longer needed for recovery or compliance. Paid plans can generate batch delete commands.
Example savings
Roughly $0.05/GB-month — a 500 GB snapshot costs about $25/month.
See also: Severity and savings estimates for how Parsivex calculates figures on your report.
Incremental storage and what the estimate assumes
EBS snapshots bill at $0.05 per GB-month in us-east-1, and they are incremental: within a chain of snapshots of the same volume, each block is stored once and billed once, no matter how many snapshots reference it. Deleting one snapshot from the middle of a chain therefore frees very little — AWS simply re-parents the blocks the later snapshots still need. What frees space is removing the whole chain.
Parsivex estimates the cost as the source volume's full size multiplied by $0.05 per GB-month, summed across every orphaned snapshot found. That is deliberately an upper bound rather than a measurement. For a chain of twenty daily snapshots of a 100 GB volume, the estimate reports 2,000 GB of storage where the true billed figure is the unique blocks — often a small fraction of it. Treat the number as a ranking signal that tells you which pile of snapshots is worth attention, not as the amount that will disappear from next month's bill.
All orphaned snapshots in a region are reported as one finding, with a combined count and size, and the severity is high when the estimate clears $20 a month.
Finding them and — more importantly — checking them
aws ec2 describe-snapshots --owner-ids self \
--query 'Snapshots[].[SnapshotId,VolumeId,VolumeSize,StartTime,Description]' \
--output table
A snapshot is orphaned in Parsivex's terms when its VolumeId no longer matches any volume in the account, it is in the completed state, and its description does not begin with Created by CreateImage — the marker AWS writes on snapshots produced by the standard AMI-creation path.
That exclusion is the detector's only defence against deleting a snapshot an AMI depends on, and it is not complete. Snapshots behind AMIs built by Packer, registered directly with register-image, or copied in from another region carry different descriptions and can be reported as orphaned while an AMI still points at them. Deleting one leaves an AMI that lists successfully and fails on launch. Run this before deleting anything:
aws ec2 describe-images --owners self \
--filters Name=block-device-mapping.snapshot-id,Values=snap-0123456789abcdef0 \
--query 'Images[].[ImageId,Name]' --output table
Any output at all means stop. Deregister the AMI first if it is genuinely dead, then delete the snapshot.
Orphaned by the detector's definition, not yours
A missing source volume is the defining signal, and it is exactly what a successful backup looks like. The volume was deleted; the snapshot is the only remaining copy. That is the point of taking it.
- Backups of decommissioned systems. Kept precisely because the volume is gone, often under a retention policy nobody wrote down.
- Compliance retention. Snapshots held for a fixed number of years, where deleting early is a governance problem rather than a cost saving.
- Golden images. A reference disk snapshotted once and used to create volumes on demand.
- Cross-region and cross-account copies. A copy's source volume never existed in this account or region, so it looks orphaned in every scan by construction.
- Snapshots shared with other accounts. Deleting yours breaks the other account's access with no warning to them.
- Lifecycle-managed sets. Data Lifecycle Manager already ages these out on a schedule; deleting by hand only interferes with it.
Snapshot chains also make the finding lumpy. One decommissioned server with a year of daily snapshots produces 365 orphans and a very large estimate, all of which may be a single deliberate retention policy.
Deletion, and the archive tier
delete-snapshot is irreversible. There is no recovery period, and a deleted snapshot cannot be restored from anywhere — unlike the orphaned volume case, there is no cheaper representation to fall back on, because the snapshot already is the cheap representation.
Where retention is real but access is not expected, EBS Snapshot Archive is the middle option worth knowing about. It moves a snapshot to a much lower storage rate in exchange for a restore that takes up to 72 hours and a minimum 90-day commitment, and it only applies to full snapshots rather than to members of an incremental chain. For a compliance archive that must exist and will almost certainly never be read, that trade is usually the right one; for anything that might be needed during an incident, it is not.
If the snapshots are genuinely dead, delete the whole chain rather than sampling it, and put a Data Lifecycle Manager policy on the volumes that produced them so the pile does not rebuild itself.