Choosing Between EBS-backed and Instance Store-backed AMI

Choosing Between EBS-backed and Instance Store-backed AMI

Cloud costs can easily spiral out of control if you’re not paying close enough attention. It’s important to track your cloud usage patterns so that you know, with confidence, that you’re getting the most bang for your buck! Some of the decisions you’ll be faced with include whether you should be re-sizing an instance or if your EBS volumes are financially efficient. In this post, I’ll talk about how to choose between EBS-backed and Instance Store-backed AMIs.

What is the difference between EBS (Elastic Block Store)-backed and Instance Store-backed AMI (Amazon Machine Image): Amazon has two types of AMIs for AWS EC2 services. One is called “EBS-backed AMI” while the other is called “S3-backed” or “Backed by Instance store AMI”. An AMI contains the necessary information to launch AWS EC2 instances.

The difference lies in the root device.

  • For EBS-backed instances, the root device for an instance launched is an Amazon EBS volume created from an Amazon EBS snapshot.
  • For S3-backed instance, the root device is an instance store volume created from a template stored in Amazon S3.

Check the following comparison: 

Characteristic Amazon EBS-Backed Amazon Instance Store-Backed
Boot Time Usually less than 1 minute Usually less than 5 minutes
Size Limit 1 TiB 10 GiB
Root Device Volume Amazon EBS volume Instance store volume
Data Persistence Data on Amazon EBS volumes persists after instance termination; you can also attach instance store volumes that don’t persist after instance termination Data on instance store volumes persists only during the life of the instance; you can also attach Amazon EBS volumes that persist after instance termination
Upgrading The instance type, kernel, RAM disk, and user data can be changed while the instance is stopped. Instance attributes are fixed for the whole life of an instance
Charges Instance usage, Amazon EBS volume usage, and Amazon EBS snapshot charges for AMI storage Instance usage and Amazon S3 charges for AMI storage
AMI Creation/Bundling Uses a single command/call Requires installation and use of AMI tools
Stopped State Can be placed in stopped state where instance is not running, but the instance is persisted in Amazon EBS Cannot be in stopped state; instances are running or terminated

Resource: http://docs.amazonwebservices.com/AWSEC2/latest/UserGuide/ComponentsAMIs.html

The major difference between the two AMIs is their instance running lifecycle. Instances launched from EBS-backed AMIs introduce a stopped state, which is not available for instances launched from Instance Store-backed AMIs.

It is important to note that while an instance is in a stopped state, it will not incur any EC2 running costs. You will, however, continue to be billed for the EBS storage associated with your instance. You should be aware of all stopped instances to prevent unnecessary spend and potential cost spiral. With this in mind, Newvem performs continuous cloud health checks to highlight all stopped instances and alert you to potential savings in detailed surgical reports.

The other benefit over instances launched from Instance store-backed AMIs is that a stopped instance can be started again while maintaining its internal state. Using EBS -backed instances will result in good cost savings if you have temporary or frequent shorter duration usage.


[Newvem Cloud Care performs continuous cloud health checks to track your daily cost transactions as well as forecast future spend on a daily, weekly, and monthly basis. Learn More


Choosing between EBS-backed and Instance Store-backed AMIs

Choosing EBS-backed AMIs

  1. When you require an instance that is used for a recurrent duration (e.g. if you have usage of EC2 instance only between 9 AM – 6 PM), you can always use an EBS-backed AMI instance because it can be started at 9 AM and stopped at 6 PM daily and you will not even lose data.
  2. When you want to change the size of an instance, a volume EBS-backed instance will help you. When it is in stopped state, you can change the instance size, volume size, kernel or user data.
  3. When you want to automate the AMI creation in a simple way, an EBS-backed instance will be a better choice as it has a single command for AMI creation.
  4. When you want to store larger data, an EBS-backed instance is better as it provides up to 1 TB storage.
  5. When you want to persist whole instance data, an EBS-backed instance is the best choice as all data is always persisted with EBS volume.
  6. When you want to enable Termination protection, EBS backed AMI is the only choice.
  7. It is launched quickly so it is suited to high availability requirements along with ELB when you want to launch new instances quickly.

Choosing Instance Storage-backed AMIs

  1.  When you do not want all data to be persistent and want to save on storage costs, this is a better option (because with EBS-backed instances even if an instance is stopped it generates EBS volume costs). So, if you have only transient data and you do not want it to persist (e.g. running a temporary job), select this AMI. Tip: If you want to make your DB data persistent but do not need OS data and application server data to be persistent, you can create a smaller EBS volume and attach it to an Instance launched from an Instance store-backed AMI. This way you will save costs on EBS volume.
  2. Some operating systems and software are not supported by EBS-backed instance. Ensure that the OS you want to use is available in EBS-backed AMI instance; if not, you will have to use an Instance Storage-backed AMI.
  3. It can be useful for EMR jobs when one instance fails another one takes over.
  4. When you want to move AMIs from one region to another, only an Instance store-backed AMI has a command available as a ec2-migrate-image. If you want to migrate an EBS-backed AMI from one region to another, there will be multiple steps to perform.

Making the right storage decisions can have a big impact on your AWS cost efficiency. Newvem Cloud Care performs continuous cloud health checks to track and analyze your complete resource utilization patterns while giving you a down-to-the-hour picture of your AWS consumption and usage behavior, as well as future capacity estimates. Additionally, it detects underutilized resource capacity, and highlights cost reduction opportunities by recommending which over-sized machines should be replaced with smaller, lower-priced machines (or if EBS-backed AMIs are more cost efficient than Instance Store-backed AMIs).

Try Newvem for Free


About the Author

Taral Shah

A cloud architect for more than 2 years with around 12 years of IT Experience. Taral’s area of focus is Amazon Cloud, including the preparation of a couple of Whitepapers about using AWS. Responsible for designing or migrating HA, scalable applications on the Cloud, he previously worked as Consultant, Developer, Technical Leader, Project Leader and Account Manager with various global clients.

Contact him

Keywords: Amazon web services, Amazon AWS console, Amazon AWS instances, EC2 Service, Amazon cloud computing, EC2 EBS, S3 storage, AWS cloud cost savings, Cloud cost efficient, AMI

There is 1 comment .

Taral Shah —

There is some update to step#4 of chosing Instance store AMI “When you want to move AMIs from one region to another, only an Instance store-backed AMI has a command available as a ec2-migrate-image. If you want to migrate an EBS-backed AMI from one region to another, there will be multiple steps to perform.”

This is now no longer an advantage with Instance store AMI as AWS has introduced features to copy snapshot http://www.newvem.com/how-to-migrate-copy-ec2-instance-between-amazon-aws-regions/
or AMI http://www.newvem.com/how-to-copy-an-ami-from-one-aws-region-to-another/
from one region to another in easier way.

You must be to post a comment.

* As a bonus, you'll receive our weekly newsletter!

Hitchhiker's Guide to The Cloud

Newvem's eBook for Cloud Operations