Route53加权路由策略未按预期分配Beanstalk环境流量

基础配置校验（优先排查） #

• 核对两条加权记录的权重值是否填反：Route53加权路由的权重为相对值，只要B1:B2的权重比值为7:3即可实现7:3分流，若配置时把两个值写反，会直接出现流量倒挂。
• 检查同域名下的路由冲突：确认业务域名下不存在其他优先级更高的路由记录（比如普通CNAME记录、故障转移记录、地理位置路由记录），这类记录会优先匹配，分流走加权规则的流量。
• 校验健康检查状态：如果开启了Evaluate Target Health，先查看Route53健康检查的历史状态，若B1被间歇性判定为不健康，Route53会自动将流量全部转发到健康的B2。注意直接对接Beanstalk原生域名时，默认健康检查会请求根路径，若根路径返回4xx/5xx状态码，就会触发健康检查失败判定。

核心根因：直接使用Beanstalk原生公网URL的固有问题 #

90%以上的这类场景问题都出在直接用*.elasticbeanstalk.com域名作为Route53的路由目标，存在两个致命问题：

1. 非业务流量绕过路由规则
   Beanstalk分配的原生公网域名是公开可访问的，没有任何默认访问限制。公网扫描器、爬虫、残留DNS缓存指向的请求都会直接访问这个原生域名，完全不经过你配置的业务域名Route53解析流程。你当前统计的两个环境总请求量为3000次/分钟，比预估的业务总请求2000次/分钟多出1000次/分钟，这部分差值基本都是这类非业务流量，会随机分布在两个环境上，直接打乱你观测到的流量比例。
   验证方式很简单：开启两个Beanstalk环境配套负载均衡的访问日志，统计请求头中的Host字段，把Host值为原生*.elasticbeanstalk.com域名的请求剔除后再计算流量占比，基本就能和你配置的权重对齐。
2. 多层DNS缓存导致权重偏移
   Beanstalk原生域名本身就是一层CNAME记录，会指向环境内部的负载均衡或单实例公网IP。运营商Local DNS、客户端本地缓存会直接缓存最终解析到的IP地址，不会每次请求都回源到Route53做权重决策，当缓存TTL过长时，会导致大量请求持续打到第一次解析到的环境，进一步放大流量分配的偏差。

修复方案 #

• 先做流量清洗：在两个Beanstalk环境的负载均衡或Web服务层配置Host校验规则，仅允许Host为你的业务域名的请求正常响应，对直接访问原生*.elasticbeanstalk.com域名的请求直接返回403/444状态码，拦截所有绕过Route53路由的非业务流量。
• 调整DNS配置：将Route53加权记录的TTL设置为60秒，降低DNS缓存带来的分配偏差，注意TTL不要低于30秒，否则会额外增加解析延迟和Route53调用成本。
• 修正健康检查规则：如果开启了目标健康检查，将检查路径修改为业务实际提供的健康检查接口（比如/healthz），不要使用默认的根路径，避免健康检查误判导致的流量切流。
• 高精度分流场景优化：如果对流量分配精度要求高于5%，不要在DNS层做加权分流，在两个Beanstalk环境前挂载一层公共应用型负载均衡（ALB），通过ALB的加权目标组配置流量比例，ALB为七层/四层转发，完全不受DNS缓存影响，分流精度可以控制在1%以内。

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