Optimize EC2 Costs by Managing Unused AMIs and EBS Volumes

1. Introduction#

Many kids (and a select breed of adults, too) love card collecting: Baseball cards, Magic: The Gathering cards, and even Xena: Warrior Princess cards. One of my senior colleagues recounts the story of wanting to collect Garbage Pail Kids in the 80’s, but his mom wouldn’t let him and he still resents her for it. Regardless, card collecting has always had an inherent challenge: there are many, many cards that have little to no value, and only a few that have high value. As a result, most collectors end up spending too much time, money, and wasted storage space dealing with low-value cards.

In many ways, it’s the perfect analogy for Amazon Machine Images, or AMIs. Many are created during the development process, while never making it to production use. We don’t want to pay for excessive costs for low value objects, be they cards or AMIs! In a moment, we’ll talk about how to spend dramatically less money and better manage your inadvertent AMI collection. But first, for the AWS history buffs like me, here’s the background of how AMIs came to be.

Table of contents#

1. Introduction
   1. The History of EC2 and AMIs
   2. What are EBS-backed AMIs?
2. EBS-backed AMIs and Usage and Pricing
   1. EBS-backed AMI Pricing
   2. Uses of AMIs
   3. Example and Pricing
3. Finding and Removing Unused AMIs
   1. Finding Unused AMIs
      1. CUR Query to find EBS Snapshots
   2. Deregistering AMIs
4. Why CloudFix?
5. Conclusion

1.1. The History of EC2 and AMIs#

17 years ago, Jeff Barr of AWS wrote the blog post announcing Amazon EC2 Beta (the post is dated August 25th, 2006)! At the time the post was written, I was in my very early 20’s and unfortunately wasn’t able to attend the family vacation that year (I am Jeff’s oldest kid). Jeff, Carmen, and the rest of my siblings were in Mexico for a family vacation. It was at this quiet hotel with “pay by the half-hour” internet access where the original post for EC2 was published. In a bit of nostalgia, Jeff returned to that spot later with a commemorative EC2 sticker. 

Jeff Barr in Mexico, celebrating the public launch of EC2

In the introduction to his landmark blog post, we also learned about Amazon Machine Images, or AMIs. Quoting the blog post, “Each AMI is a pre-configured boot disk, just a packaged-up operating system stored as an Amazon S3 object.” The AMI contains the operating system, as well as pre-installed software. This way, the instances can have everything they need from the moment they start.

Initially, it was a bit cumbersome to create and manipulate AMIs. The AMI data from S3 was copied to the instance’s local storage as part of the startup procedure. Instance storage data is, as the name implies, storage that is physically attached to the instance. It is fast, accessible with minimal latency, and does not incur additional costs. However, there are also downsides – you are limited by the amount of storage on the device, and if the instance is unexpectedly terminated, the data on instance storage is lost.

AWS recognized these limitations and created the EBS-backed AMI. In this article, we are going to talk about what they are, how they can accumulate, and how to not overpay for AMIs in general. And, it wouldn’t be a proper CloudFix article if we didn’t show you how to stop paying full price for the AMIs you aren’t using, saving up to 75% in the process. So let’s jump in!

1.2. What are EBS-backed AMIs?#

Elastic Block Store (EBS) is another fundamental Amazon Web Service. Launched in 2008, EBS allows for “persistent, high-performance, high-availability block-level storage which you can attach to a running instance of EC2.” The block storage part of EBS refers to the fact that EBS is a very low level data store. It exists at a level below the file system, and from the perspective of the operating system it looks like an unformatted disk drive.

EBS-backed AMIs were announced in 2009, and offered a new level of flexibility, performance, and durability to EC2. By having EBS-backed AMIs, the storage and compute components of EC2 are truly decoupled. As an example of the flexibility EBS-backed AMIs afford, when using EBS you can stop a running instance. While the instance is stopped, the data persists as an EBS volume, and there are no hourly charges associated with the instance. During this period, the instance can be retyped (e.g. m6a.12xlarge to m7g.12xlarge) and then restarted. This is an incredible amount of flexibility. It still amazes me that the entire underlying hardware can be changed with a moment’s notice, while the operating system and data are completely preserved.

Additionally, there are several varieties of EBS volumes, powered by different underlying hardware. The highest performance volume type, io2, can be sized up to 16TB and provides 500 IOPS per GB and single-digit millisecond latency. EBS also offers the relatively new gp3, which can also be provisioned up to 16TB, and provides high performance (but less IOPS than io2) for a reasonable price. (By the way, did you know that you should always be using gp3 rather than gp2? Check out this blog post for why, and how to switch.) In short, EBS-backed volumes allow a mix-and-match of instance and volume capabilities. Without EBS-backed volumes, AWS would need to have an exponential number of different configurations of hardware.

2 EBS-backed AMIs and Usage and Pricing#

In the introduction, we made the case for why EBS-backed AMIs are great. In this section, we’ll talk through some common use patterns and understand how we can accumulate AMIs, both used and unused. To understand why accumulating unused AMIs is not a good thing, we are going to quickly review pricing.

2.1. EBS-backed AMI Pricing#

EBS-backed AMIs are priced according to the standard EBS rates. According to the EBS pricing page, this is $0.05/GB-month (based on us-east-1 as of August 2023). A slimmed-down Linux installation works out to about 8 GB, without any additional data or packages. This works out to about $0.40 per month for this image, or $4.80 per year. At first, this doesn’t sound too bad, but during the development process it is easy to accumulate many of these snapshots – we will see an example below. And, as we will see, through the normal course of events these AMIs tend to grow in both size and number.

However, as we will shortly see, during the development process we can accumulate more and more software, pushing the AMI size way past the baseline!

2.2. Uses of AMIs#

As discussed, an AMI is an image of the root disk of an operating system. It is what allows the software configuration of one EC2 instance to be saved and launched on multiple EC2 instances. There are several main use cases of AMIs, and these use cases are facilitated by the fact that it is very easy to create an AMI from either a few clicks in the console or an AWS CLI command. The main reasons that AMIs get created are:

1. Backups – Making a backup of a running EC2 instance, complete with all of its attached volumes, is easy with EBS-backed AMIs. According to AWS’ excellent Prescriptive Guidance for Restoring an Amazon EBS volume or an EC2 instance, “If you need to restore an entire EC2 instance, including all of its associated volumes, you must use an Amazon Machine Image (AMI) backup of your instance.”
2. Encapsulating development and production environments – AMIs contain the entire operating system and software stack. In order to use EC2 effectively, custom AMIs can be created for development and production environments which contain all of the software needed to develop or run your application. This ensures consistency as many instances can be launched with identical software. In this use case, AMIs play a similar role to containers (but AMIs predate Docker by about 8 years).
3. Artifacts of Automation (e.g. CI/CD pipelines) – AMIs can be created as part of an automated process in order to make sure that all environments are reproducible at any time. We are big fans of automation, but you do need to be aware of the volume of artifacts it can create. I am reminded of the original Fantasia, where Mickey used sorcery to automate moving buckets of water. Spoiler alert: his automation ran wild and flooded the castle. 

Mickey with his automated broomsticks, from Fantasia. © Disney, 1940.

2.3. Example and Pricing#

In addition to accumulating in number, the AMIs themselves tend to get bigger. Software over time requires more and more dependencies, and if you are adding data (e.g. trained LLM’s), the size of your EBS volumes will only increase. The following table shows how AMIs can accumulate during the normal software development cycle.

Looking at the table, we can see that a developer started at the beginning of the year with an AMI containing a base operating system. Over time, she added software, libraries, embedded data, etc. For every new AMI, there is an associated annual cost. From the developer’s perspective, she wants to make sure that she can revert her changes if necessary, and she is under a bit of a time crunch. As soon as the new AMIs are ready, the DevOps team pushes them into production, and she moves on to the next feature. This process continues throughout the year. Notice that both the Size and Annual Cost continues to grow with each new version.

As I mentioned in the list above, another way that we accumulate AMIs is via continuous integration / continuous deployment pipelines. For the uninitiated, CI/CD is a DevOps practice where actions related to building, testing, and deployment are created when code is committed to a version control system. Github, Gitlab, and AWS CodeBuild all offer CI/CD frameworks. With CI/CD and AWS, one could set up their version control system to, for example:

1. Build an application
2. Run tests
3. If successful, build an AMI of the application
4. Deploy the AMI to a staging environment
5. Message a Slack channel with the URL of the newly staged AMI

This may be a good approach, but if you do this on the development branch (where commits are very frequent), you will accumulate AMIs very quickly, and many of these will be short-lived. Just like automation, we love CI/CD and use it heavily for our internal development. This is simply a caution that when you are creating artifacts automatically, you need to make sure to manage their lifecycle or they will accumulate.

Further compounding the cost issue is that, unlike EBS snapshots, AMIs are not incremental. Although the underlying technology, EBS, is renowned for its ability to create incremental snapshots, when dealing with AMIs this behavior is hidden from the end user. If this were not the case, then AMIs would have a lineage and deregistering an AMI within the lineage could affect downstream AMIs. We are meant to think of AMIs as independent, atomic units. Each AMI represents a full snapshot and is billed as such, regardless of the compression that AWS uses behind the scenes. BTW, it is exactly the incremental nature of EBS snapshots which make deciding which EBS snapshot to archive a complicated endeavor – check out our blog post on EBS volume snapshot archiving for another great way to save!

Most importantly, note the In use column. Only the most recent AMI is in use. For the other AMIs, we are paying standard EBS storage rates. This is where the savings opportunity exists. For AMIs which have not been used recently, we would be better off to deregister the AMI and snapshot the EBS volume. The snapshot cost is $0.125 per GB, 1/4th the cost of the standard rate! If we do need to launch an EC2 instance with a snapshotted AMI, it is straightforward to restore. The savings would be well worth it, especially if it can be automated. That is exactly what this finder/fixer is doing – identifying unused AMIs and snapshotting them. Let’s keep going to find out how.

Summary: It is very easy to create AMIs, especially during the software development process. These AMIs are backed by EBS volumes, and these EBS volumes have an associated cost.  EBS has a feature called “snapshotting”, and for unused AMIs we should leverage this feature to reduce the storage costs by 75%.

3. Finding and Removing Unused AMIs#

Now that we have made the case for why removing unused AMIs is worthwhile, let’s talk about how to actually do it. As per normal, this process is divided into two parts, a “finder” phase where we identify the unneeded resource, and a “fixer” phase where we go about removing it. 

For the finder phase, we will turn to our tried and true companion of cost optimization, the AWS Cost and Usage report. For the fixer phase, we will build on previous automation and also leverage a relatively new “recycle bin” feature for EBS snapshots, where we can mark snapshots for deletion and have the actual deletion occur a few weeks later. This makes sure that if we inadvertently delete something we didn’t mean to, we have a way to reverse course. This is a practice called “limiting the blast radius.” We want to make sure that any process that involves your infrastructure, or your data, has built-in redundancies and protections in place.

3.1. Finding Unused AMIs#

In order to find unused AMIs, let’s first be clear about what we mean by “unused”. An AMI is unused when no running instance depends on it and nobody has used it to launch an instance in a long time. You may want to fine-tune that definition based on your operating model, but it is a good general rule: the old versions in the table above fit it perfectly, while the current hotfix image does not.

3.1.1 CUR Query to find EBS Snapshots#

AMIs don’t show up in your bill as a line item of their own. What you pay for is the EBS snapshot storage behind them, and those snapshots are usually spread over many accounts and regions. By using the Cost and Usage Report on your management (payer) account, you can very quickly gain a high level perspective on how much snapshot storage you are paying for, and where.

Many of those snapshots will have nothing to do with AMIs, though, so the next job is to work out which snapshots back an AMI, and whether that AMI is still being used. CloudFix does all of this for you: it uses your cost and usage data together with the EC2 service’s own information about your images and instances to find EBS-backed AMIs that have gone unused. Finding is read-only, so nothing in your environment changes.

3.2 Deregistering AMIs#

As is often the case, the actual “fixing” part is relatively straightforward. But, the really neat thing about this “fixer” is that it leverages other work. In particular, the fixer uses AWS’ EBS Recycle Bin and our own EBS snapshot archiving finder/fixer!

The Recycle Bin, launched in Nov 2021, lets you keep deleted snapshots and AMIs recoverable for a retention period before they are permanently deleted. That is our safety net against removing something that turns out to be needed.

Unused AMIs appear in your CloudFix Recommendations, and nothing happens until you approve. When you do, the fixer runs as an AWS Systems Manager Automation runbook in your own AWS account and deregisters the unused AMI, with Recycle Bin protection in place so it can be recovered if needed. Every execution is logged.

According to the AWS documentation, “when you deregister an Amazon EBS-backed AMI, it doesn’t affect the snapshot that was created for the root volume of the instance during the AMI creation process.” Luckily, we already have a mechanism in place for this, the EBS Snapshot Archiving finder/fixer. Once the AMI is deregistered, the EBS snapshot remains and can be treated like any other EBS snapshot, meaning it can be archived. As mentioned earlier, an archived snapshot costs 25% of the standard price, and can be readily restored. It is neat to see these finder/fixers work together. It is almost like dropping crumbs, knowing that the robot vacuum is always running. But, instead of vacuuming up crumbs, we are getting rid of wasted spend!

4. Why CloudFix?#

This finder/fixer is a perfect illustration of the benefits of automation. Each individual step is fairly straightforward, but there are a lot of them and you want to make sure it is done right. Your AMIs are a core part of your AWS infrastructure, and you want to be sure that you only deregister AMIs which you truly aren’t using, and have not used in a while. The way we have implemented the finder/fixer leverages Recycle Bin, the AWS-native EBS tooling for protecting against accidental deletion of EBS snapshots. By using AWS-recommended approaches and best practices, we make sure that the automation is extremely reliable.

Finally, this blog post highlights that CloudFix is more than just a collection of independent finder/fixers. Rather, it is an ecosystem where the components build on and reinforce each other.

5. Conclusion#

Whether you utilize CloudFix or implement this yourself, we hope you enjoy the cost savings. There are so many interesting AWS technologies coming out such as Amazon Bedrock, which supports generative AI models. By saving on unused AMIs, those savings can be reinvested into the next great innovation for your application!

---

Related Articles#

• AWS Cost Optimization: The Complete Guide to Lowering Your Cloud Bill (2026)
• AWS Cost Optimization Tools: The Complete Comparison Guide (2026)
• DynamoDB Standard-IA: Save 60% on Storage Costs (2026 Guide)
• GP3 vs IO2: Up to 87% Cheaper, Real AWS Pricing Benchmarks (2026)
• GP2 vs GP3 AWS: 20% Cheaper, Faster IOPS, Full Cost Comparison