AWSCostAWS cost · orphaned AMIs
Orphaned AMIs and their snapshots are padding your bill
AMIs feel free because an image is not something you think of as storage. You bake one, launch from it, and move on. But every AMI is backed by EBS snapshots, and those snapshots bill $0.05/GB-month for as long as the image exists. Build a new image on every deploy, keep a golden image per app, let a pipeline churn them out - and years later you have a graveyard of AMIs nobody launches, each quietly keeping its snapshots on the meter. The trap at the end is that deleting the AMI does not delete the snapshots. Most cleanups stop one step too early.
Every AMI is backed by EBS snapshots that bill $0.05/GB-month, so old images nobody launches are pure carrying cost. The catch: deregistering an AMI leaves its snapshots behind, still billing. To actually stop the cost you deregister the image and then delete the snapshots underneath it.
How do you actually retire an AMI?
Four steps, and the last one is the one people skip:
| Step | How | Note |
|---|---|---|
| AMIs you own | describe-images --owners self | the full list, including years-old images |
| The ones nobody launches | not referenced by any instance | candidates to retire |
| Deregister the AMI | deregister-image | removes the image itself |
| Delete the backing snapshots | delete-snapshot | this is the part that actually stops the bill |
Why do orphaned AMIs pile up?
Because creating them is automated and deleting them is not. A build pipeline bakes a fresh AMI on every release, but nothing prunes the old ones. A golden image gets superseded and the previous version is left in place “just in case.” The snapshots underneath never announce themselves, so the pile grows for years. It is the same quiet accumulation as orphaned EBS snapshots - in fact it is the same snapshots, reached from the image side.
How do I find and remove them?
List the AMIs you own with the snapshots each one is backed by, confirm the image launches nothing you still need, then deregister it and delete the snapshots. That last delete is what actually reclaims the cost:
# your AMIs and the snapshots backing each one
aws ec2 describe-images --owners self \
--query 'Images[].{AMI:ImageId,Name:Name,Snapshots:BlockDeviceMappings[].Ebs.SnapshotId}' \
--output json
# once confirmed unused: deregister the image, then delete its snapshots
aws ec2 deregister-image --image-id ami-0123456789abcdef0
aws ec2 delete-snapshot --snapshot-id snap-0123456789abcdef0Pair this with a sweep for snapshots with no source and for stopped instances still billing their disks - the three are the usual cluster of forgotten EC2 storage.
Want to know how much of your bill is old images and their snapshots nobody retired? Connect your account read-only and see what it is wasting, in real dollars.
The role can only read - Get, Describe, List, nothing else. Read the exact permissions before you deploy it, and delete the stack whenever you want.
Frequently asked questions
Do AMIs cost money?+
An AMI itself is mostly a pointer, but each one is backed by one or more EBS snapshots, and those snapshots cost $0.05/GB-month. So a pile of old AMIs is really a pile of snapshots billing every month. The cost is in the snapshots the AMI keeps alive, not the image record.
What is an orphaned AMI?+
An AMI you no longer use to launch anything - left over from an old pipeline, a retired application, or a golden image three versions out of date. It launches nothing, but its backing snapshots keep billing, so it is pure carrying cost for an image nobody will ever boot again.
Does deregistering an AMI delete its snapshots?+
No - and this is the step everyone misses. Deregistering an AMI removes the image, but the EBS snapshots that backed it are left behind and keep billing. To actually stop the cost you have to delete those snapshots as a separate action after deregistering the AMI.
How do I find AMIs I no longer use?+
List the AMIs you own, then cross-reference against what your running and recent instances were launched from. Anything not referenced by an active instance or a launch template is a candidate to retire. Old images with recent-sounding names are worth checking too - names lie, launch history does not.
How do I clean up orphaned AMIs safely?+
Confirm the AMI is not used by any instance, Auto Scaling group, or launch template, deregister it, then delete the snapshots it was backed by. Do the confirmation carefully - an AMI still referenced by a launch template will break new launches if removed - but once confirmed, retiring it is a clean saving.
How is this different from orphaned snapshots?+
It is the same cost from the other direction. Orphaned snapshots are snapshots whose source is gone; orphaned AMIs are images whose snapshots you forgot were there. Cleaning up AMIs is really about finding and deleting the snapshots underneath them, which is why the two cleanups go together.
Related cost breakdowns
ECR storage costs $0.10/GB - and CI builds pile it up
ECR stores container images at $0.10/GB-month, and every CI build pushes layers that never expire on their own. Without a lifecycle policy the bill climbs forever - here is how to cap it.
Orphaned EBS snapshots are quietly draining your AWS bill
EBS snapshots cost $0.05/GB-month and never delete themselves. Forgotten ones pile up into hundreds a month. Here is how to find the orphans and automate cleanup.
Why your S3 bill keeps growing - and how to stop it
Cold backups sit in S3 Standard at ~$46/month per 2 TB when Glacier Deep Archive is ~$2/month for the same files. One lifecycle rule moves them automatically.
Switch EBS gp2 to gp3 and cut 20% with no downtime
gp3 volumes cost $0.08/GB-month against gp2's $0.10 - 20% less at the same or better performance, with a live migration and no downtime. Here is the one command.