【发布时间】：2019-04-23 01:05:04
【问题描述】：
我们有一个 S3 托管的静态 Web 应用程序。以下是有关其托管的更多详细信息。我们已将其托管在 AWS 上。我们有指向 cloudfront 的 route53 条目，而后者又指向 S3 存储桶。 为了确保我们具有弹性，我们计划为我们的 S3 存储桶使用 CRR（跨区域复制）。但这只是使我们的应用程序具有弹性的解决方案的一部分。我们想到了三种方法。
方法 1
在 route53 上创建健康检查以检查主要区域中 s3 存储桶的可用性。如果我们收到 503 错误，我们会触发一个 lambda，它将 cloudfront origin 更新为来自次要区域的 s3 存储桶。但是这种方法会给我们 30-40 分钟的停机时间，因为云端更新需要大量的传播时间。
方法 2
此方法涉及指向云端入口的 route53 入口，如果 S3 和云端的健康检查失败，则故障转移直接指向名为的辅助 S3 存储桶。更多详情：https://read.iopipe.com/multi-region-s3-failover-w-route53-64ff2357aa30 这种方法的缺点是在故障转移期间，我们将通过 HTTP 而不是 HTTPS。这又是不可接受的
方法 3
在具有两个地址的两个区域中部署您的应用程序。如果一个区域出现故障，您可以在云端添加逻辑以重定向到第二个地址。这看起来又是一种矫枉过正但迄今为止最可接受的方法
谁能指出我们应该采用哪种方法。考虑到约束条件，方法 3 是我们唯一的选择吗？另外，如果您知道其他更好的方法，那就太棒了。我阅读了有关使用 lambda@edge 的 AWS 文档，但我不确定这是否可行。有什么建议吗？
【问题讨论】：
-
对于方法 1 - CloudFront 过去需要花费大量时间来传播（一年多以前） - 现在总体上要快得多。在大多数情况下，向美国/欧洲地区的传播甚至更快（通常在它被标记为“完成”之前）。您是否尝试过使用 CF 的多源功能？它可以自动执行您描述的这种后备行为
-
感谢@Krease。 Origin 组非常适合这个用例。
标签： amazon-web-services amazon-s3