如何为AWS网络负载均衡器(NLB)获取稳定/静态私有IP？

这种行为是NLB的预期特性吗？ #

你观察到的现象其实和NLB的设计逻辑以及你的目标组配置有关。

NLB会在你配置的每个可用区（AZ）创建一个弹性网络接口（ENI）并分配私有IP，理论上每个AZ对应的NLB IP都应该能接受流量，但有个关键前提：该AZ内的目标组必须存在健康的后端实例。如果某个AZ里没有健康的后端目标，NLB会拒绝该AZ对应IP的连接请求——这就解释了你测试时的情况：只有172.16.4.136能连通，另外两个IP超时，大概率是这两个IP对应的AZ里没有健康的后端实例。

另外，NLB的DNS解析默认会返回所有AZ的IP（当开启跨AZ负载均衡时），但很多轻量DNS客户端只会返回/使用第一个解析到的IP，这也让你误以为只有DNS返回的IP是“活跃”的。

如果你的三个AZ都配置了健康的后端实例，但还是只有一个IP能连，那可能要检查VPC路由表（对应AZ的子网路由是否指向NLB的ENI）或者安全组规则（是否放行对应IP的流量）。

针对Legacy应用的AWS原生解决方案（获取稳定私有IP） #

因为你的应用无法使用DNS解析，需要单一的静态私有IP，这里有两个最适合的AWS原生方案：

1. 使用AWS Global Accelerator（内部端点）

这是最省心的托管方案，不需要你维护任何基础设施：

• Global Accelerator可以为你的私有NLB分配静态内部IP地址，这些IP不会随着NLB的ENI轮换或IP变更而改变。
• 你只需要将Global Accelerator的终端节点指向你的NLB，Legacy应用直接连接这个静态私有IP即可，Global Accelerator会自动将流量转发到NLB的健康节点，即使NLB的内部IP发生变化也不会影响连接。
• 它还自带跨AZ故障转移能力，能自动避开不健康的AZ，保证高可用性。

2. 用EC2实例作为反向代理（带静态私有IP）

如果你不想使用Global Accelerator，这个方案更轻量化（但需要你维护EC2实例）：

• 启动一个EC2实例（建议放在有健康后端的AZ，或者用Auto Scaling Group保证高可用），给它分配一个弹性私有IP（EIP for VPC）——这个IP是静态的，不会随实例重启或更换而改变。
• 在EC2上配置反向代理服务（比如Nginx、HAProxy），将流量转发到你的NLB的DNS名称（这样代理会自动解析NLB的最新IP，不需要你手动更新）。
• 让Legacy应用直接连接EC2的静态私有IP，代理会把流量转发到NLB，实现IP的稳定性。

内容来源于stack exchange