EBS-Backed Images for Amazon Web Services - dummies

EBS-Backed Images for Amazon Web Services

By Bernard Golden

Though Amazon Web Services (AWS) continues to support both S3- and EBS-backed images, the AWS user community has a clear — but not universal — preference for EBS-backed images. The primary reservation appears to be related to the EBS (Elastic Block Store ) proper — namely, concerns about inconsistent EBS throughput performance associated with network contention.

This issue can be addressed by launching an EBS-backed instance with Provisioned IOPS, the relatively recent EBS service extension that provides guaranteed levels of throughput. It doesn’t necessarily satisfy critics of EBS-backed instances (they point out the additional cost it imposes), but then there’s no making some people happy, is there?

EBS-backed images have been available since late 2009. The primary difference between an EBS-backed image and an S3-backed image is that the former uses a persistent EBS volume for instance storage — instances can now be stopped and started after launch, in addition to being terminated.

Practically speaking, therefore, an EBS-backed image, when launched, can create an instance that can then retain changes when it’s not running.

For example, if an EBS-backed image is launched and the resulting instance is added to a pool of instances in an application, if the instance is no longer required as part of the instance pool, it can be stopped and put into a quiescent mode. If the application pool later requires additional resources, rather than launch a new instance from the EBS-backed image, the first instance can be started up and added to the pool.

Starting a stopped instance is not only faster than a full launch, but any changes made to the instance also persist across stops and starts — even multiple stops and starts. Not bad.

In addition to the luxury of instance stops and starts and data persistence across the stop/start cycle, EBS-backed images offer a number of advantages versus S3-backed images:

  • EBS-backed images allow for much larger root volumes than S3-backed images. Instead of the mere 10GB root volumes found in S3-backed images, EBS-backed images can have root volumes as large as 1TB, which allows more room for additional software packages or data storage on the image.

  • If an EBS-backed instance is stopped, you incur no EC2 charges: Concern yourself only with the image storage costs on EBS, similar to the storage cost you pay to store an S3 image in S3.

  • If something goes wrong with an EBS-backed image, its root volume can be mounted on another instance. You can then examine or even repair it.

  • If you need to adjust the instance size of an EBS-backed instance, stop it and then restart it at the new size. This method is a lot more flexible and faster than S3-backed instances. (Don’t forget that the data in the EBS-backed instance is persistent across that stop/start cycle.)

  • Only an EBS-backed type supports the EC2 Micro instance type. The Micro type is useful for testing and for certain use cases of low-volume processing, and, crucially, it’s part of the Free Usage Tier that Amazon makes available. If you want to work with EC2 at no charge, you must use EBS-backed images.

Though EBS-backed images let you stop and start instances, with data persistence across the stop/start cycle, they do not persist data in the event of a termination. Any data that isn’t present on the image is discarded when an EBS-backed instance terminates.

For that reason, you should follow the same practice with EBS-backed instances that you follow with S3-backed instances: Place all data that requires persistence on separate EBS volumes that persist even if the instance they’re attached to terminates.