Why Replace ALB with NLB for Static IP Requirements

Quick Answer

Client whitelisting by IP address requires a genuinely static, predictable IP address at the load balancer layer, and that requirement is where Application Load Balancers fundamentally fall short: ALBs are assigned dynamic IP addresses that can change over time, and there's no way to attach an Elastic IP directly to one, so any client-side IP whitelist configured against an ALB is at risk of breaking whenever the underlying IPs shift. A Network Load Balancer solves this because NLBs do support associating Elastic IP addresses with their nodes, giving you a fixed, known IP address that clients can safely whitelist and that won't change as the underlying infrastructure scales or is replaced. That's why the fix here is to replace the load balancer type entirely rather than trying to work around the ALB's behavior. The other options don't solve the root problem: adding a reverse proxy like Nginx in front of the ALB introduces another layer of complexity while still needing its own static IP to actually solve the whitelisting requirement, and changing the ALB's routing algorithm has no effect on IP address behavior at all, since routing algorithm and IP assignment are unrelated concerns. Whenever a scenario specifically requires a fixed, whitelistable IP address for a load-balanced AWS application, that's a strong signal pointing toward a Network Load Balancer with an Elastic IP rather than an Application Load Balancer.