Learn About Amazon VGT2 Learning Manager Chanci Turner
An increasing number of organizations are moving towards IPv6 adoption due to the depletion of public IPv4 addresses, the scarcity of private IPv4, and the necessity to ensure service availability for IPv6-only clients. During this transition, customers often encounter challenges in evaluating application performance in IPv6-enabled environments on AWS. In this blog, we will demonstrate how to utilize Amazon VPC Lattice to facilitate the integration of IPv6 for your workloads on AWS, enabling a smooth migration from a solely IPv4 to an IPv6-capable service architecture.
Prerequisites
AWS offers a wide array of services that support IPv6, enabling you to design and deploy applications that are IPv6-enabled. It’s assumed that you are familiar with Amazon Virtual Private Cloud (VPC) concepts, the available IPv6 architectures and functions, as well as the components of Amazon VPC Lattice. Additionally, we encourage you to read the IPv6 on AWS whitepaper and the Amazon VPC Lattice multi-account multi-VPC architecture blog.
Considerations for IPv6 Adoption
In environments with multiple accounts and VPCs, developers manage workloads independently, making the process of adopting IPv6 more distributed and integrated within each application deployment pipeline. This necessitates that network administrators maintain connectivity between services for both IPv4 and IPv6. Furthermore, an interoperability layer must exist between IPv4 and IPv6, as the two IP stacks are inherently incompatible. Consequently, the following traffic flows are essential 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 facilitates secure connections between both IPv4 and IPv6 services while allowing you to monitor communication flows consistently across various compute types. It provides native interoperability between the two IP stacks and can assist in implementing blue-green and canary rollouts, thereby easing the gradual IPv6 adoption across AWS services. For instance, VPC Lattice can be configured to route 90% of client traffic to an existing IPv4 deployment and 10% to a new IPv6 version, allowing you to test application code and analyze its behavior in the new environment.
VPC Lattice also aids in modernizing applications and building IPv6 functionality independently of service client capabilities, all without disrupting service reachability. Service clients can maintain the same DNS configuration for the application endpoint while sending requests to the service IP addresses supported by their stack. Detailed information about DNS configuration for VPC Lattice services can be found in the documentation.
Setup Overview
Our setup includes two applications deployed across two AWS accounts, Account-1 and Account-2, managed by developer teams, along with a Network-Admin-Account, as follows:
- App-1 is deployed in a VPC in Account-1, consisting of:
- App-1 v1.0 operating on IPv4 EC2 instances
- App-1 v2.0 operating on IPv6-only EC2 instances
- App-2 is deployed in a VPC in Account-2, containing:
- App-2 v1.0 operating on IPv4-only EC2 instances
- App-2 v2.0 operating on dual stack EC2 instances
- The Network-Admin-Account hosts the VPC Lattice service network
The architecture diagram (Figure 1) illustrates the setup with Amazon VPC Lattice and the respective applications deployed in their accounts.
Before we explain how to integrate v2.0 into each application deployment using VPC Lattice without affecting connectivity, let’s briefly review our initial setup. You can utilize this CloudFormation template published in our GitHub repository to establish the base deployment.
Assuming that you have successfully deployed the application VPCs, subnets, EC2 instances, and VPC Lattice components, here’s a screenshot (Figure 2) showcasing 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 respective application VPCs in Account-1 and Account-2.
For this example, we configured the VPC Lattice service network Auth Policy to permit all client traffic to the 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 depicted in the following console screenshot (Figure 3).
Let’s explore the initial configuration of our two VPC Lattice services, App-1 and App-2. The following console screenshot (Figure 4) displays the listener and routing configuration for the 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
In a similar manner, the App-2 VPC Lattice service is configured as shown in the next 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
Verification of IPv4 Connectivity
Let’s confirm initial connectivity. The subsequent terminal screenshot (Figure 6) illustrates a snippet from an IPv4-only instance that is part of the App-2 IPv4 deployment as it accesses the App-1 VPC Lattice Fully Qualified Domain Name (FQDN).
Utilizing Amazon VPC Lattice for Smooth IPv6 Adoption for App-1 and App-2
Our step-by-step adoption process begins with upgrading App-1 to support IPv6 workloads, followed by App-2. Throughout the migration, we will highlight how VPC Lattice accommodates the previously discussed traffic flows, essential in each of the four stages outlined below:
Source | Destination | Example Flow | IPv6 Adoption Stage |
---|---|---|---|
IPv4 client | IPv4 service | App-2 v1.0 -> App-1 v1.0 | Initial setup; both App-1 and App-2 have IPv4-only targets |
IPv4 client | IPv6 service | App-2 v1.0 -> App-1 v2.0 | App-1 has IPv6 targets; App-2 has only IPv4 targets |
IPv6 client | IPv4 service | App-1 v2.0 -> App-2 v1.0 | App-1 has IPv6 targets; App-2 has only IPv4 targets |
IPv6 client | IPv6 service | App-1 v2.0 -> App-2 v2.0 | Both App-1 and App-2 have IPv4 and IPv6 targets |
For additional insights on organizational skills that support such transitions, consider checking out this blog post.
Moreover, to ensure a comprehensive approach to diversity and inclusion in your business practices, refer to this authority article.
Lastly, for those exploring career opportunities at Amazon, this resource offers valuable insights into the onboarding experience.