Introduction

In AWS, whether you can use static public IP addresses depends on the load balancer type. If you need fixed entry-point IPv4 addresses, the usual solution is a Network Load Balancer with Elastic IPs; an Application Load Balancer does not let you attach Elastic IPs directly.

Start with the Load Balancer Type

The first design question is not "how do I assign the IP" but "which load balancer am I using?"

At a high level:

• Application Load Balancer, usually shortened to ALB: no direct Elastic IP attachment
• Network Load Balancer, usually shortened to NLB: supports static IPs through subnet mappings with Elastic IPs
• Classic Load Balancer: older design and usually not the right answer for modern static-IP requirements

This matters because many teams ask for a static IP when they actually mean one of two different things:

• a fixed public address that partners can allowlist
• advanced Layer 7 routing features such as host or path rules

Those goals do not always point to the same AWS service.

The Standard Static-IP Pattern: NLB Plus Elastic IPs

If you truly need fixed public IPv4 addresses, the normal AWS approach is:

1. allocate one Elastic IP for each enabled subnet or Availability Zone
2. create an internet-facing Network Load Balancer
3. attach those Elastic IPs through subnet mappings

Example with the AWS CLI:

1aws elbv2 create-load-balancer \
2  --name my-nlb \
3  --type network \
4  --scheme internet-facing \
5  --subnet-mappings SubnetId=subnet-aaa,AllocationId=eipalloc-111 \
6                    SubnetId=subnet-bbb,AllocationId=eipalloc-222

After that, you add listeners and target groups in the usual way. The fixed addresses come from the Elastic IPs attached to the NLB front end.

Why ALB Is Different

Application Load Balancers are designed around DNS-based entry rather than fixed Elastic IP assignment. That is why you cannot simply take an existing ALB and "pin" an Elastic IP to it.

If you need ALB features such as:

• host-based routing
• path-based routing
• HTTP-aware redirects
• advanced Layer 7 behavior

then an NLB may not be a drop-in replacement.

At that point, common alternatives are:

• use an NLB if Layer 4 behavior is sufficient
• put AWS Global Accelerator in front of the ALB when fixed entry-point IPs are required
• ask the downstream system to allowlist the AWS-managed DNS name instead of fixed IPs, if that policy is acceptable

The important engineering step is to admit that "static IP" and "ALB features" are separate requirements.

One Static IP Per Enabled Subnet

A common surprise is that you usually do not get one universal public IP for the whole load balancer. For an internet-facing NLB, you normally have one static public IPv4 address per enabled subnet or Availability Zone.

Operationally, that means:

• firewall allowlists may need multiple IPs
• high availability and static addressing come together as a set of zonal addresses
• the number of fixed addresses depends on how many subnet mappings you configure

So if a partner says "give us the IP," the accurate AWS answer may be "here are the static IPs," plural.

Infrastructure as Code Example

A Terraform-style configuration makes the same idea explicit:

1resource "aws_eip" "nlb_a" {
2  domain = "vpc"
3}
4
5resource "aws_eip" "nlb_b" {
6  domain = "vpc"
7}
8
9resource "aws_lb" "example" {
10  name               = "example-nlb"
11  load_balancer_type = "network"
12  internal           = false
13
14  subnet_mapping {
15    subnet_id     = aws_subnet.a.id
16    allocation_id = aws_eip.nlb_a.id
17  }
18
19  subnet_mapping {
20    subnet_id     = aws_subnet.b.id
21    allocation_id = aws_eip.nlb_b.id
22  }
23}

The important fields are the subnet_mapping blocks and the Elastic IP allocation IDs.

Common Pitfalls

The most common mistake is assuming an Application Load Balancer can be assigned an Elastic IP directly. It cannot.

Another issue is forgetting that static public IPs on an NLB are usually zonal. If you use multiple Availability Zones, you usually need multiple allowlisted IPs.

People also sometimes solve the wrong problem. If the requirement is really "partner can allowlist a stable endpoint," then Global Accelerator or a different front-door design may fit better than replacing an ALB with an NLB blindly.

Finally, do not confuse the front-end static IP requirement with target registration or private backend IPs. Those are separate layers of the architecture.

Summary

• In AWS, fixed public IPv4 addresses for a load balancer usually mean using a Network Load Balancer with Elastic IPs.
• Application Load Balancers do not support direct Elastic IP attachment.
• Static addresses are configured through NLB subnet mappings, typically one Elastic IP per enabled subnet.
• If you need ALB-style Layer 7 features and fixed public IPs, consider a different front-door design such as Global Accelerator.
• Clarify whether the real requirement is fixed IPs, Layer 7 routing, or both before choosing the load balancer type.