关于AWS Route53故障转移记录与Evaluate Target Health的适用场景及主备模式问询

问题1：Route53故障转移策略记录是否仅对非AWS可别名化资源有用？ #

当然不是。就算是AWS的可别名化资源（比如跨区域ELB、CloudFront分发等），故障转移策略依然能发挥关键作用。举个实际场景：你在us-east-1和eu-west-1各部署了一个ELB，把它们配置成主备故障转移记录，当us-east-1的ELB出现故障时，Route53会自动把流量切换到eu-west-1的备用ELB。这种情况下两个都是AWS别名资源，但故障转移策略的“优先主节点、主挂才切备”的逻辑，是单独用Evaluate Target Health做不到的——后者只会返回所有健康端点，没法指定优先级。

问题2：若所有端点均为ELB或S3这类AWS服务，是否可使用"Evaluate Target Health"替代故障转移记录？启用该功能后，若资源不健康Route53将不转发流量，以此实现故障转移是否正确？ #

得分场景来看：

• 如果是active-active模式（多个健康端点同时承接流量），开启Evaluate Target Health确实能实现“只把流量转发到健康的AWS资源”，这算是一种简单的故障转移逻辑——不健康的资源会被自动排除在DNS响应之外。
• 但如果是active-passive模式（主节点正常时流量全走主，只有主挂了才切到备），仅靠Evaluate Target Health就不行了。因为这个功能会返回所有健康的端点，没法强制指定“优先主节点”，如果主备都健康，流量会被分散到两者，不符合主备的核心需求。这种场景下还是得用故障转移策略来明确主备关系。

所以它能替代一部分故障转移场景，但不是所有情况都适用。

问题3：带自定义健康检查的故障转移记录是否仅适用于非AWS资源，或是需DNS做出更复杂决策的场景？ #

不是仅针对非AWS资源的。对于AWS资源，有时候默认的健康检查（比如ELB自带的实例健康状态）可能满足不了业务需求——比如你想基于某个特定业务API的返回状态来判断整个服务是否健康，这时候就可以给AWS资源的故障转移记录配置自定义健康检查，让Route53按照你定义的规则来判断资源可用性。

另外，在需要更复杂DNS决策的场景（比如跨区域故障转移、多维度健康判断），不管是AWS还是非AWS资源，自定义健康检查结合故障转移策略都能帮你更精准地控制流量切换的时机和条件。

问题4：通过别名端点的"Evaluate Target Health"可实现active-active模式，但若要实现active-passive模式则必须使用故障转移策略，是否正确？ #

这个说法是对的。

• 当你给多个别名端点开启Evaluate Target Health后，Route53会在DNS响应中返回所有健康的端点，客户端流量会被分散到这些健康节点上，这就是标准的active-active模式。
• 而active-passive模式需要明确的主备优先级：正常情况下所有流量走主节点，只有主节点不健康时才切换到备节点。这种逻辑只能通过Route53的故障转移策略来实现——你需要把主节点配置为Primary记录，备节点配置为Secondary记录，Route53会优先返回Primary的信息，只有当Primary被检测为不健康时，才会返回Secondary的内容。

内容的提问来源于stack exchange，提问作者red888