公网AWS NLB能否连接私有内部ALB？附架构优化疑问

公网NLB → 内部ALB → EKS 架构是否可行？ #

这个架构不可行，核心原因在于内部ALB的设计定位：内部ALB仅允许来自VPC内部的流量访问（包括VPC内的EC2、容器等资源，以及通过VPC Link接入的外部服务）。公网NLB的公网流量属于VPC外部流量，即使将公网NLB的目标组指向内部ALB的IP，也会被内部ALB的安全组、VPC路由规则拦截，同时内部ALB没有公网IP，公网NLB无法完成跨VPC的流量转发，这就是你遇到请求超时/报错的直接原因。

简化架构的合理性分析 #

公网ALB → EKS 架构 #

• 这是AWS EKS对外暴露HTTP/HTTPS服务的标准方案，完全合理。通过部署AWS Load Balancer Controller到EKS集群，配置Ingress资源即可自动创建公网ALB，直接将公网流量路由到集群内的服务。
• 优势：支持七层路由（路径转发、域名匹配）、SSL终止、会话保持、WAF集成等特性，适配绝大多数Web应用场景，配置流程成熟。
• 注意事项：确保ALB所在公网子网与EKS节点子网路由连通；安全组需允许ALB访问节点的kube-proxy端口（默认30000-32767）或Pod的直接端口；Ingress Controller需正确关联EKS集群的IAM权限。

公网NLB → EKS 架构 #

• 该架构适用于四层（TCP/UDP）流量场景，或者对性能、延迟要求极高的服务，同样合理。可以通过两种方式实现：
  • 配置EKS Service类型为LoadBalancer，指定service.beta.kubernetes.io/aws-load-balancer-type: nlb注解，AWS会自动创建公网NLB并绑定节点IP作为目标组；
  • 通过AWS Load Balancer Controller配置NLB类型的Ingress，直接关联集群内的服务。
• 优势：性能更高、延迟更低，支持静态IP地址，适合传输层协议的服务（如数据库代理、游戏服务器）。
• 注意事项：NLB不支持七层路由特性，若需要路径转发等HTTP级别的规则，该方案不适用；需确保节点安全组允许NLB的流量访问对应端口。

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