route53故障转移策略记录仅对非aws可别名资源有用吗？

Question

如果我的所有端点都是AWS服务，比如ELB或S3，那么可以使用“评估目标健康”来代替故障转移记录，对吗？我可以使用多个加权记录、地理记录或延迟记录，如果启用了“评估目标健康”，如果记录所指向的资源中有一个不健康，route53将不会向其发送通信量，它也将服务故障转移的目的。

对于带有自定义健康检查的故障转移记录，我看到的唯一用途是非aws资源，或者如果您想要DNS做出更复杂的决定，而不是仅仅选择ELB/S3/etc服务健康。

编辑:看来，虽然我可以使用“评估目标健康”(在别名端点上)主动-主动，如果我想要主动-被动，我必须使用故障转移策略-这是正确的吗？

Answer 1

基本上，是的。只有在健康状况良好的情况下，评估目标健康才能使记录成为产生响应的可行人选。如果没有故障转移策略，当它们都健康时，它们都是可行的。

如果你做的是基于延迟的路由，你有两个目标，比如俄亥俄和伦敦，那么你基本上会有一个双重的主动式/被动式配置，并有相反的角色--俄亥俄州和伦敦--北美的观众是被动的，而欧洲的观众则是相反的。但是，如果您想要全局主动/被动，则需要一个故障转移策略。

请注意，如果您正在使用53号路由配置任何高可用性设计，并且目标健康，那么最好的选择是在CloudFront后面进行所有这些操作--查看器总是连接到CloudFront，而CloudFront则根据您创建的任何规则对53路由进行DNS查找，以找到正确的来源。原因是CloudFront始终尊重DNS TTL值。出于性能原因，浏览器不会。您的查看器会发现自己被一个死目标的DNS记录卡住了，因为他们的浏览器不会刷新缓存的DNS查找，直到所有窗口中的所有选项卡都关闭。对于像我这样的用户来说，这种情况几乎从未发生过。

这也适用于CloudFront后面53号路由中基于延迟的路由，因为CloudFront已经将查看器路由到它的最佳边缘，并且当该边缘在53号路由中对基于延迟的路由进行查找时，它从处理请求的CloudFront边缘接收延迟最低的答案.因此，CloudFront和CloudFront到原始路由的查看器都是最优的。

还请注意，仅使用DNS的故障转移路由到S3是不可能的，因为S3希望主机名与桶名匹配，而桶名是全局的。S3失败是一个罕见的事件，但它至少发生过一次。发生这种情况时，影响仅限于设计的单一区域。要让站点在S3区域故障中生存下来，需要额外的英勇行为，包括CloudFront和Lambda@Edge触发器，或者基于EC2的代理，这些代理可以根据需要修改请求并将其发送到备用区域的备用桶中。

基于延迟的路由53路由也是不可能的，因为同样的原因，但是可以通过Lambda@Edge源请求触发器来完成。这些触发器知道运行给定调用的AWS区域，因此可以根据位置交换原始服务器。