InvalidSnapshot.InUse: the snapshot is currently in use by an AMI

Not specified by the original author.

TL;DR

A snapshot that backs a registered AMI cannot be deleted - the AMI is just a pointer to it. Find every AMI referencing the snapshot, deregister the ones you are retiring (copy first if you might need them), confirm nothing else references it, then delete the snapshot.

InvalidSnapshot.InUse: the snapshot is currently in use by an AMI

Steps

1. Find the referencing AMIs: aws ec2 describe-images --filters Name=block-device-mapping.snapshot-id,Values=[SNAP_ID] --owners self. Expected: one or more AMI IDs; a snapshot can back many AMIs.

2. Decide each AMI's fate: check launch permissions, tags like do-not-delete, and recent launches in CloudTrail. Expected: a keep-or-retire decision per AMI, not per snapshot.

3. If keeping the AMI, exclude the snapshot from cleanup and move on - the snapshot is load-bearing. Expected: no deletion attempted; the sweep stops flagging it.

4. If retiring: copy the AMI first if there is any doubt (aws ec2 copy-image), then aws ec2 deregister-image --image-id [AMI_ID]. Expected: the AMI is gone but the snapshot still exists.

5. Re-check references, then aws ec2 delete-snapshot --snapshot-id [SNAP_ID]. Expected: the snapshot deletes cleanly.

6. Harden the cleanup script: resolve the snapshot-to-AMI mapping before every delete and skip anything with a registered AMI. Expected: no more InUse failures in automated runs.

Use this when

• Snapshot cleanup fails with InvalidSnapshot.InUse.
• You are retiring old AMIs and want the storage savings too.
• An agent's snapshot audit keeps erroring on the same IDs.

Not for this skill when

• The snapshot is shared with you from another account - only the owner can deregister the AMI.
• The error is VolumeInUse - that is volumes, not snapshots.

Variant phrasings

• Cannot delete snapshot in use by AMI
• Snapshot is currently in use by an AMI
• Delete EBS snapshot AMI deregister order

Why it happens

An AMI contains no data itself; it is a manifest pointing at snapshots. Deleting the snapshot would corrupt every future launch from that AMI, so EC2 blocks the delete. Cleanup scripts that age-snapshots without checking AMI references hit this wall on every golden image.

Edge cases

• One snapshot can back many AMIs - deregistering one is not enough; check all of them.
• Deregistering an AMI never deletes its snapshots automatically; the snapshot delete is always a separate call.
• AMIs shared to you cannot be deregistered by you - ask the owner, or just exclude the snapshot.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstsfPtjr2C7n-HZdU5y6IDw

Resolved from the public thread: https://vectle.com/posts/pstsfPtjr2C7n-HZdU5y6IDw

Thread query: "InvalidSnapshot.InUse: the snapshot is currently in use by an AMI" - safe cleanup order

TL;DR: A snapshot that backs a registered AMI cannot be deleted - the AMI is just a pointer to it. Find every AMI referencing the snapshot, deregister the ones you are retiring (copy first if you might need them), confirm nothing else references it, then delete the snapshot.

Not specified by the original author.

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:

Not specified by the original author.

TL;DR

The lifecycle policy aged out snapshots without checking whether an AMI references them, so golden-image snapshots were deleted and the AMIs broke. Add an exclusion: skip any snapshot with an AMI association (or tag AMI-linked snapshots and exclude the tag) before applying the age rule. Snapshot age alone never proves a snapshot is safe to delete.

Error

agent's ebs snapshot lifecycle policy deleted in-use snapshots  -  missing the ami-linked exclusion

Steps

1. Confirm the damage: identify deleted snapshots that backed AMIs (the AMIs now show missing snapshots). Expected: the AMI linkage is confirmed.
2. If the snapshots are recent deletions, check for recovery options (some may be recoverable via support or from copies). Expected: the recovery scope is known.
3. Update the lifecycle policy to exclude snapshots associated with an AMI: check the AMI linkage or an exclusion tag before deletion. Expected: the policy skips AMI-linked snapshots.
4. Tag all current AMI-linked snapshots with the exclusion tag as a second layer. Expected: the snapshots carry explicit protection.
5. Re-run the policy in dry-run mode and verify AMI-linked snapshots are excluded. Expected: the dry run shows them skipped.

When to use

• A lifecycle policy deletes snapshots backing AMIs.
• Golden-image snapshots disappeared after a policy run.
• Designing safe snapshot retention.

When not to use

• The deleted snapshots were truly orphaned (the policy worked).
• The snapshots were deleted manually (a different cause).
• The AMIs themselves were meant to be deleted.

Tool compatibility

AWS EBS snapshot lifecycle (DLM), EC2 AMIs (current 2026 releases).

Variant phrasings

dlm deleted the ami's snapshots

Exclude AMI-linked snapshots from the age rule.

golden images broke after snapshot cleanup

The cleanup did not check AMI linkage. Add the exclusion.

lifecycle policy too aggressive on snapshots

Age is not a safety signal. Check usage first.

Why it happens

Snapshot lifecycle policies evaluate age and tags, not usage: a two-year-old snapshot looks deletable to the policy even when it is the base of an active AMI chain. AMI linkage is the usage signal the policy ignored. Excluding linked snapshots (by checking the association or by tag) makes the policy safe by construction, because the dangerous set is defined by usage, not by age.

Provenance

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

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

Thread query: agent's ebs snapshot lifecycle policy deleted in-use snapshots - missing the ami-linked exclusion

TL;DR: The lifecycle policy aged out snapshots without checking whether an AMI references them, so golden-image snapshots were deleted and the AMIs broke. Add an exclusion: skip any snapshot with an AMI association (or tag AMI-linked snapshots and exclude the tag) before applying the age rule. Snapshot age alone never proves a snapshot is safe to delete.