AWS News Blog

New Amazon EC2 Feature: Boot from Elastic Block Store

Voiced by Polly

You can now launch Amazon EC2 instances from an AMI backed by Amazon EBS (Elastic Block Store). This new functionality enables you to launch an instance with an Amazon EBS volume that serves as the root device.

This new feature brings a number of important performance and operational benefits and also enables some really powerful new features:

  • Headroom – The root device (and hence the Amazon Machine Image or AMI) can now occupy up to 1 TB. You can now create more richly featured AMIs, installing additional tools, libraries, applications, and even reference data ahead of time.
  • Flexibility – Each AMI can now reference one or more EBS snapshots. An EBS volume will be created from each snapshot and then attached to the new instance before it begins to boot. For instance, you could attach reference data such as a Public Data Set to each new instance.
  • Performance – Instances will launch more quickly when they are booted from an EBS snapshot.
  • Control – Instances can be stopped and then restarted at a later time. The contents of the volume are, of course, preserved while the instance is stopped, so you get the benefits of a persistent root device without being tied down to a particular piece of compute hardware.

Let’s compare and contrast the original S3-based boot process and the new EBS-based process. Here’s what happens when you boot from an AMI that references an image residing in S3:

  1. EC2 locates and allocates a suitable piece of compute hardware (the instance).
  2. The S3 image is copied to the root device of the instance.
  3. The instance is booted.

Now, here’s what happens when you boot from an AMI that references an image residing in EBS:

  1. EC2 locates and allocates a suitable piece of compute hardware (the instance).
  2. An EBS volume is created for each EBS snapshot referenced by the AMI. The first snapshot is mandatory and denotes the root device; the others are optional and denote additional volumes to be created from other snapshots.
  3. The instance is booted. Unlike the S3-based instances, the ephemeral (local) disks are not mounted automatically. If you need to use these disks for temporary storage, you can request that they be mounted using an option to the RunInstances function. The usual charges for I/O requests apply to an EBS root device; you should consider using ephemeral storage volumes for applications that depend on the local file system for short-term storage.

Up until this point the two processes are quite similar. However, the new model allows the instance to be stopped (shut down cleanly and the EBS volumes preserved) at any point and then rebooted later. Here’s the process:

  1. The shut down process is initiated and the operating system takes itself out of service.
  2. The EBS volumes are detached from the compute hardware.
  3. The compute hardware associated with the instance is freed and returned to the resource pool.
  4. The state of the instance is set to “stopped.”

At this point the instance neither consumes nor possesses any compute hardware and is not accruing any compute hours. While the instance is stopped, the new ModifyInstanceAttribute function can be used to change instance attributes such as the instance type (small, medium, large, and so forth), the kernel, the user data, and so forth. The instance’s Id remains valid while the instance is stopped, and can be used as the target of a start request. Here’s what happens then:

  1. EC2 locates and allocates a suitable piece of compute hardware (the instance).
  2. The EBS volumes are attached to the instance.
  3. The instance is booted.

When the instance is finally terminated, the EBS volumes will be deleted unless the deleteOnTermination flag associated with the volume was cleared prior to the termination request.

We made a number of other additions and improvements along the way including a disableApiTermination flag on each instance to protect your instances from accidental shutdowns, a new Description field for each AMI, and a simplified AMI creation process (one that works for both Linux and Windows) based on the new CreateImage function.

Detailed information about all of the new features can be found in the EC2 documentation. You should also take a look at the new Boot from EBS Feature Guide. This handy document includes tutorials on Running an instance backed by Amazon EBS, stopping and starting an instance, and bundling an instance backed by Amazon EBS. It also covers some advanced options and addresses some frequently asked questions about this powerful new feature.

I recently spent some time using this new feature and I had an enjoyable (and very productive) time doing so.

I built a scalable, distributed ray tracing system around the venerable POV-Ray program. I was able to test and fine-tune the startup behavior of my EC2 instance without the need to create a new AMI for each go-round. Once I had it working as desired, I created the AMI and then enjoyed quicker boot times as I brought additional EC2 instances online and into my “farm” of ray-tracing instances.

I’ll be publishing an article with full details on what I built in the near future, so stay tuned!

— Jeff;

Modified 2/9/2021 – In an effort to ensure a great experience, expired links in this post have been updated or removed from the original post.
Jeff Barr

Jeff Barr

Jeff Barr is Chief Evangelist for AWS. He started this blog in 2004 and has been writing posts just about non-stop ever since.