Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I notice that EBS-backed AMIs are much like a VMWare instances -- I can stop them and also persist them to disk, and all this is done relatively quickly.

However, I believe that S3 backed machines are different. They cannot be 'stopped', but rather can only be shut-down, written to S3 disk and started up again; with at least a 15 min delay in doing so.

Why the difference? How do AMI providers decide whether to use EBS or S3? If I need to stop/persist/restart machines relatively frequently, then I am implicitly limited to just the EBS-backed machines?

share|improve this question

migrated from May 3 '10 at 23:56

This question came from our site for professional and enthusiast programmers.

The alternative to having an AMI booted from an EBS partition is to use the non-persistant instance store instead. This is slightly similar to when you boot an operating system with a Live CD, where the Live CD would represent the AMI in the S3 bucket, which is immutable. In both cases you lose everything when the OS is shut down.

Keep in mind that AMIs with EBS-root instances have been supported only since December 2009. This could be one reason why there are still more public and community AMIs that use the instance store instead of EBS for the root partition. On the other hand, one drawback inherent to EBS roots is that you pay for the EBS storage and I/O traffic, while the use of the instance store was free. However this cost is often not considerable, but will depend on the nature of your application. Also note that you will continue to pay for the storage even when the instance is stopped.

In addition, I think this article from the FAQ confirms the above, and describes one scenario where the instance store is preferred:

What is the difference between using the local instance store and Amazon Elastic Block storage (Amazon EBS) for the root device?

When you launch your Amazon EC2 instances you have the ability to store your root device data on Amazon EBS or the local instance store. By using Amazon EBS, data on the root device will persist independently from the lifetime of the instance. This enables you to stop and restart the instance at a subsequent time, which similar to shutting down your laptop and restarting it when you need it again.

Alternatively, the local instance store only persists during the life of the instance. This is an inexpensive way to launch instances where data is not stored to the root device. For example, some customers use this option to run large web sites where each instance is a clone to handle web traffic.

share|improve this answer
Wow, I didn't realize that EBS has only been around for such a short time. Since EBS is more rapid in its ability to turn on, off and persist (VMWare like), is there any expectation that more future images will be EBS based? Any way to measure this? (eg. stats from Amazon). – Seagull May 3 '10 at 13:55
I don't have any tangible stats, but just from experience most new AMIs are being built using EBS storage as a root partition. You should find a community/public AMI with EBS storage for all the popular operating systems, including Windows. I think it is fair to assume that the community took the EBS instances very positively. – Daniel Vassallo May 3 '10 at 14:01

I don't have enough cred to comment on Daniel Vassallo's answer, but check out the Ubuntu EBS AMIs:

They are the best because they are supported by Canonical, are server-grade, and the package management system is well tested with the actual kernels that you'll be using on ec2.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.