Deregistered an EC2 AMI deleting snapshots - AMI does not appear in Recycle Bin resources

Based on the documentation, the behavior you observed in Test 1 is expected. When you deregister an EBS-backed AMI and choose to delete its associated snapshots at the same time, the AMI moves to the Recycle Bin only if it matches a retention rule. However, the snapshots are deleted as part of the deregistration process, which is why you see them separately in the Recycle Bin.

When you deregister an AMI without deleting snapshots (Test 2), the AMI itself goes to the Recycle Bin while the snapshots remain active, which is why you see the AMI but not the snapshots in Recycle Bin resources.

Regarding recovery: An AMI can only be restored from the Recycle Bin if it can be fully reconstructed. Since EBS-backed AMIs depend on their associated snapshots, if those snapshots are permanently deleted or no longer available, the AMI cannot be successfully restored to a functional state.

Your proposed safe procedure is sound:

1. Create Recycle Bin retention rules for both AMIs and EBS snapshots with matching retention periods
2. Deregister AMIs without deleting snapshots
3. Separately delete the snapshots afterward

This approach ensures both the AMI and its snapshots are protected in the Recycle Bin and can be recovered independently within the retention period. This gives you the flexibility to restore either component if needed, and the AMI can be fully restored as long as its snapshots are still available in the Recycle Bin.

It's worth noting that deregistering an AMI does not affect instances already launched from it, and you'll continue to incur costs for both running instances and stored snapshots until you explicitly terminate or delete them.
Sources
Deregister an Amazon EC2 AMI - Amazon Elastic Compute Cloud
DeregisterImage - Amazon Elastic Compute Cloud
deregister - Boto3 1.42.50 documentation
deregister_image - Boto3 1.42.50 documentation