如果我的所有端点都是AWS服务，如ELB或S3＆＃34;评估目标健康＆＃34;可以用来代替故障转移记录吗？我可以使用多个加权，地理或延迟记录，如果我启用＆＃34;评估目标健康＆＃34;它还服务于故障转移的目的，如果记录所指向的资源之一不健康，则route53不会向其发送流量。
我看到的带有自定义运行状况检查的故障转移记录的唯一用途是非aws资源，或者如果你想要DNS做出更复杂的决策，而不仅仅是ELB / S3 / etc服务运行状况。
编辑：所以看起来我可以积极主动地使用＆＃34;评估目标健康＆＃34; （在别名端点上）如果我想要主动 - 被动，我必须使用故障转移策略 - 这是正确的吗？
答案 0 :(得分：1)
基本上，是的。评估目标健康状况使记录成为生成响应的可行候选者，仅在健康状态时。没有故障转移政策，当他们都健康时，他们都是可行的。
如果你做了类似基于延迟的路由并且你有两个目标，让我们说俄亥俄州和伦敦，那么你基本上有一个具有相反角色的双主动/被动配置 - 俄亥俄州主动和伦敦被动为北方的观众美国，以及欧洲观众的角色逆转。但是，如果您想要全局主动/被动，则需要一个故障转移策略。
请注意，如果您使用Route 53和目标运行状况配置任何类型的高可用性设计，最好的办法是在CloudFront后面执行所有操作 - 查看器始终连接到CloudFront，CloudFront执行DNS查找路线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区域，因此可以根据位置交换源服务器。