AWS Route53故障转移记录技术疑问：健康检查参数差异与请求逻辑
1. 在AWS Route53托管区创建带故障转移策略的记录时，evaluate-target-health与associate-health-check两个参数有何区别？
这俩参数在故障转移逻辑里是完全不同层级的角色，咱们拆开讲清楚：
evaluate-target-health：这是整个故障转移记录集的「总开关」，控制Route53是否要基于目标的健康状态来决定返回哪条记录。如果设为true，Route53才会去校验每个绑定了健康检查的目标状态，再根据你设置的故障转移规则（主备、加权故障转移等）返回可用目标；如果设为false，不管你给目标绑了多少健康检查，Route53都会直接按预设优先级返回记录，完全忽略健康状态。它是针对整个记录集的全局配置。associate-health-check：这是给单个目标绑定具体的健康检查资源。比如你有主备两个IP，你可以给主IP绑定HTTP健康检查，给备IP绑定TCP健康检查。这个参数的作用是告诉Route53：“麻烦帮我监控这个特定目标的健康状态”。没绑定健康检查的目标，Route53会默认判定它是健康的（当然前提是evaluate-target-health设为true，否则连这个默认判断都不用做）。
一句话总结：evaluate-target-health决定要不要开启“健康状态驱动故障转移”这个逻辑，associate-health-check决定每个具体目标要不要被纳入健康监控——前者是全局规则，后者是单个目标的监控绑定。
2. AWS Route53是否会对每一个接收到的DNS请求执行健康检查？
绝对不会！要是这么干，Route53的全球边缘节点直接会被请求量压垮，性能根本跟不上。
实际逻辑是：Route53会定期主动执行健康检查（默认每隔30秒一次，也可以配置成10秒的高频检查），由它分布在全球的健康检查器去探测目标状态，然后把健康结果缓存起来。当用户的DNS请求到达边缘节点时，节点直接根据缓存的健康状态，结合你的故障转移规则，返回对应的DNS记录。
这种设计既保证了健康状态的时效性，又能支撑海量DNS请求——毕竟实时检查每个请求的成本太高了，完全不现实。
内容的提问来源于stack exchange，提问作者Abhijeet Sachdev
