EBS-Backed Images for Amazon Web Services
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.