Networking & Content Delivery
Simplify ALB’s public IP address assignment with VPC IPAM
Application Load Balancer (ALB) operates at layer-7 of the OSI model and allows you to load balance HTTP and HTTPS requests to its backend targets. In March 2025, we launched ALB and HAQM VPC IP Address Manager (IPAM) integration that allows you to use predictable IP address blocks for your internet-facing ALBs. This feature helps you reduce public IPv4 address costs by using Bring Your Own IP (BYOIP) addresses, and maintain consistent IP allowlists (with either BYOIPv4 or with HAQM provided contiguous prefixes) for your internet-facing ALBs with external partners or customers.
In this post, we discuss the basics and considerations for using this feature, and how to set it up using AWS Management Console and APIs.
Prerequisites
In the following sections, we assume that you are familiar with the fundamentals of ALB, such as provisioning an ALB, creating listeners, and associating target-groups. You can find more information about ALB in the documentation, and you can check out demos on the Elastic Load Balancer (ELB) demos page.
We also assume that you’re familiar with AWS networking services, such as HAQM Virtual Private Clouds (HAQM VPCs), subnets, VPC routing tables, and VPC IPAM.
Why are deterministic IP addresses needed for ALB?
An internet-facing ALB routes requests from clients over the internet, and forwards those requests to backend targets. An internet-facing ALB associates public IP addresses with its Elastic Network Interfaces (ENIs). Before the launch of this feature, an internet-facing ALB derived its public IP addresses randomly from HAQM owned regional public IP address blocks. As a result, customers couldn’t use predictable IP addresses on their internet-facing ALBs.
ALB’s integration with IPAM allows you to use predictable public IP addresses on your internet-facing ALB, which helps with maintaining allowlists with external partners or clients. This feature also works with BYOIP addresses. HAQM provided public IP addresses have an hourly cost, thus you can save on the public IP usage cost when you use BYOIP address blocks for your ALBs.
When you use this feature, your ALB can be dual-stack with both IPv4 and IPv6 addresses. You can use ALB and IPAM integration for getting deterministic public IPv4 addresses, and the IPv6 addresses are provided from an HAQM owned regional IPv6 address block. This is because BYOIPv6 addresses aren’t supported on ALB at the time of writing.
DNS for internet-facing ALB
In this section, we discuss how DNS works for an internet-facing ALB. We build on this information as we discuss ALB’s IPAM integration in the following sections.
Clients use DNS to access applications hosted behind an internet-facing ALB. Each internet-facing ALB gets a Fully Qualified Domain Name (FQDN). AWS automatically updates the FQDN with the ALB’s public IP addresses, regardless of whether the public IP addresses are provided by HAQM, or BYOIP addresses. Figure 1 shows the interaction between ALB and HAQM Route 53.
ALB and VPC IPAM integration
You must use VPC IPAM to provide predictable IP addresses on your internet-facing ALB. To achieve this, you first need to create a Regional IPAM Pool with the IP address block, and then configure the ALB to fetch its public IP addresses from the IPAM Pool. Figure 2 shows the relationship between internet-facing ALB, VPC IPAM, and DNS.
- Create ALB API call references a VPC IPAM pool to get public IP addresses. In this example, the ALB is created in three Availability Zones (AZs).
- ALB tries to get public IP addresses for its ENI in availability-zone-1 from the VPC IPAM Pool.
- VPC IPAM Pool includes 192.0.2.144/29 CIDR, and the pool has available IP addresses. IPAM allocates the next available IP address (192.0.2.144) for ALB’s ENI in availability-zone-1.
- VPC IPAM marks this IP addresses as ‘in use’.
- VPC IPAM provides the allocated IP address to the ALB. ALB’s ENI in availability-zone-1 gets this IP address.
- Route 53 adds the allocated IP address to the ALB’s FQDN.
This process repeats for each of the ALB’s ENIs, and each of the ALB’s ENIs gets a public IP address from the VPC IPAM Pool.
In case your IPAM Pool does not have enough available IP addresses for all of the ALB’s ENIs, the ALB first reaches out to VPC IPAM to get the IP addresses. VPC IPAM provides as many IP addresses as it can, and HAQM owned regional public IP pool provides the remainder of the IP addresses. Figure 3 shows this scenario.
- The IPAM Pool (192.0.2.144/29) has a total of eight IP addresses, and six are already in use before the ALB is created.
- Create ALB API call references the VPC IPAM Pool to get public IP addresses. The ALB is created in three AZs.
- VPC IPAM Pool provides public IP addresses for ALB’s ENIs in availability-zone-1 and availability-zone-2. At this point, all eight IP addresses within the IPAM pool are in use.
- The ALB’s ENI in availability-zone-3 requests a public IP address from VPC IPAM.
- VPC IPAM Pool doesn’t have any available IP addresses.
- , 7. HAQM owned regional pool of public IP addresses provide the next available IP address for ALB’s ENI in availability-zone-3.
This mechanism of falling back on HAQM owned public IP addresses makes sure of availability for ALB in the case that the VPC IPAM Pool doesn’t have sufficient IP addresses available. However, this can make it difficult to provide deterministic IP allowlists for your internet-facing ALBs. To alleviate this, we recommend using the VPC IPAM pool’s PercentAvailable CloudWatch metric to alert if the percentage of available IP addresses falls below a specific threshold. As an action, you can provision more CIDRs in the IPAM Pool and provide the newly provisioned CIDRs to your customers or partners for the allowlisting use-case.
How does this feature work with ALB scaling?
An ALB consists of a fleet of ALB-nodes in the background. Under default settings, the ALB provisions one node in each AZ, and an internet-facing ALB needs a private and a public IP address for each ALB-node. ALBs can scale up or down appropriately based on the traffic and load. When an ALB scales, existing nodes may be replaced with different sized ALB-nodes, or new ALB-nodes may be added.
In case an internet-facing ALB scales out and adds new nodes, it follows the same process outlined in Figure 2 for getting public IP addresses from a VPC IPAM Pool. In case the VPC IPAM Pool doesn’t have sufficient IP addresses, the HAQM owned regional public IP pool provides IP addresses for the ALB scale out use case, as shown in Figure 3.
Setup
This section shows how to use deterministic IP addresses for a new ALB.
Step 1: Bring IP prefixes into VPC IPAM pool
The first step is to configure CIDRs in a VPC IPAM Pool. You can either use HAQM provided public IP addresses or BYOIPv4 CIDRs into the IPAM Pool. Refer to documentation for more details on how to set it up in VPC IPAM. The locale of the VPC IPAM Pool must be the AWS Region where you want to create the ALB.
Verify that the CIDRs are in the provisioned state in the IPAM Pool.
Step 2: Create internet-facing ALB and configure it to get IP addresses from the VPC IPAM Pool.
Choose the Use IPAM Pool for public IPv4 addresses option at the time of creating the internet-facing ALB.
Alternatively, you can use the following API call while creating the internet-facing ALB:
aws elbv2 create-load-balancer \
--type application \
--name <ALB name> \
--ip-address-type ipv4 \
--subnets <list of subnets separated by space> \
--scheme internet-facing \
--ipam-pools Ipv4IpamPoolId=<VPC IPAM pool id>
Step 3: Verification
You can see details of the IPAM Pool that provided public IPv4 addresses in the Network mapping tab of the ALB, as shown in the following figure.
Migrating an existing internet-facing ALB to use VPC IPAM provided addresses
In this section, we discuss the steps and considerations if you’d like to use VPC IPAM Pool provided public IPv4 addresses for your existing internet-facing ALB.
On the network mapping tab of an existing ALB, choose Edit IP Pools.
On the next screen, choose Use IPAM Pool for public IPv4 address, and then choose the IPAM Pool from the drop down list:
You can also use this API call to use VPC IPAM Pool provided public IPv4 addresses for an existing internet-facing ALB:
aws elbv2 modify-ip-pools \
--load-balancer-arn <ARN of the ALB> \
--ipam-pools Ipv4IpamPoolId=<VPC IPAM Pool ID>
When you change the IP Pool for an existing internet-facing ALB, the ALB creates new ENIs and use VPC IPAM Pool provided IPv4 addresses for the new interfaces. The new ENIs also consume one IP address each from the private subnet’s CIDRs. Therefore, we recommend you monitor your private subnet’s IP address usage and make sure that there are enough private IP addresses available to account for the ALBs’ new ENIs that are created. You can use VPC IPAM’s SubnetIPUsage CloudWatch metric to monitor your subnet’s IP address usage. Refer to the VPC IPAM CloudWatch metrics page for more details.
After migrating an existing internet-facing ALB to use VPC IPAM Pool for public IP addresses, the ALB’s FQDN resolves only to the IPAM Pool provided IP addresses. However, the ALB keeps any existing connections open until the ALB’s configured HTTP keepalive duration. Refer to this HAQM Networking post for details on how you can work with HTTP keepalive timer to gracefully terminate client connections.
When all open connections on the ALB’s non VPC IPAM Pool provided public IP addresses are closed, the ALB deletes the ENIs associated with the previous set of public IPv4 addresses. At this point, you would only see ENIs for ALB’s new IP addresses. This mechanism makes sure that the ALB uses your subnet’s private IP addresses optimally.
The ENIs associated with previous IP addresses are deleted, thus any clients that may have cached DNS responses to the ALB’s previous pubic IPv4 addresses don’t get a response. To alleviate this, we recommend optimizing the TTL setting of your DNS records, or have the client refresh their DNS cache after you migrate your ALB.
Things to know
- The ALB’s deterministic IP address feature works only with internet-facing load balancers.
- You can’t delete any in-use CIDRs from the VPC IPAM Pool after creating an ALB that used IP addresses from the IPAM Pool for its ENIs.
- For a multi-account scenario, you can use VPC IPAM to bring in CIDRs into a central account, and then use AWS Resource Access Manager (AWS RAM) for sharing VPC IPAM Pools across multiple accounts. Review the VPC IPAM documentation for more details.
- You need VPC IPAM advanced tier for managing your IP addressing across multiple accounts. Read the VPC IPAM pricing page for details on the included features in the advanced tier, and the cost information.
Conclusion
In this post, we explained the integration between ALB and HAQM VPC IPAM, and how to use this feature using the Console and APIs. This integration allows you to reduce your HAQM-provided public IPv4 costs by using BYOIPv4 addresses with ALB. This new feature also allows you get contiguous public IPv4 addresses on your internet-facing ALB, which makes it easier to maintain consistent IP allowlists for your internet-facing ALBs with external partners or customers.
To get started, read ALB documentation.
Author bios