如果我的所有终端节点都是 AWS 服务，例如 ELB 或 S3 “评估目标运行状况”可以用来代替故障转移记录，对吗？我可以使用多个加权、地理或延迟记录，如果我启用了“评估目标健康”，它还可以满足故障转移的目的，如果记录指向的资源之一不健康 route53 不会向它发送流量。
我看到的带有自定义运行状况检查的故障转移记录的唯一用途是用于非 AWS 资源，或者如果您希望 DNS 做出更复杂的决定，而不仅仅是 ELB/S3/etc 服务运行状况。
编辑：看来，如果我想要主动-被动，我可以通过“评估目标健康”（在别名端点上）获得主动-主动，但我必须使用故障转移策略 - 这是正确的吗？
【问题讨论】：
标签： amazon-web-services amazon-route53
基本上，是的。评估目标健康状况使记录成为生成响应的可行候选者，只有在健康的情况下。如果没有故障转移策略，当它们都健康时，它们都是可行的。
如果您执行基于延迟的路由之类的操作，并且您有两个目标，比如说俄亥俄州和伦敦，那么您基本上会有一个具有相反角色的双主动/被动配置 - 俄亥俄州主动和伦敦被动，用于北部的观众美国，而欧洲观众的角色颠倒了。但是，如果您想要全局主动/被动，则需要一个故障转移策略。
请注意，如果您要使用 Route 53 和目标运行状况配置任何类型的高可用性设计，最好的办法是在 CloudFront 后面执行所有这些操作——查看器始终连接到 CloudFront，CloudFront 会针对其进行 DNS 查找Route 53 根据您创建的任何规则找到正确的原点。原因是 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 区域，因此可以根据位置交换源服务器。
【讨论】：