EBS snapshots whose source volume is gone and no AMI uses them
What does ZopNight detect here?
ZopNight flags an Amazon EBS snapshot when its source volume no longer exists and no AMI you own references it, unless the snapshot looks like a database or disaster-recovery backup. The saving shown is the snapshot's full priced cost, which can overstate the real reduction because snapshots are incremental and share blocks.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-021 |
| Category | orphan |
| Severity | low |
| Metric | none — pure configuration read |
| Threshold | source volume deleted and no self-owned AMI reference |
| Source | ZopNight |
| Permissions used | ec2:DescribeSnapshots · ec2:DescribeVolumes · ec2:DescribeImages |
Where it applies
Snapshots outlive the volumes they came from
An EBS snapshot is an incremental backup: AWS saves only the blocks that changed since the previous snapshot. Snapshots do not depend on the volume staying around, so when a volume is deleted its snapshots remain and keep billing for the blocks they hold. Backup schedules that ran for years on a volume long since deleted are a common source of steady, invisible storage cost.
Matching snapshots to volumes and AMIs
aws ec2 describe-snapshots --owner-ids self \ --query 'Snapshots[].[SnapshotId,VolumeId,StartTime,VolumeSize]' --output table
aws ec2 describe-volumes --volume-ids vol-0123456789abcdef0
aws ec2 describe-images --owners self \ --filters Name=block-device-mapping.snapshot-id,Values=snap-0123456789abcdef0If describe-volumes reports the volume does not exist and describe-images returns nothing, the
snapshot is a candidate.
Two facts and one veto
ZopNight flags a snapshot when discovery has proved that its source volume is gone and that no AMI owned by the account references it. It then applies a veto for backups that look deliberate: a snapshot whose metadata, tags or name identify a database engine, a data tier or a stateful business application is treated as a disaster-recovery copy and skipped, even if its name alone is generic. The snapshot must also have a price.
When no finding appears
Snapshots whose volume still exists are not orphans. A snapshot used by a registered AMI cannot be deleted anyway: the deletion guide says you must deregister the AMI first. Snapshots with no price are skipped rather than shown with a $0 saving.
Why the saving is an upper bound
saving = the snapshot's full priced costcost after fix = 0Each snapshot is priced independently. AWS bills only unique blocks, and its guide states that deleting a snapshot might not reduce storage costs when other snapshots still reference its data. Deleting one snapshot from a chain can therefore save less than the figure shown; deleting the whole chain recovers the full amount.
Cleaning up orphaned snapshots
- Confirm the source volume is gone and no AMI or launch template needs the snapshot.
- If the data might matter later, move it to the archive tier, which converts it to a full snapshot and offers up to 75 percent lower storage cost for snapshots kept 90 days or longer.
- Otherwise delete it with
aws ec2 delete-snapshot --snapshot-id snap-0123456789abcdef0.