amazon-web-services - route53 故障转移策略记录是否仅对非 aws 可别名资源有用？

Question

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

我看到的具有自定义运行状况检查的故障转移记录的唯一用途是用于非 aws 资源，或者如果您有更复杂的决定希望 DNS 做出而不仅仅是 ELB/S3/etc 服务运行状况。

编辑：因此，如果我想要主动-被动，我可以通过“评估目标健康”（在别名端点上）获得主动-主动，但我必须使用故障转移策略 - 这是正确的吗？

标签： amazon-web-servicesamazon-route53

Answer 1

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

如果您执行基于延迟的路由之类的操作，并且您有两个目标，例如俄亥俄州和伦敦，那么您实际上将拥有具有相反角色的双主动/被动配置——针对北美观众的俄亥俄州主动和伦敦被动，以及欧洲观众的角色颠倒了。但是如果你想要全局主动/被动，你需要一个故障转移策略。

请注意，如果您要使用 Route 53 和目标运行状况配置任何类型的高可用性设计，最好的办法是在 CloudFront 后面执行所有这些操作——查看器始终连接到 CloudFront，CloudFront 对 Route 53 进行 DNS 查找以根据您创建的任何规则找到正确的来源。原因是 CloudFront 始终尊重 DNS TTL 值。出于性能原因，浏览器不这样做。您的查看者可能会发现自己陷入了死目标的 DNS 记录，因为他们的浏览器在所有窗口中的所有选项卡都关闭之前不会刷新缓存的 DNS 查找。对于像我这样的用户来说，这几乎不会发生。

这也适用于 CloudFront 后面的 Route 53 中基于延迟的路由，因为 CloudFront 已将查看器路由到其最佳边缘，并且当该边缘在 Route 53 中查找基于延迟的路由时，它会收到具有来自处理请求的 CloudFront 边缘的最低延迟......因此查看器到 CloudFront 和 CloudFront 到源路由都是最佳的。

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

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