An increasing number of organizations are adopting IPv6 in their environments, driven by the public IPv4 space exhaustion, private IPv4 scarcity, and the need to provide service availability to IPv6-only clients. While undergoing this transformation, customers sometimes find it difficult to assess application behavior in IPv6-enabled environments on AWS. In this blog post, we show how you can leverage Amazon VPC Lattice to adopt IPv6 for your workloads on AWS, and seamlessly migrate from an existing IPv4-only to an IPv6-enabled service architecture.

Prerequisites

AWS has a broad set of services that support IPv6 that allow you to design and deploy IPv6-enabled applications. We assume you are familiar with the Amazon Virtual Private Cloud (VPC) constructs, the available IPv6 architectures and functionalities, and the Amazon VPC Lattice components. Furthermore, we recommend reading the IPv6 on AWS whitepaper, and the Amazon VPC Lattice multi-account multi-VPC architecture blog.

IPv6 adoption considerations

In multi-account and multi-VPC environments, developers manage their workloads independently, so IPv6 adoption can become a distributed process, integrated in each application deployment pipeline. This requires network admins to maintain connectivity between services, for both IPv4 and IPv6 stacks. Additionally, an interoperability layer must be maintained between IPv4 and IPv6, as the two IP stacks are not natively compatible. In consequence, the following traffic flows become critical for a seamless IPv6 adoption:

• IPv4 clients communicating with IPv4 services
• IPv4 clients communicating with IPv6 services
• IPv6 clients communicating with IPv6 services
• IPv6 clients communicating with IPv4 services

Amazon VPC Lattice helps you connect both IPv4 and IPv6 services securely, and monitor communication flows, in a simple and consistent way across various compute types. It provides native interoperability between IP stacks, and can help you create blue-green and canary style roll-outs, to facilitate the gradual IPv6 adoption across services on AWS. For example, you can configure VPC Lattice to send 90% of client traffic to an existing IPv4 deployment, and 10% to a new IPv6 version, to test application code, and analyze its behavior in the new environment.

VPC Lattice also helps you modernize applications, and build IPv6 functionality, independently on the capabilities of service clients, and without impacting reachability. Service clients continue to maintain the same DNS configuration for the application endpoint, and send requests to the service IP addresses on the stack they support. The details on DNS configuration for VPC Lattice services can be found in the documentation.

Let’s explore how you can use VPC Lattice to accommodate for the four connectivity flows required above, and accelerate your IPv6 adoption plans on AWS.

Setup review

Our setup makes use of two applications deployed in two AWS accounts, Account -1 and Account-2, owned by developer teams, and a Network-Admin-Account, as follows:

• App-1 is deployed in a VPC in Account-1, with:
  • App-1 v1.0 running on IPv4 EC2 instances
  • App-1 v2.0 running on IPv6-only EC2 instances
• App-2 is deployed in a VPC in Account-2, with:
  • App-2 v1.0 running on IPv4-only EC2 instances
  • App-2 v2.0 running on dual stack EC2 instances
• Network-Admin-Account hosts the VPC Lattice service network

The following architecture diagram (Figure 1) depicts the setup with Amazon VPC Lattice, and the two applications, deployed in their respective accounts:

Figure 1: App-1 and App-2 deployed in 2 AWS accounts and VPCs, and associated with the Amazon VPC Lattice service network

Before we show how you can integrate v2.0 in each application deployment using VPC Lattice, without impacting connectivity, let’s briefly walkthrough our initial setup. You can use this CloudFormation template published on our GitHub repository to create the base deployment.

Going forward, we assume that you deployed the application VPCs, subnets, EC2 instances, and the VPC Lattice components: service network, App-1 and App-2 VPC Lattice services.

The following console screenshot (Figure 2) shows our service network ipv6-day-service-network, deployed in the Network-Admin-Account. We shared the service network with the application accounts using AWS Resource Access Manager (RAM), and associated it with the two applications VPCs in Account-1 and Account-2:

Figure 2: Amazon VPC Lattice service network ipv6-day-service-network details

For our example, we configured the VPC Lattice service network Auth Policy to allow all client traffic to App-1 and App-2 services. We defined App-1 and App-2 as VPC Lattice services in their respective accounts, and associated them with the service network, as shown in the following console screenshot (Figure 3).

Figure 3: App-1 and App-2 VPC Lattice services associated with the service network

Let’s dive deeper into the initial configuration of our two VPC Lattice services, App-1 and App-2. The following console screenshot (figure 4) shows the listener and routing configuration of App-1 VPC Lattice service:

• Listener Protocol: HTTP
• Listener Port: 80
• Routing: Default rule to forward all client traffic to app-1-ipv4-targets target group, based on an EC2 Autoscaling Group

Figure 4: Amazon VPC Lattice App-1 service configuration

Similarly, App-2 VPC Lattice service is configured as shown in the following console screenshot (Figure 5):

• Listener Protocol: HTTP
• Listener Port: 80
• Routing: Default rule to forward all client traffic to app-2-ipv4-targets target group, based on an EC2 Autoscaling Group

Figure 5: Amazon VPC Lattice App-2 service configuration

IPv4 connectivity verification

Let’s verify initial connectivity. The following terminal screenshot (Figure 6) shows a snippet from an IPv4-only instance part of App-2 IPv4 deployment, as it accesses the App-1 VPC Lattice Fully Qualified Domain Name (FQDN):

Figure 6: An IPv4-only instance part of App-2 IPv4 deployment accesses the App-1 VPC Lattice FQDN

Using Amazon VPC Lattice to seamlessly adopt IPv6 for App-1 and App-2

For our step-by-step adoption process, we first upgrade App-1 to include IPv6 workloads, followed by App-2. Throughout the migration process, we highlight how VPC Lattice accommodates for the previously discussed traffic flows, required in each of the four steps below:

Table 1: Traffic flows during the step-by-step IPv6 adoption process

Let’s dive deeper into our step-by-step process to add IPv6 support for App-1 and App-2.

Step 1: Creating IPv6 VPC Lattice target groups for App-1 and App-2 VPC Lattice services

We first create additional IPv6 target groups that will include the IPv6 EC2 instances deployed in each application VPC. The base template provided in our GitHub repo creates the necessary IPv6 target groups. The following console screenshot (Figure 7) shows the VPC Lattice IPv6 target group for App-1:

Figure 7: VPC Lattice IPv6 target group for App-1

The VPC Lattice IPv6 target group for App-2 is shown in the following console screenshot (Figure 8):

Figure 8: VPC Lattice IPv6 target group for App-2

Note the target groups are not yet associated with a VPC Lattice service, so the “unused” health check status is expected. Also, for the IPv6 targets groups we use IP type targets, instead of EC2 Auto Scaling Groups.

Step-2: Adding IPv6 support for App-1

To add IPv6 functionality to App-1 VPC Lattice service, we update the routing rules for App-1 VPC Lattice listener, and add the IPv6-only target group. We also want to test that App-1’s code supports IPv6, therefore we configure weights associated with each forwarding rule, to ensure a blue/green deployment, as shown in the following console screenshot (Figure 9). App-1 VPC Lattice configuration forwards:

• 90% of incoming client requests to the IPv4-only target group
• 10% of incoming client requests to the IPv6-only target group

Figure 9: App-1 VPC Lattice service configuration with routing rules for IPv4 and IPv6 target groups and associated weights

The following architecture diagram (Figure 10) shows the updated configuration for App-1, while App-2 continues to send all client to its IPv4 only instance:

Figure 10: Architecture after adding IPv6 support to App-1

Step-3: Verifying App-1 IPv6 support and backwards compatibility with App-1 on IPv4

To test the App-1 VPC Lattice blue/green deployment, we access the VPC Lattice provided FQDN for App-1 from one of the IPv4-only instances part of the App-2 deployment. The following terminal screenshot (Figure 11) shows that 10% of requests (1 in 10 requests) are sent to the App-1 IPv6 target group:

Figure 11: Accessing the VPC Lattice provided FQDN for App-1 from one of the App-2 IPv4-only instances;
10% of the client traffic is routed to the IPv6 target group, regardless of the client IP capabilities

App-1 also needs to access App-2, so let’s explore how VPC Lattice ensures backwards compatibility between the new IPv6 App-1 deployment and App-2 IPv4 only version. VPC Lattice services’ FQDNs receive both A and AAAA records to link local IPv4 and IPv6 addresses, respectively. In this case, an App-1 IPv6-only instance will access App-2 via the link local IPv6 address, as shown in the following terminal screenshot (figure 12):

Figure 12: DNS resolution of App-2 VPC Lattice FQDN from an App-1 IPv6-only instance

Connectivity between the IPv6 client instance and IPv4 service is achieved seamlessly using VPC Lattice, as shown in the following terminal snapshot (Figure 13):

Figure 13: App-1 IPv6 only instance accessing App-2 running on IPv4-only instances

Step-4: Adding IPv6 support to App-2

To add IPv6 functionality to App-2 VPC Lattice service, we repeat the actions taken at Step-2. We update the routing rules for App-2 VPC Lattice listener, and add the IPv6-only target group. We also want to test that App-2’s code supports IPv6, therefore we configure weights associated with each forwarding rule, to ensure a blue/green deployment. App-2 VPC Lattice configuration forwards:

• 50% of incoming client requests to the IPv4-only target group,
• 50% of incoming client requests to the IPv6-only target group.

With both the App-1 and App-2 supporting IPv6, let’s review the updated architecture diagram (Figure 14), showing the configured traffic distribution for each application’s IPv4 and IPv6 versions:

Figure 14: Architecture after adding IPv6 to both App-1 and App-2

Step-5: Verifying new IPv6 client to IPv6 service connectivity

To verify the new IPv6 client to IPv6 service connectivity, we access the FQDN of App-2 VPC Lattice service from an IPv6-only instance part of the App-1 deployment, as shown in the following terminal screenshot (figure 15).

Figure 15: Accessing the FQDN of App-2 VPC Lattice service from an IPv6-only instance in the App-1 deployment

Amazon VPC Lattice distributes client traffic to healthy targets, according to the routing rules for the IPv4 and IPv6 target groups, independently from the client IP capabilities. This allows you to modernize your applications, and adopt IPv6 seamlessly, even when your service clients do not yet support IPv6.

Tracking your IPv6 adoption with VPC Lattice access logs

Amazon VPC Lattice allows you to configure logs at the service network level, and also at the individual services level. Let’s explore how you can use this information to track and monitor IPv6 adoption across your environment on AWS. The following console screenshot (Figure 16) shows an Amazon CloudWatch log stream configured to ingest VPC Lattice logs:

Figure 16: Amazon VPC Lattice’s service network access log

The ‘sourceIpPort’ field includes the source IP address and the port of the client that originated the request. You can run Amazon Athena queries on this field, and create custom dashboards using services like Amazon QuickSight or Amazon OpenSearch, to track your IPv6 adoption. The following console snapshot (Figure 17) shows a sample Amazon QuickSight dashboard which highlights the percentage of IPv4 and IPv6 requests for our example service network:

Figure 17: Sample Amazon QuickSight visualization showing percentage of IPv4 and IPv6 requests
through an Amazon VPC Lattice service network

In our sample environment, 56% of all requests use the IPv6 stack, while 44% use the IPv4 stack. You can run similar queries on VPC Lattice logs for your services, and understand IPv6 adoption progress.

Cleanup

In case you used the base template provided in our GitHub repository, please use this CLI command to delete all the resources deployed by the template:
aws cloudformation delete-stack --stack-name lattice-ipv6-stack

You can also manually delete the resources using the AWS console.

Things to know

• When creating a new IP target group in VPC Lattice, you can select the IP address type of your target group as IPv4 or IPv6. This controls the IP version used by VPC Lattice to communicate with targets and perform health checks.
• All targets within a VPC Lattice target group must have the same IP address type. For example, you can’t register an IPv4 target with an IPv6 target group.
• You associate an EC2 Auto Scaling group that contains dual stack EC2 instances with an IPv4 or an IPv6 VPC Lattice target group.

Conclusion

In this blog, we explored how you can use VPC Lattice to seamless provide a blue/green style IPv4 to IPv6 modernization for an application. We used VPC Lattice to provide seamless connectivity for these traffic patterns

• IPv4-clients communicating with IPv4-servers
• IPv4-clients communicating with IPv6-servers
• IPv6-clients communicating with IPv6-servers
• IPv6-clients communicating with IPv4-servers

We also reviewed how you can use VPC Lattice logs to track IPv6 adoption progress. If you have questions about this post, start a new thread on AWS re:Post, or contact AWS Support. For more information about Amazon VPC Lattice, you can refer to the documentation and additional blogs.

About the authors