Introducing dual-stack without public IPv4 Application Load Balancer

In May 2024, Amazon Web Services (AWS) launched a new feature for internet-facing Application Load Balancers. This enhancement allows you to provision an internet-facing Application Load Balancer without needing public IPv4 addresses, enabling clients to connect using only IPv6 addresses. To connect, clients resolve the AAAA DNS records assigned to the Application Load Balancer. The Application Load Balancer is still dual-stack and can use private IPv4 addresses for communication between the load balancer and targets. With this capability, you have the flexibility to use both IPv4 and IPv6 for your application targets while avoiding public IPv4 charges for workloads that don’t require it.

Before diving into the feature, let’s review the IP address types supported by Application Load Balancer:

ipv4:

Clients must connect to the load balancer using IPv4 addresses (for example, 192.0.2.1).

dualstack:

Clients can connect to the load balancer using both IPv4 addresses (for example, 192.0.2.1) and IPv6 addresses (for example, 2001:db8:85a3::8a2e:0370:7334).

dualstack-without-public-ipv4:

Clients must connect to the load balancer using IPv6 addresses (for example, 2001:db8:85a3::8a2e:0370:7334).

How does the feature work?

As shown in Figure 1, an Application Load Balancer has been created in two dual-stack subnets. These subnets have a default IPv6 (::/0) route pointing towards an internet gateway. The Application Load Balancer provides an IPv6 address that the client can connect to over the internet, then can use private IP addresses to communicate with the targets. You can then create a AAAA alias record pointing towards the Application Load Balancer in an Amazon Route 53 public hosted zone for users of your application to use.

Figure 1: Dual-stack without public IPv4 Application Load Balancer

Let’s take a look at how to configure this feature using either AWS Command Line Interface (AWS CLI) or the AWS Management Console.

Configure the feature using AWS CLI

Use the create-load-balancer command to create a dual-stack load balancer. As with any Application Load Balancer, you must specify two subnets in different Availability Zones, and you will need to create a security group prior to creating the Application Load Balancer because the create command references it.

aws elbv2 create-load-balancer \
--name Dualstack-without-PublicIPv4-ALB \  
--subnets subnet-05ba35492f49ebf96 subnet-07f835be0c4841904 \ 
--security-groups sg-008c280444b05d751 \ 
--ip-address-type dualstack-without-public-ipv4
{
    "LoadBalancers": [
{
            "LoadBalancerArn": "arn:aws:elasticloadbalancing:us-east-1: 777788889999:loadbalancer/app/Dualstack-without-PublicIPv4-ALB/c32fa99f5dd20f18",
            "DNSName": "Dualstack-without-PublicIPv4-ALB-949941269.us-east-1.elb.amazonaws.com",
            "CanonicalHostedZoneId": "Z35SXDOTRQ7X7K",
            "CreatedTime": "2024-05-24T21:00:48.880000+00:00",
            "LoadBalancerName": "Dualstack-without-PublicIPv4-ALB",
            "Scheme": "internet-facing",
            "VpcId": "vpc-03d1bfe794747c9d8",
            "State": {
                "Code": "provisioning"
            },
            "Type": "application",
            "AvailabilityZones": [
                {
                    "ZoneName": "us-east-1a",
                    "SubnetId": "subnet-05ba35492f49ebf96",
                    "LoadBalancerAddresses": []
                },
                {
                    "ZoneName": "us-east-1d",
                    "SubnetId": "subnet-07f835be0c4841904",
                    "LoadBalancerAddresses": []
                }
            ],
            "SecurityGroups": [
                "sg-008c280444b05d751"
            ],
            "IpAddressType": "dualstack-without-public-ipv4"
        }
    ]
}

For creating things like target groups or listeners, follow this documentation: Tutorial: Create an Application Load Balancer using the AWS CLI.

Configure the feature using the AWS console

Create a new Application Load Balancer by opening up the Amazon EC2 console (in the same region) then going to load balancers section and then clicking on Create load balancer, as shown in Figure 2.

Figure 2: Create a load balancer

Next, as shown in Figure 3 enter a name for the load balancer and Select an internet-facing as the sceme and dualstack without public IPv4 as the IP address type.

Figure 3: Select the IP address type

Select the virtual private cloud (VPC), subnets, and the security group and target group, as shown in Figure 4.

Figure 4: Load balancer settings

You are required to have a target group and a listener. For more details on how to configure this, refer to how to configure a target group and listener.

Verifications

Verify that the new Application Load Balancer was created with only an AAAA DNS name, as shown in Figure 5.

Figure 5: Dualstack without public IPv4 Application Load Balancer

In the Network mapping tab, the Application Load Balancer is provisioned without any public IPv4 addresses, as can be seen in Figure 6. The Application Load Balancer still creates private IPv4 addresses for it to use to communicate with the targets.

Figure 6: Dualstack without public IPv4 Application Load Balancer

You can verify using nslookup or dig that the Application Load Balancer returns only IPv6 addresses:

$ nslookup Dualstack-without-PublicIPv4-ALB-368593218.us-east-2.elb.amazonaws.com
Server:         10.1.0.2
Address:        10.1.0.2#53
 
Non-authoritative answer:
Name:   Dualstack-without-PublicIPv4-ALB-368593218.us-east-2.elb.amazonaws.com
Address: 2001:db8:1063:f105:de70:b404:2fd8:f27f
Name:   Dualstack-without-PublicIPv4-ALB-368593218.us-east-2.elb.amazonaws.com
Address: 2001:db8:1063:f106:5a41:2957:4350:50c3
 
$ dig Dualstack-without-PublicIPv4-ALB-368593218.us-east-2.elb.amazonaws.com AAAA +short
2001:db8:1063:f106:5a41:2957:4350:50c3
2001:db8:1063:f105:de70:b404:2fd8:f27f
$

Test the connectivity to the Application Load Balancer:

# curl -6 http://Dualstack-without-PublicIPv4-ALB-368593218.us-east-2.elb.amazonaws.com
<html><body><h1>It works!</h1></body></html>
#

Primary use cases and customers

The following use cases are examples of customers that can use this feature.

• Your clients can communicate with Application Load Balancer on an IPv6 network. These clients can resolve IPv6 DNS and connect to Application Load Balancer IPv6 endpoints. If you require public IPv4 connectivity, you must keep using dual-stack Application Load Balancers.
• You use a content delivery network (CDN) that supports IPv6 endpoints as an origin can enable this feature. Enabling dual-stack with IPv4 disabled for this use case eliminates the public IPv4 costs with Application Load Balancer.

How to migrate

If you are currently using Application Load Balancer as IPv4 only, we recommend you switch to dual-stack first. This will give you more confidence before switching to dual-stack without IPv4 because it is a more gradual change.

You should then test whether all the IPv6 infrastructure, specifically Application Load Balancer, internet gateway, and route tables are correctly set up. Ensure that all clients get the Application Load Balancers IPv6 addresses by nslookup or dig, and the clients can successfully connect to IPv6 Application Load Balancer endpoint using the curl -6 command. After confirmation that all clients can successfully connect through IPv6 Application Load Balancer endpoints (Application Load Balancer access logs can help here), you can use Option 2 to switch address type to dual-stack with IPv4 disabled to gracefully switch traffic to IPv6 endpoints.

Option 1: Migrate to the newly created dual-stack without public IPv4 Application Load Balancer

For this option, you create two separate but identical environments. One environment is running the current application version (dual-stack or IPv4 Application Load Balancer), and the other environment is running the new application version (dual-stack without public IPv4). Verify that clients, upon performing nslookup or dig, get the Application Load Balancers IPv6 addresses only, and the clients can successfully complete the request to IPv6 Application Load Balancer endpoint using the curl -6 command. You can reference the white paper on deployment strategies for more details.

Using this approach increases application availability and reduces deployment risk by simplifying the rollback process if a deployment fails. Once testing has been completed on the new environment, live application traffic is directed to the new environment, and the old environment is deprecated.

In this case, you can create a new deployment for dual-stack Application Load Balancer with no IPv4 address using the steps outlined earlier in Configure the feature section and after thorough testing, failover the traffic to the new deployment.

Option 2: Dual-stack to dual-stack without public IPv4

1. Modify the HTTP client keepalive duration for Application Load Balancer to 60 seconds to gracefully terminate the client connections. This setting is found under the Attributes tab of the Application Load Balancer in the console, and it defaults to 3,600 seconds.
2. Modify your dual-stack internet-facing Application Load Balancer by choosing Actions and selecting Edit IP address type. In Basic configuration select the Dualstack without public IPv4.
3. Verify the Application Load Balancer details show the AAAA record in the DNS name instead of the A record and AAAA record displayed earlier.
4. Modify the HTTP client keepalive duration for Application Load Balancer to the previous value after waiting for at least 1 hour plus the client keepalive time of switching to dual-stack without public IPv4.This is needed to ensure that after the change, Application Load Balancer can drain the IPv4 traffic.
5. This change does not affect the connectivity between the Application Load Balancer and its associated targets. Your application stack requirements remain unchanged when changing to dual-stack without public IPv4. This means the Application Load Balancer target group configuration remains unchanged. If the communication between the Application Load Balancer and targets previously used IPv4, they will remain using IPv4. If the configuration previously used IPv6, they will remain using IPv6.
6. The application clients query for the application DNS name and receive the IPv6 address of the endpoint.
7. The clients open connections to the application endpoint using IPv6.
8. The Application Load Balancer distributes traffic to the healthy targets in the target groups using IPv4/IPv6 connections.

Considerations

Consider the following points when preparing to implement dual-stack without public IPv4 Application Load Balancer:

• Before migrating an Application Load Balancer to dual-stack without public IPv4, verify that you do not have any clients still connecting using public IPv4. You can verify the client details using Application Load Balancer access logs and looking at the client:port field.
• If you’re using external identity provider (IdP) auth along with Application Load Balancer, all communication between Application Load Balancer and the IdP or Cognito endpoints uses IPv4 only. If you use an Application Load Balancer without IPv4, you must configure the Application Load Balancer’s subnet to be able to reach your IdP public endpoint. One option is talked about in our Blog post about using a NAT gateway for IPv6-only workloads connecting to IPv4 services.
• If you use AWS WAF, firewalls, or security services that support IPv6 endpoints as targets can enable this feature. Enabling dual-stack with IPv4 disabled for this use case will eliminate the public IPv4 cost with Application Load Balancer.
• You can set the IP address type (ipv4, dual-stack, or dualstack-without-public-ipv4) for an Application Load Balancer when you create the load balancer and update it at any time. See the Dualstack requirements section for configuration.
• When you change from dual-stack Application Load Balancer to dual-stack-without-public-ipv4, the AAAA DNS name does not change.
• When you change an existing Application Load Balancer to dual-stack-without-public-ipv4, the Application Load Balancer DNS record is updated to reflect only the IPv6 addresses of the existing nodes and no longer returns IPv4 addresses. Although DNS is updated, the public IPv4 address is not immediately removed from existing load balancer nodes. This is done to ensure the IPv4 traffic is drained. The draining period is calculated as client_keep_alive.seconds plus 1 hour. After this time has elapsed, the load balancer network interfaces will no longer have public IPv4 associated. We recommend that you monitor your load balancer during this time to ensure no impact is experienced.

Conclusion

In this post, we introduced the new dual-stack-without-public-ipv4 functionality and explained how to configure the feature and various migration options. This feature allows you to connect to the Application Load Balancer over the internet using IPv6 protocol, in turn avoiding the public IPv4 charges.

There are no additional charges for using this feature. The internet-facing dual-stack-without-public-ipv4 Application Load Balancer is now available in all commercial AWS Regions and the AWS GovCloud (US) Regions.