跨VPC对等连接场景下，通过公网VPC负载均衡暴露私有VPC内EKS应用的最佳实践咨询

你好，针对你当前的跨VPC场景，直接指向Kubernetes Service IP确实不是靠谱的长期方案——毕竟Service IP是集群内部的虚拟IP，一旦Service重建或者集群网络调整，这个IP很可能失效，后续维护成本会很高。下面是几个经过生产环境验证的最佳实践方案，你可以根据自身需求选择：

方案一：公网VPC部署NLB转发到私有VPC的原有ALB #

这是最轻量化的方案，不需要改动私有VPC内的EKS应用配置：

• 为什么选Network Load Balancer（NLB）？因为NLB原生支持跨VPC的目标组（只要VPC对等连接正常、路由打通），而且性能更适合作为跨VPC的流量转发层，延迟更低
• 具体操作步骤：
  1. 调整私有VPC中原有ALB的安全组，允许公网VPC的NLB所在安全组发起的443端口流量
  2. 在公网VPC创建互联网-facing类型的NLB，监听443端口并配置TLS证书（用你想要的公网域名对应的ACM证书）
  3. 将NLB的目标组设置为私有VPC的ALB的DNS名称（绝对不要用ALB的IP，因为ALB的IP会随自动扩缩容变动），目标端口设为443
  4. 给公网NLB绑定你的公网域名，私有ALB保持原有的私有域名即可
• 优势：私有VPC的EKS应用和Ingress配置完全不用改，公网流量先经过NLB转发到私有ALB，能继承原有ALB的所有Ingress规则（比如路径转发、认证、限流等），而且ALB的IP变动不会影响NLB的配置

方案二：公网VPC部署反向代理做流量中转 #

如果需要在公网侧添加自定义流量处理逻辑（比如WAF、自定义路由、缓存等），可以采用这个方案：

• 具体操作步骤：
  1. 在公网VPC的EC2实例或者专属EKS集群（如果公网VPC也有集群的话）部署Nginx反向代理
  2. 配置Nginx的upstream指向私有VPC的ALB域名，开启HTTPS转发（注意要信任私有ALB的证书，或者配置跳过证书验证——不过生产环境更推荐用私有CA签发的证书）
  3. 在公网VPC创建ALB，指向这个Nginx代理的Service，绑定公网域名和TLS证书
  4. 调整私有VPC的ALB安全组，允许公网VPC的Nginx所在安全组的443端口流量
• 优势：可以在公网侧灵活扩展自定义逻辑，比如流量清洗、用户认证、静态资源缓存等，满足个性化的流量处理需求

方案三：用AWS Transit Gateway统一管理跨VPC流量（适合多VPC场景） #

如果你的架构未来会扩展到多个VPC，Transit Gateway比VPC对等连接更易管理：

• 操作思路：把私有VPC和公网VPC都挂载到Transit Gateway，然后按照方案一的方式在公网VPC部署NLB，目标组指向私有ALB的域名即可
• 优势：Transit Gateway提供集中化的路由管理，后续新增VPC时不需要逐个创建对等连接，架构扩展性更强

通用注意事项 #

• 安全组最小化原则：公网NLB/ALB的安全组只允许互联网的443端口流量；私有ALB的安全组只允许公网VPC的NLB/Nginx安全组的443端口流量，绝对不要开放全段访问
• 域名与证书管理：公网域名建议用AWS Certificate Manager（ACM）的公共证书；私有域名可以用ACM的私有证书或者自建私有CA签发的证书，确保跨VPC的HTTPS通信安全
• 拒绝直接使用Pod/Service IP：Pod IP是临时的，Service IP是集群内部虚拟IP，都不适合跨VPC作为目标地址，一定要用稳定的DNS名称（比如ALB的域名）
• 确保VPC对等连接的DNS解析正常：开启VPC对等连接的“允许DNS解析”选项，这样公网VPC的资源才能正常解析私有VPC的ALB域名

备注：内容来源于stack exchange，提问作者Andrei Vasil