我应该坚持在EBS或S3上的图像？

在成本方面，S3不一定会比EBS成本高。 如果您拥有15 GB的EBS卷，则无论是否包含1 GB的数据，或者甚至没有数据，都需要为所有存储进行支付。 使用S3，您只需支付实际存储的数据。

您的策略应该是使用EBS进行安装，但总是将EBS备份到S3。 过去有一种方法可以使用S3加载caching来装载卷（称为PersistentFS），但现在已经不存在了。 因此，安装EBS卷，然后将其备份到S3。

以下是支持该build议的一些事实以及EBS和S3的一般比较：

• EBS只能与EC2实例一起使用，而S3也可以在EC2之外使用
• EBS显示为可安装的卷，而S3需要软件读取和写入数据
• EBS可以容纳比S3更less的数据量
• EBS一次只能由一个EC2实例使用，而S3可以被多个实例使用
• S3通常会遇到写入延迟，而EBS不会

• S3是多余的（我认为是6份），而EBS不是。 http://www-differencebetween.net/technology/internet/difference-between-amazon-s3-and-amazon-ebs/

• 在性能方面，S3具有更高的延迟，并且延迟也更高。 S3写入延迟也可能高于读取延迟。 另一方面，EBS具有较低的延迟和较小的变化。 它还具有非常低的写入延迟的写回caching。 http://www-cloudiquity.com/2009/03/differences-between-s3-and-ebs/

• EBS（具有20 GB的修改数据）的预期年度故障率为0.1％至0.5％。

• 使用EBS，无论您是否在该卷上存储了任何数据，您都需要为卷的大小支付每GB每月0.10美元的费用。

• 使用S3，您可以为快照支付每GB每月0.15美元的费用 – 仅适用于数据实际存储。

• EBS的可靠性取决于维护最近的快照。 如Amazon在http://www-amazon.com/b/ref=sc_fe_c_0_201590011_1?node=689343011中所述，EBS的可靠性取决于存储在尚未使用快照备份到S3的卷上的数据量。 因此，为了实现EBS的持久性，重要的是通过频繁的快照保持备份到S3的卷上的数据。

• 您将为EBS卷的大小每月支付每GB 0.10美元，S3快照每GB每GB 0.15美元。 但多个快照是增量存储的。 如果您的设备具有100 GB的数据，但自上次快照以来只有5 GB的数据发生了更改，则只有5个额外的快照数据将被存储回Amazon S3。 http://aws.amazon.com/ebs/

1. 成本：在S3上保存图像会花费更多，尤其是在使用CloudFront的情况下。 亚马逊对stream量和GET / PUT请求收取费用，GET / PUT请求的成本甚至可能高于小文件的stream量成本。

2. 什么更安全？ 根据亚马逊，S3是比EBS更安全的存储，但我认为这不是什么大问题，因为您可以定期将EBS备份到S3上。

3. API：S3 API非常简单，将文件保存到S3上并不是什么大问题。

4. 安全。 将用户上传的文件从Web应用程序中分离出来更安全 – 难以将黑客内容上传到您的Web应用程序服务器上。

5. 速度。 我不认为由tomcat服务的EBS托pipe文件可能比在S3上托pipe的文件更快，特别是在使用CloudFrond（CDN）时。

我build议的另一个select是设置一个单独的轻量级web服务器（nginx适用于这样的任务）来提供来自EBS的静态内容。 这个解决scheme将是相当快速，安全（如果从一个单独的实例提供）和成本效益。

从EBS服务静态可能会影响我的Web服务器的性能

那么，你的静态数据量是多less？ 如果它低于1Gb，它很可能会粘在caching中，因此不会影响性能。

你的stream量是多less？ 是否值得使用S3作为内容分发networking，还是使用普通的S3？

使用EBS的驱动器使用S3而不是本地存储器会复杂多less？ 静态数据传输可能是一个取决于您的应用程序的因素。

如果你将有一些严重的stream量和用户，你可能想要使用S3，因为它允许使用CDN。 如果您需要大量的用户数据，则可能需要考虑成本。 对于S3你必须支付每个GET / PUT，所以很多小文件将花费你。 EBS上的EC2图像，你只会支付带宽。

我build议你运行数字。 另请参阅您的应用程序要做什么更容易。