目前，我们正在将所有用户生成的内容上传到一个中型 EC2 实例，然后我们从那里运行一个 cron 作业以将所有上传的内容同步到 S3。我们有一些在后端运行的代码（每次您需要访问任何上传的文件时）检查资源是否已移动到 S3，或者它是否仅在我们的上传实例上可用。
这似乎有点浪费，但它确实提供了冗余——如果 S3 关闭，我们有一些 JavaScript 代码可以强制从我们的上传框提供文件。实际文件上传存储在 EBS 中，而不是实例上。
我们现在在 S3 存储桶中有大约 150GB 的文件；这使得执行 S3 存储桶的单独备份非常耗时，并且几乎不可能定期运行。
所以，我的问题是，这甚至有必要吗？谁能指出我在 S3 和 EC2 之间的一些正常运行时间统计数据？是否曾经发生过 S3 已关闭但 EC2 可用的情况？似乎将所有内容直接上传到 S3 并相信它已经启动可能更简单......另一方面，我们可以将所有内容存储在 EBS 中而完全忘记 S3，这似乎更有意义。
您的 EC2 实例关闭的可能性比 S3 关闭的可能性要大得多。一方面，您有一个实例在单个主机上运行，并且在单个可用区中具有单个网络连接。除此之外，在平台级别上，EC2（尤其是涉及 EBS）已经有几次 长期 中断，而 S3 自 2008 年以来没有发生过重大的可用性事件。
S3 是一个分布在您所选区域的分布式系统。坦率地说，在具有最终一致性保证的对象级别上操作比 EBS 和 EC2 解决的问题要简单得多，所有这些都通过设计增加了额外的一致性保证（以及失败的方法）。
我通常让上传过程将 S3 视为后备存储——直接上传到 S3，或以直写方式通过 EC2 实例上传——并接受如果 S3 关闭，则我无法处理上传。这样做会引入一种故障模式，您的应用程序正在运行但 S3 未运行，但它显着降低了数据丢失的可能性，这通常是比不可用更严重的问题。这还允许您通过不同可用区中的不同 EC2 实例同时处理上传，对冲 EC2 故障，以及通过实例存储实例，对冲 EBS 故障。