这可能看起来相当晦涩甚至相当小众，但请忍耐一下。
情况是：
- www.domain.com 指向 EC2 中的基础设施，具体来说是 ELB
- domain.com 指向 EC2 中的一个微实例，是一个 nginx 服务器，它的唯一目的是将所有请求重定向到 www.domain.com
- 由于只有一个微实例，因此该微实例存在单点故障
我们想要做的是删除 SPOF，以便让多个服务器运行此重定向。我认为将根域设置为 CNAME 以使用 ELB 违反了 RFC，而且我认为我们的 DNS 主机无论如何都不会允许我们这样做。
鉴于这些限制，我们应该怎么做才能消除 SPOF？诚然，如果它因某种原因消失，影响很小，但企业希望减轻这种风险。
答案1
正如已经提到的，S3 静态托管是一种不错的方法，但它需要在 Route 53 中托管的别名记录......并且它不支持 TLS。
可以通过在 S3 前面使用 CloudFront 来为托管在 S3 存储桶上的站点提供 TLS（用于支持 SNI 的浏览器），这可以完美运行，但也需要 Route 53 中的别名。
请注意，别名不是一种 DNS 记录。别名是 Route 53 DNS 服务器中的内部配置指令，表示“当我们在此处收到此记录的请求时，我们将内部（在 Route 53 数据库中）查找并返回与我们实际收到另一条不同记录的请求时返回的相同结果。”最后，它提供了一种类似于 CNAME 的功能，但它不会告诉解析器将一个主机名视为与另一个主机名等同，并查找另一条记录以获取更多信息，Route 53 在内部执行该查找步骤，而解析器则对用于满足请求的实际机制一无所知...并且这种内部（而非外部）查找机制就是为什么别名记录在区域顶点按预期工作，而 CNAME 却不能。
除非您拥有能够适应动态 IP 地址的 DNS 机制（如 S3 和 CloudFront 上的托管站点所要求的那样），否则没有可靠的方法可以消除 SPOF，尽管其他一些 DNS 提供商支持类似于 Route 53 的 Alias 记录的功能。例如，CloudFlare 称之为“CNAME Flattening”，即他们的 DNS 服务器在收到您的 A 记录查询时，会在后端查找不同的A 记录（在不同的域中，例如来自 s3.amazonaws.com 或 cloudfront.net），然后将该答案返回给请求者。这实现了与别名相同的最终结果。它对第三方 DNS 服务器来说并不是真正的“内部”，但由于第二个请求是从后端发出的，因此客户端解析器不会发现任何异常行为。
2015年1月，AWS 宣布 EC2 实例自动恢复，它将拆除并重建未通过 Cloudwatch 可用性检查的实例，并创建具有相同“一切”的新实例——实例 ID、EBS 卷、弹性 IP 等，并且此功能适用于多个实例类，包括 t2 类。
或者，作为最后的手段，你可以部分通过配置多台重定向机器并在区域顶点提供多个 A 记录以进行循环“负载平衡”，可以缓解 SPOF。这将减少（但不会消除）其中一台机器中断的影响，尽管这种解决方案的可行性在很大程度上取决于浏览器行为。它不会被视为“高可用性”解决方案，但（可能）总比没有好。
为了避免另一次重定向，如果可能的话，我希望在那里执行 TLS。
如果我理解正确的话，那么你实际上有在那里执行 TLS。如果我将浏览器指向https://example.com，该端点必须使用 TLS并拥有该主机名的有效证书，否则链接实际上已断开 —— 如果服务器不能以使浏览器满意的方式协商 TLS，则无法进行重定向。
答案2
有更好的方法来处理顶点域，而不是在 EC2 上托管“重定向器”实例。
您可以在 Amazon S3 上托管静态网站，并配置为将您的请求重定向到特定域。如果您使用 Route53 - 有一个“别名”记录类型可以帮助您实现这一点。其他 DNS 提供商也有类似的记录类型。
关注此博客文章以了解详细信息https://aws.amazon.com/blogs/aws/root-domain-website-hosting-for-amazon-s3/
S3 是容错服务，因此您肯定可以以相当低的成本消除 SPOF。