A partner will only send traffic to IP addresses on their firewall allowlist, but your endpoint currently sits behind an AWS Application Load Balancer. How does moving to a Network Load Balancer solve this, and exactly what would the partner allowlist?

## Why the ALB has nothing to allowlist An Application Load Balancer is reached through a DNS name such as `my-alb-123456.eu-west-1.elb.amazonaws.com`. Behind that name sit load-balancer nodes whose addresses come from the AWS pool. As traffic grows and shrinks, AWS adds and removes nodes and the resolved set changes. Nothing about those addresses is contractual. Allowlisting them works for a day and then silently breaks — the worst possible failure mode, because it looks like an intermittent network problem months later. ## What an NLB provides instead When you create a Network Load Balancer you choose the subnets it operates in — one per Availability Zone. For each of those subnets the NLB takes exactly one IP address, and you have a choice: - let AWS assign it (a public address for an internet-facing NLB, or a private address from the subnet for an internal one), or - supply your own **Elastic IP** allocation in the subnet mapping. Those addresses do not rotate as the load balancer scales. That stability is the entire point: it is what turns "our partner needs an allowlist" from a blocker into a ticket. ```bash aws elbv2 create-load-balancer \ --name partner-edge-nlb --type network --scheme internet-facing \ --subnet-mappings \ SubnetId=subnet-0a1b2c3d,AllocationId=eipalloc-0aaa1111 \ SubnetId=subnet-0e4f5a6b,AllocationId=eipalloc-0bbb2222 ``` The reason to bring your own Elastic IPs rather than accept AWS-assigned addresses is ownership of the address itself: an Elastic IP you allocated stays yours across a rebuild of the load balancer, so a future migration does not require the partner to re-run their change-control process. AWS-assigned NLB addresses are stable for the life of *that* load balancer, and a new load balancer gets new ones. ## What the partner actually allowlists All of the addresses, one per enabled AZ. This is the mistake teams make: someone resolves the NLB's DNS name once, sees a single address, sends that one address to the partner, and the integration works — until a client resolves a different AZ's address and is dropped by the firewall. The NLB's DNS name returns the addresses of the enabled zones, so any of them can be the one a given client uses. Direction matters too, and it is worth stating explicitly in an interview because it is the most common misunderstanding of the whole question. The NLB's addresses are what the partner sees when *they* connect *to you*. They are not the source addresses of connections your workload initiates outbound — outbound traffic from instances in private subnets leaves via a NAT gateway and carries the NAT gateway's Elastic IP, and that is a different address to allowlist for a different direction. If the partner needs to allowlist your outbound calls, you are talking about NAT gateway addresses, not load balancer addresses. ## Alternatives worth naming If you need the ALB's layer-7 features and a stable address, you have two clean options: 1. **NLB in front of the ALB.** Register the ALB as a target of the NLB. The Elastic IPs live on the NLB; host and path routing and WAF stay on the ALB. 2. **AWS Global Accelerator.** It fronts ALBs, NLBs, EC2 instances and Elastic IPs with two static anycast IP addresses and routes traffic over the AWS backbone from the nearest edge location. This also gives you a fixed pair of addresses without a second load balancer in your VPC, and it changes the latency profile for distant clients. ## The judgment being tested The interviewer is checking whether you know that an address requirement is a real architectural constraint rather than a configuration detail, and whether you understand which AWS component owns each address in the path: NLB addresses for inbound, NAT gateway addresses for outbound, and CloudFront or Global Accelerator when the answer needs to be an anycast edge rather than a regional endpoint.