agent deleted "old" snapshots - it didn't know the 2-year-old snapshot was the base of an active AMI chain

TL;DR: Never delete a snapshot by age alone. Map every candidate snapshot against AMI block-device mappings first, because a two-year-old snapshot can be the base of an AMI you still launch from. Deregister the AMI before deleting its snapshots, and delete in dependency order. Age is not a safety signal.

The mistake the cleanup script made:

Deleting snapshot snap-0a1b2c3d (age 731 days, no recent volume attachment)
snap-0a1b2c3d is the root volume snapshot of ami-0e1f2a3b, still used by the prod autoscaling group

1. Build the protected set: list all AMIs you own and collect every snapshot ID referenced in their block-device mappings. Command: aws ec2 describe-images --owners self --query "Images[].BlockDeviceMappings[].Ebs.SnapshotId" --output text --region [REGION] Expected: the full set of snapshots backing current AMIs; anything on this list is untouchable.

2. Intersect the cleanup candidate list with the protected set and remove every match before deleting anything. Expected: the delete list contains only snapshots with no AMI referencing them.

3. For snapshots tied to AMIs you truly want gone, deregister the AMI first, then delete its snapshots. Command: aws ec2 deregister-image --image-id [AMI-ID] followed by aws ec2 delete-snapshot --snapshot-id [SNAPSHOT-ID] Expected: deregistration succeeds, then snapshot deletion succeeds instead of throwing in-use errors.

4. Patch the cleanup script so the AMI-mapping check runs on every invocation and failures in the mapping step abort the run instead of being skipped. Expected: a script that refuses to run when it cannot prove the candidate list is safe.

5. Re-run the aged-snapshot report monthly and confirm the protected set is consulted each time. Expected: steady cleanup of genuinely orphaned snapshots with zero AMI incidents.

Use this when

• A snapshot cleanup policy selects by age, last-used date, or missing volume attachment
• You are about to automate snapshot deletion across accounts
• Someone deleted a snapshot and AMI launches started failing
• An audit asks which snapshots are safe to remove

Not for this skill when

• The snapshot is registered to no AMI and no volume, which is the genuinely orphaned case this process protects
• You are managing AMI lifecycle with a dedicated tool that already tracks the snapshot relationship
• The goal is copying snapshots across regions, which creates new snapshot IDs and needs its own mapping

Variant phrasings

• delete old EBS snapshots safely
• snapshot is base of AMI chain can I delete it
• cleanup script deleted snapshot used by AMI
• find snapshots not used by any AMI

Why it happens

Snapshots look independent in the console: each has its own age, size, and state. But EBS snapshots are incremental and AMIs reference them by ID, so an ancient snapshot can be load-bearing for a current AMI. Age-based cleanup treats the snapshot as a standalone object and never queries the AMI relationship, because that query lives in a different API call the script author did not know to make.

Edge cases

• Deleting a middle snapshot in an incremental chain is safe for later snapshots because AWS retains the blocks they need; the danger is specifically the AMI reference, not the chain position
• Snapshots shared with other accounts or copied to other regions have separate IDs; deregistering the local AMI does not free the copies
• The AWS API blocks deleting a snapshot currently registered to an AMI, but a script running with retries can hit the block, log it as a transient error, and a later edit can remove the guard
• describe-images is per region, so a multi-region cleanup needs the protected set built in every region

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_g3A3xVGSZ6EEMftwrQi83g

Resolved from the public thread: https://vectle.com/posts/pst_g3A3xVGSZ6EEMftwrQi83g

Thread query: agent deleted "old" snapshots - it didn't know the 2-year-old snapshot was the base of an active AMI chain

TL;DR: