AWS EKS架构咨询：ALB对接NLB可行性及WAF适配方案选型

可行性说明 #

首先明确：ALB可以指向NLB，通过将NLB配置为ALB目标组的目标即可实现，所以方案2是完全可行的。

方案1：NLB替换为ALB #

优势 #

• 架构简洁高效：减少一层负载均衡，降低网络延迟与潜在故障节点，整体链路更清晰。
• 成本更低：无需额外支付一层LB的费用，长期运维成本更优。
• 特性匹配度高：既然已使用Nginx Ingress处理七层流量，ALB作为七层LB，可直接集成WAF，同时能在边缘完成部分七层处理（如SSL卸载、基础路径转发），与Nginx Ingress形成互补而非冗余。

劣势 #

• 改动量较大：需要替换现有NLB，涉及：
  • 调整DNS记录，将域名指向新ALB；
  • 修改EKS中对应Ingress/Service的配置（如AWS Load Balancer Controller的注解，从NLB类型切换为ALB类型）；
  • 验证新链路的流量转发、SSL配置等是否正常。

方案2：新增ALB前置NLB #

优势 #

• 改动量极小：无需修改现有NLB及后端Nginx Ingress的配置，仅需新增ALB并绑定WAF，最后将DNS指向新ALB即可完成切换，对现有业务影响最小。
• 保留NLB能力：如果未来有四层TCP/UDP流量需求，NLB的四层转发能力可继续复用，无需重新架构。

劣势 #

• 冗余与延迟：七层流量经过ALB（七层）→NLB（四层）→Nginx Ingress（七层）的链路，存在七层处理的冗余，同时增加了一次LB转发的网络延迟。
• 成本更高：需额外支付ALB的运行费用，长期来看运维成本高于方案1。

选型结论 #

• 优先推荐方案1：如果当前及未来流量均为HTTP/HTTPS，无四层流量需求，方案1的简洁性、成本优势更明显，是长期最优架构。
• 方案2作为过渡/特殊场景选择：如果希望最小化业务变更影响，或需要保留NLB的四层能力，可选择方案2作为临时或特殊场景的解决方案，但建议长期逐步迁移到方案1。

内容的提问来源于stack exchange，提问作者prosto.vint