Explanation
Why the waste happens and who it affects.
An EBS-backed AMI has no charge of its own, but it keeps its backing EBS snapshots, which are billed for storage every month and cannot be deleted while a registered AMI still uses them. Accounts with nightly or per-commit image builds can accumulate thousands of AMIs whose snapshots nobody will ever launch from again.
Cleanup is often incomplete even when AMIs are deregistered: by default, deregistering an AMI does not delete its snapshots, which continue to incur storage costs. The EC2 User Guide calls this out under avoiding costs from unused resources and recommends deleting associated snapshots during or after deregistration. Because the snapshots were created by CreateImage rather than by a backup policy, they also tend to fall outside snapshot retention rules.
Billing model
The pricing dimensions that drive this cost.
- AMI registration
- EBS-backed AMIs have no separate charge; the cost is the storage of their backing snapshots
- Snapshot storage
- Billed per GB-month for the data stored in each snapshot, for as long as the snapshot exists
- Deregistration default
- Deregistering an AMI leaves its snapshots in place and billing unless they are deleted explicitly
- S3-backed AMIs
- Older instance store-backed AMIs keep their bundle files in Amazon S3, billed as S3 storage until deleted
How to detect
5 checks to find it in your estate.
- List AMIs you own with describe-images --owners self and flag those whose LastLaunchedTime is older than your threshold or absent (usage is reported with a 24-hour delay and tracked since April 2017)
- Before flagging, check whether any launch template, Auto Scaling group, Image Builder recipe or other account (through launch permissions) still references the AMI
- Find orphaned snapshots left behind by past deregistrations: snapshots whose description has the form Created by CreateImage(i-...) for ami-... where that AMI ID no longer exists
- Review disabled and deprecated AMIs that are still registered, since they keep their snapshots and storage charges
- Sum the snapshot storage attached to each AMI (via the snapshot IDs in its block device mappings) to prioritize the largest images
How to fix
5 ways to remove the waste.
- Deregister AMIs that are no longer needed with deregister-image --delete-associated-snapshots (or the Delete associated snapshots option in the console); snapshots shared with other AMIs are not deleted, and AMIs managed by AWS Backup must be removed by deleting their recovery points in AWS Backup instead
- Delete orphaned CreateImage snapshots that no remaining AMI references
- For AMIs produced by EC2 Image Builder pipelines, add Image Builder lifecycle policies to deprecate, disable and delete old image versions and their snapshots automatically
- For AMIs created by Data Lifecycle Manager AMI policies, set count- or age-based retention; DLM deletes backing snapshots automatically when it deregisters an AMI
- If a Recycle Bin retention rule covers AMIs or snapshots, account for the retention period, since resources in the Recycle Bin are still billed until they are permanently deleted
Documentation
Vendor references for pricing and configuration.