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