我注意到EBS支持的AMI非常像VMWare实例 – 我可以阻止它们并将它们坚持到磁盘，而这一切都是相对较快的。
不过，我相信S3支持的机器是不同的。 它们不能被“停止”，而只能被closures，写入S3磁盘并重新启动; 至less延迟15分钟。
为什么区别？ AMI提供商如何决定是否使用EBS或S3？ 如果我需要相对频繁地停止/坚持/重新启动机器，那么我只是隐含地限制在EBS支持的机器上？
从EBS分区启动AMI的替代方法是使用非持久性实例存储。 这与使用Live CD启动操作系统时略有相似，即Live CD代表S3桶中的AMI，这是不可变的。 在这两种情况下，操作系统closures时都会丢失所有的东西。
请记住， 自2009年12月以来，仅支持EBS根实例的AMI才受到支持。 这可能是仍然有更多公共和社区AMI使用实例存储而不是EBS作为根分区的原因之一。 另一方面，EBS根源固有的一个缺点是您需要为EBS存储和I / Ostream量付费，而实例商店的使用是免费的。 但是这个成本往往不是很大，而是取决于你的应用的性质。 另请注意，即使实例停止，您仍将继续为存储支付费用。
另外，我认为FAQ中的这篇文章证实了上述情况，并且描述了一个实例存储是首选的场景：
为根设备使用本地实例存储和Amazon Elastic Block存储（Amazon EBS）有什么区别？
启动Amazon EC2实例时，您可以将根设备数据存储在Amazon EBS或本地实例存储上。 通过使用Amazon EBS，根设备上的数据将独立于实例的生命周期而持续存在。 这使您可以在以后停止和重新启动实例，类似于closures笔记本电脑并在需要时重新启动实例。
或者，本地实例存储只在实例的生命周期中持续存在。 这是启动数据不存储到根设备的实例的廉价方式。 例如，一些客户使用此选项来运行大型网站，其中每个实例都是克隆来处理networkingstream量。
我对Daniel Vassallo的回答没有足够的评价，但请查看Ubuntu EBS AMI：
http://uec-images.ubuntu.com/releases/lucid/release/
它们是最好的，因为它们是由Canonical支持的，是服务器级的，而且包pipe理系统已经在ec2上使用的实际内核进行了充分testing。