Networking & Content Delivery

Accelerate IPv6 application migration with AWS PrivateLink and dual stack Network Load Balancers UDP support

This post was co-authored by: Ashish Kumar, Senior Product Manager; Blayze Stefaniak, Senior Solutions Architect; Natti Swaminathan, Senior Solutions Architect; and Yogesh Patel, Senior Solutions Architect

In this post, we review how you can leverage AWS PrivateLink support for User Datagram Protocol (UDP) services, and accelerate Internet Protocol version 6 (IPv6) migrations with UDP support for dual stack Network Load Balancers (NLBs). We outline the steps to configure the two new features, their use cases, and best practices for integrating both in your existing environments.

With the addition of UDP support, AWS PrivateLink allows you to privately connect your Amazon Virtual Private Cloud (VPC) to UDP-based services exposed through PrivateLink endpoints. These services can be deployed in your AWS environment across multiple VPCs, or shared with your AWS accounts by partners and Software as a Service (SaaS) providers. You can now create VPC Endpoints to access UDP-based VPC Endpoint Services, just like you access Transmission Control Protocol (TCP)-based services.

To help you accelerate your IPv6 adoption, AWS now supports UDP listeners for dual stack NLBs. This allows you to automatically distribute incoming traffic to UDP-based applications, such as real-time gaming, voice over IP (VoIP), and media streaming, to ensure high availability and scalability. Dual stack NLBs allow both IPv4 and IPv6 clients to access your application endpoints, accelerating your IPv6 adoption journey on AWS. With UDP support for dual stack NLBs, you can benefit from the same feature available with TCP listeners, such as health checks, automatic scaling, and transparent upgrades, without the need to maintain custom load balancing solutions.

Prerequisites

In this post, we assume you are familiar with fundamental networking constructs on AWS, such as Amazon VPC, Elastic Load Balancing, NLBs, and AWS PrivateLink, as well as Amazon CloudWatch. We also assume you are familiar with IPv4, IPv6, TCP, and UDP. We don’t focus on defining these services and concepts, but we do use them to show use cases and configuration steps for the two new features. For more IPv6 adoption resources on AWS, refer to the AWS re:Post article Get started with IPv6 on AWS – Resources & Content.

UDP support for dual stack NLBs and AWS PrivateLink

With UDP support for dual stack NLBs, clients can use both IPv4 and IPv6 to connect to your UDP service. To use this feature, you must create an IPv6-type target group for your dual stack NLB UDP listener. The NLB sends UDP traffic to your targets using IPv6.

Clients can directly access dual stack NLBs with UDP listeners, by resolving the associated Fully Qualified Domain Name (FQDN). You can also configure AWS PrivateLink services (VPC Endpoint Services) using dual stack NLBs with UDP listeners. Consumers can create AWS PrivateLink endpoints (VPC Endpoints) in their VPCs, to access the UDP-based services, using IPv4 or IPv6.

Figure 1 is an example architecture of clients using IPv4 or IPv6 to connect to a VPC Endpoint Service over UDP. The NLB is dual stack, and has a UDP lister for the service. The service provider service target group must use IPv6. Consumers have the option to deploy and send traffic to IPv4, IPv6, and dual stack VPC Endpoints. Clients can then connect to the VPC Endpoint to use the UDP-based service.

This figure shows clients connecting over IPv4 and IPv6, the NLB set to dual stack, and the NLB connections to its target group over IPv6.

Figure 1: Network topology diagram depicting IP compatibility of dual stack UDP NLB clients and targets

Source IP address preservation for dual stack NLBs

TCP and TLS listeners

When IPv4 clients directly connect to a dual stack NLB with IPv6 targets, the NLB cannot preserve the original IPv4 address of the client. This is because IPv6 is not backwards compatible with IPv4. IPv6 targets cannot process the IPv4 address of the clients, so the NLB translates the client IPv4 source address to its own IPv6 address, to match the IP version of the targets.

Similarly, when IPv4 and IPv6 clients connect to a VPC Endpoint, the NLB does not preserve the original IP address of the client, regardless of the protocol version. Since the NLB performs IP NAT, you can use AWS PrivateLink regardless of any overlapping IP addresses between consumer and service provider VPCs. As a result of the NAT, the target application is not aware of the client’s original IP address. To let the target application know the original client IP address, you can enable Proxy Protocol version 2 (PPv2) on the target group. This allows the NLB to add the client IP address as a Type-Length-Value (TLV) in the packet header, and can be enabled for both IPv4 and IPv6-type target groups.

UDP and TCP_UDP listeners

UDP is a connectionless protocol, therefore source NAT requires a different implementation to overcome this challenge with UDP support for dual stack NLBs. There are two key differences compared to TCP:

  1. In UDP, unlike TCP, there is no concept of a connection, so ports cannot be used to track sessions through the NLB. Thus, NLB uses IPv6 addresses to uniquely identify each client of a UDP listener.
  2. For TCP traffic, NLB adds the PPv2 header added only to the first packet, when the connection is established. In UDP, there is no session being established, and each packet is viewed as independent. As a result, when PPv2 is enabled on a UDP target group, the NLB adds the PPv2 header to every packet.

Let’s review the configuration steps for UDP listeners on dual stack NLBs, and UDP-based VPC Endpoint Services.

Configuring UDP listeners for dual stack Network Load Balancers

Before you begin, ensure you meet the following prerequisites:

  • Verify your VPC IP Configuration: Confirm your VPC has an associated IPv6 prefix. For more details on configuring IPv6 on your VPC, refer to Add IPv6 support for your VPC in the Amazon VPC User Guide.
  • Verify your subnet IP Configuration: The NLB subnets must be dual stack. The target group subnets can be dual stack or IPv6-only.
  • Verify your Amazon Elastic Compute Cloud (Amazon EC2) instance configuration: Each instance must have a primary IPv6 address configured. For details on configuring primary IPv6 addresses, refer to Manage the IP addresses for your network interface in the Amazon EC2 User Guide.
  • Create security group ingress rules for your NLB and targets: Your security group ingress rules must allow UDP on the port(s) your NLB UDP listener and your targets are configured to receive traffic on.
  • Ensure your application allows IPv6 traffic: Confirm your application can process IPv6 traffic, and uses a socket library supporting IPv6.

The following steps show how you can configure a UDP listener for new and existing dual stack NLBs:

Step 1 (Optional): Modify your existing NLB to use dual stack and source NAT

To change the IP address type to dual stack, you must delete existing UDP and TCP_UDP listeners, and ensure the NLB subnets are dual stack, as shown in Figure 2:

This figure is an AWS management console screenshot which states the requirements for an IP address type change. It says, "All of the following must be true before changing your load balancer- to Dualstack. First, any existing UDP or TCP_UDP listeners must be deleted. After switching to Dualstack you will be able to configure IPv6-compatible UDP and TCP_UDP listeners. Second, the VPC subnets within the network mapping must include an IPv6 CIDR.

Figure 2: Requirements before changing the IP address type for an NLB

To update the IP address type of an existing NLB, navigate to Load Balancers in the Amazon EC2 console and select your NLB. Choose Actions, then Edit IP address type, as shown in Figure 3:

This figure is an AWS management console screenshot that shows choosing a load balancer, selecting "Actions", and then choosing "Edit IP address type".

Figure 3: Edit the IP address type for an NLB

When you modify the NLB and change the Load balancer IP address type to Dualstack, set Enable prefix for IPv6 source NAT to On (source NAT prefixes per subnet), choose your subnet(s), and assign a source NAT IPv6 address. An example is shown in Figure 4:

This figure is an AWS management console screenshot which shows the modifications to make to your load balancer. You choose dual stack, turning the prefix for IPv6 source NAT on, and assigning IPv6 addresses for the source NAT capability through auto-assignment.

Figure 4: Change to dual stack, enable source NAT, and set the IPv6 address range

Step 2: Create a new dual stack UDP NLB

To create a new dual stack NLB with a UDP listener, navigate to Load Balancers in the Amazon EC2 console and choose Create Load Balancer. Select Network Load Balancer and choose Create. Under Basic configuration, give your NLB a unique name and choose the scheme (Internal or Internet-facing). For Load balancer IP address type, choose Dualstack. An example is shown in Figure 5:

This figure is an AWS management console screenshot of creating a new dual stack NLB. The name is an arbitrary name you define. The scheme we selected is Internal rather than Internet-facing, and the IP address type is set to dual stack.

Figure 5: NLB basic configuration

Step 3: Configure your NLB subnets and source NAT configuration

Choose the VPC where your NLB will be deployed, as shown in Figure 6:

This figure is an AWS management console screenshot of selecting our VPC under the Network Mapping section.

Figure 6: Choose the VPC for your NLB

Set Enable prefix for IPv6 source NAT to On, as shown in Figure 7:

This figure is an AWS management console screenshot which specifies to set the "Enable prefix for IPv6 Source NAT" option to "On".

Figure 7: Enable prefix for IPv6 source NAT

Choose your Source NAT IPv6 prefix assignment method, as shown in Figure 8:

This figure is an AWS management console screenshot which shows that you can select to set the Source NAT IPv6 prefix to be auto assigned or a custom IPv6 CIDR that you specify. We chose the auto-assign option.

Figure 8: Source NAT IPv6 prefix option

Choose your Availability Zone mappings, subnets, and security group(s) for your NLB, review your configuration, and choose Create load balancer.

Step 4: Register your Amazon EC2 instances as targets

In the prerequisites section, we mentioned to register you IPv6 targets to have a primary IPv6 address. This is required to allow you to register these targets with your target group, as shown in Figure 9:

This figure is an AWS management console screenshot which shows your target group's targets and the ability to select the "Register targets" button to add more targets.

Figure 9: Registering targets to your target group

Step 5: Configure a UDP listener

You must configure your listener Protocol to either UDP or TCP_UDP and choose your listener Port. For this example, we chose UDP and port 53. Your target group must have its IP address type value set to IPv6. To check the IP address type of your target group, refer to Target groups in the Amazon EC2 console. The IP address type of a target group cannot be modified after creation. Figure 10 shows the UDP listener configuration for our example IPv6 target group:

This figure is an AWS management console screenshot which shows that the listeners and routing section is completed by specifying a protocol, port, and default action. In this example, we specify UDP as the protocol, 53 as the port, and a default action to forward traffic to our target group.

Figure 10: Listeners and routing for NLB

If you are using AWS PrivateLink, then continue with the following steps.

Create a dual stack UDP AWS PrivateLink service

Create an AWS PrivateLink service (service owner side)

If you are a service provider, you can now share UDP services to your consumers using AWS PrivateLink. Service providers can be teams within your organization, partners such as Independent Software Vendors (ISVs), and other affiliated organizations such as regulators.

There is only one step to create your VPC Endpoint Service. Navigate to Endpoint Services in the Amazon VPC console and choose Create endpoint service, as shown in Figure 11:

This figure is an AWS management console screenshot of the VPC endpoint services page. There are currently no endpoint services listed. There is a button for "Create endpoint service" which is highlighted.

Figure 11: Create your VPC Endpoint Service

Configure the following options, as shown in Figure 12:

  • (Optional) Give your endpoint service a Name.
  • Choose your Load balancer type to be Network.
  • Choose the NLB with UDP listeners you previously configured.
  • (Optional) Choose Acceptance required. For more information about this setting, refer to Accept and reject endpoint connection requests in the AWS PrivateLink User Guide.
  • (Optional) Enable a private DNS name. For more information about private DNS names for your endpoint services, refer to Manage DNS names for VPC Endpoint Services in the AWS PrivateLink User Guide.
  • Choose the IP address types you want your VPC Endpoint Service to serve. For this example, we provide IPv4 and IPv6 so clients can create IPv4, IPv6, and dual stack VPC Endpoints.
  • (Optional) Set Tag(s) for the endpoint service.
This figure is an AWS management console screenshot of the configuration when creating a VPC endpoint service. In this example, we provide an arbitrary name, select our UDP NLB, choose "Acceptance required", choose to support both IPv4 and IPv6 address types, and provide a Name tag.

Figure 12: VPC Endpoint Service configuration options

Create a UDP AWS PrivateLink endpoint (consumer side)

To access an AWS PrivateLink service, you must create VPC Endpoints in consumer VPCs. This section assumes you followed the network configuration steps in the configuration prerequisites section of this post.

Step 1: Identify the IP version supported by the service provider

To enable IPv6 on your VPC Endpoint, the service must have IPv6 as a SupportedIpAddressType. You can verify whether a service supports IPv6 by running the following command. In the response, the SupportedIpAddressTypes provides the IP version(s) enabled on the VPC Endpoint Service.

aws ec2 describe-vpc-endpoint-services \
  --service-names <service-name>

Step 2: Create an AWS PrivateLink endpoint

To create a VPC Endpoint, configure the following settings, as shown in Figure 13:

  • (Optional) Give your VPC Endpoint a Name tag.
  • Choose the appropriate VPC Endpoint Service as the Service name.
  • Choose the VPC where you want to deploy this VPC Endpoint. You can choose to configure an IPv4, dual stack, or IPv6 endpoint. This depends on the VPC Endpoint Service SupportedIpAddressTypes values and your client capabilities.
  • (Optional) Under Additional settings you can enable private DNS name resolution. For more information about this setting, refer to Enable private DNS names in the AWS PrivateLink User Guide.
  • Choose the subnets and security group(s) for your VPC Endpoint.
This figure is an AWS management console screenshot of the VPC endpoint settings when creating a PrivateLink endpoint. In this example, we choose an arbitrary Name tag. We choose a "Service category" of "Other endpoint services". We provide the service name which begins "com.amazonaws.vpce", followed by the region ID "us-west-2", followed by "vpce-svc", and then followed by a unique ID string. There is a button to "Verify service" and the service name is verified. Then, we choose our VPC, subnets, and IP address type of IPv6 for our endpoints. We also choose a security group for the endpoints.

Figure 13: Create your VPC Endpoint

Newly created endpoint connections need to be accepted by the AWS PrivateLink service provider if acceptance is required for the VPC Endpoint Service.

Monitor your UDP-based services with Amazon CloudWatch

After you complete this configuration, consumers can send traffic to their UDP-based services. Service owners can monitor the health and performance with Amazon CloudWatch metrics such as:

  • NewConnectionCount: Measures the number of new UDP flows through the NLB.
  • PacketsOutToTarget: Measures the number of UDP packets sent from the NLB to the registered targets.
  • HealthyHostCount: Measures the number of healthy targets in the target group.

These CloudWatch metrics can help you ensure your UDP-based services are serving traffic as expected, and identify any potential issues. For more information, refer to CloudWatch metrics for AWS PrivateLink in the AWS PrivateLink User Guide.

Considerations

Dual stack UDP NLBs retain existing functionality. They support one VPC Endpoint Service with many NLBs. This includes the ability to send traffic to on-premises targets. VPC Endpoint Services serving dual stack NLBs with UDP listeners support endpoint policies, private DNS names, and security groups. AWS PrivateLink throughput, service quotas, and source IP preservation remain unchanged with the release of UDP support.

Conclusion

In this post, we reviewed how you can leverage AWS PrivateLink support for UDP services, and how you can accelerate IPv6 migrations with UDP support for dual stack NLBs. We outlined the steps to configure the two new features, their use cases, and best practices for integrating both in your existing environments. These features help you accelerate your IPv6 adoption and migration of UDP-based services to AWS, and automatically distribute incoming traffic to UDP-based applications, such as real-time gaming, voice over IP (VoIP), and media streaming. With UDP support for dual stack NLBs, you can benefit from the same feature available with TCP listeners, such as health checks, automatic scaling, and transparent upgrades, without the need to maintain custom load balancing solutions.

Get started with AWS PrivateLink using the Endpoint Services and Endpoints options in the VPC console. For more information, refer to the AWS PrivateLink and VPC Endpoints User Guides.

About the authors

Photo of Ashish KumarAshish Kumar is a Senior Product Manager Tech at AWS, based out of the San Francisco Bay Area. He manages cloud services in Amazon VPC related to private networking, data security, and data privacy. Ashish holds a Bachelor’s from the Indian Institute of Technology Guwahati, and an MBA + Master’s in Business Analytics from the University of Notre Dame.

Photo of Blayze StefaniakBlayze Stefaniak is a Senior Solutions Architect on the U.S. Federal Civilian team at AWS. He has experience bringing ambitious ideas to reality across a variety of stakeholder groups and industries. He is passionate about breaking down complex challenges into something practical, actionable, and prioritized. In his spare time, you can find Blayze singing about dinosaurs with his daughter; her favorite dinosaur at the time of publication is a carnotaurus.

Photo of Natti SwaminathanNatti Swaminathan is a Senior Solutions Architect on the U.S. Federal Civilian team at AWS. He works closely with customers to build and architect mission critical solutions. Natti has extensive experience leading, architecting, and implementing high-impact technology solutions that address diverse business needs. He has a Master’s in electrical and computer engineering from Wichita State University and an MBA from North Carolina State.

Photo of Yogesh PatelYogesh Patel is a Senior Solutions Architect at AWS, where he supports U.S. Federal customers and partners. With extensive experience in cloud migration and modernization, Yogesh helps organizations navigate the complexities of cloud adoption. He specializes in architecting solutions that drive digital transformation, empowering customers and partners to innovate.