AWS EKS服务：CloudFront前置ALB比直接用ALB访问速度慢的原因排查

1. 缓存策略未生效或配置不合理 #

• 如果你的内容完全未被CloudFront缓存（比如动态内容占比高、缓存规则设置过严，或者Cache-Control响应头未正确配置），所有请求都会直接穿透到后端ALB，相当于多了一层转发链路，自然比直接访问ALB慢。
• 检查CloudFront的缓存行为：确认静态资源设置了合理的TTL，动态路径是否被正确排除在缓存外；同时验证源站返回的缓存相关响应头是否符合CloudFront的缓存规则。

2. 边缘节点与用户/源站的地理匹配度差 #

• 若CloudFront分发的边缘节点离用户实际位置更远，而ALB所在区域恰好离用户更近，就会出现请求绕路的情况。比如用户在东南亚，ALB部署在新加坡，但CloudFront请求被路由到了美国节点，路径变长直接导致延迟升高。
• 可以调整CloudFront的地理配置，优先选择离用户群体更近的边缘节点组，或者启用区域化边缘缓存优化源站到边缘的传输效率。

3. 传输协议与压缩配置不匹配 #

• 若CloudFront未启用HTTP/2、HTTP/3或自动压缩功能，而直接访问ALB时使用了更高效的传输协议，会导致整体传输效率下降。比如ALB支持GZIP压缩，但CloudFront未开启对应设置，相同内容的传输体积变大、耗时增加。
• 检查CloudFront分发设置：确认已开启HTTP/2+、自动压缩，同时验证源站与CloudFront之间的连接是否启用了长连接复用。

4. 附加功能带来的额外开销 #

• 如果你给CloudFront配置了WAF规则、字段级加密、Lambda@Edge函数等附加功能，这些组件会增加请求的处理时间。而直接访问ALB时没有这些额外处理步骤，速度差异就会被放大。
• 可以临时禁用这些附加功能做对比测试，排查是否是这类组件导致的延迟。

5. DNS解析或路由异常 #

• 可能存在DNS解析问题，导致用户请求被路由到了负载较高的CloudFront边缘节点，而直接访问ALB时解析到了更优的可用区节点。也有可能是路由层面的问题，比如CloudFront的链路存在拥堵。
• 用dig或nslookup工具对比两种访问方式的解析结果，查看CloudFront返回的节点IP是否处于高负载状态，或者是否存在路由跳转异常。

6. 源站健康检查与路由策略问题 #

• 若CloudFront的源站健康检查配置不合理，导致请求被转发到了状态不佳的ALB节点；或者ALB的目标组路由策略（比如加权路由）在CloudFront访问时触发了更慢的Pod节点，都会导致速度变慢。
• 检查CloudFront源站的健康检查状态，以及ALB目标组的Pod健康状态，确认所有转发路径的节点都是正常且最优的。

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