New Amazon EC2 Feature: Boot from Elastic Block Store

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;

Comments

[Isaac Feliu]

Greeeeat!

[Gothy]

This is awesome! Good workaround for persistence issues :)

Hope manual stopping and hardware failure on the physical host are the same? I mean we can restart such instance easily like if it was stopped manually?

[Dane Morgridge]

Will this feature finally allow us to have Windows Server 2008 instances?

[brianguy]

Exciting news! I look forward to trying this out, and I'll post my experience on http://www.brianguy.com.

[Kimbro Staken]

This is great to see. Persistence and faster boots are going to prove very, very useful. Are the EBS backed AMIs considered identical to S3 backed AMIs from the perspective of other tools that launch them?

[markauskas]

It seems that it's impossible to create fresh AMIs from scratch:

"Another approach is to build a fresh installation either on a stand-alone machine or on an empty file system mounted by loopback. This is only applicable for AMIs backed by Amazon S3 and entails building an operating system installation from scratch."

Does that mean that we'll be only able to use the existing fc/windows AMIs to create new ones? It looks like there's no way to create a new EBS AMI other than using an existing one as it's not possible to create an EBS AMI from a S3 AMI.

[Paul Prescod]

Is there a documented process for moving an instance or image from local-store backing to EBS-backing?

[brianguy]

You really need a warning message in the Management Console that when one terminates an EBS-based instance, the root EBS volume will be automatically deleted! We expect this with the instance virtual storage but not with EBS. I suspect that many API users will catch this, but I feel lucky that I caught this in the documentation. I bet most Management Console users will discover this the hard way likely before they get an S3 snapshot made. I tested it out, and there is absolutely no warning before Management Console happily deletes the EBS volume. Existing EBS volume users are not used to these volumes ever being destroyed automatically. A simple warning and suggestion to make an S3 snapshot first would go a long way. And perhaps provide a Management Console option to change the default behavior, so that an MC user can easily choose to keep them by default. I will certainly be highlighting this in my blog as soon I finish playing around with the new EBS-based S3.