Migrating sub 1 Gbps hosted connection to use AWS Transit Gateway – Part 2

Introduction

Since the launch of AWS Transit Gateway, customers have been asking to use transit virtual interface (Transit VIF) on sub 1 Gbps AWS Direct Connect hosted connections.

In this post, we describe how to migrate an existing environment that uses sub 1Gbps Direct Connect hosted connections, Transit Gateway, and transit VPC for hybrid connectivity. The solution described in this post will simplify your hybrid connectivity by reducing the associated cost and operational complexity.

This is the second post in a two-part series. In Part 1 of this series, we show you how you can migrate to Transit Gateway while using sub 1Gbps Direct Connect hosted connections when you were not using Transit Gateway already.

Transit VPC is also used by customers to interconnect multiple Amazon Virtual Private Clouds (Amazon VPCs), with shared services, such as inspection at edge, and on-premises connections. This post specifically focuses on migrating Direct Connect services being used with Transit VPC. For a general migration approach, you can refer the post Migrate from Transit VPC to AWS Transit Gateway.

Similar to Part 1, this approach prioritizes reduced downtime and assumes that you have a resilient Direct Connect environment.

Existing Transit VPC architecture

This blog helps you migrate if you are using the solution outlined in the post integrating sub-1 Gbps hosted connections with AWS Transit Gateway. With the launch of expanded connect speed support, the previous solution is no longer recommended because of the additional costs and complexity involved when using third-party appliances, routers, and additional VPN tunnels.

The following figure shows a typical customer architecture when using the old solution, which involves the following components:

• Direct Connect, private virtual interface, and a Virtual Private Gateway (VGW).
• Third-party router or firewall appliances in the Transit VPC.
• VPN tunnels between the VGW and the third-party router appliances.
• VPN tunnels between the third-party appliances and Transit Gateway via an Internet Gateway (IGW) in the Transit VPC.
• BGP route propagation from the customer’s on-premises routers to the third-party appliances and then to Transit Gateway.

If firewall appliances were being used, then they could also perform traffic inspection and (if capable) provide next-generation firewall capabilities, besides terminating the IPSec VPNs and BGP sessions.

Figure 1: Typical Transit VPC configuration

Case A: Migrating from Transit VPC with third party router appliances

The migration will occur in three stages.

Stage 1: Build Transit Gateway and Direct Connect connectivity for a Test VPC on a secondary Direct Connect connection

As with Part 1 of this post, the first step involves using the secondary Direct Connect connection for provisioning the Transit VIF. We document detailed migration steps in Part 1 of this series.

At a high-level, this involves deleting private virtual interface 2 (on the secondary Direct Connect connection) and creating a new Transit VIF. If you keep the configuration of the private virtual interface while creating the Transit VIF, then no changes are required on the on-premises router.

As shown in the following figure, we can attach the secondary Direct Connect as attachment to the Transit Gateway.

Migration steps:

• Step 1: Create a Direct Connect Gateway.
• Step 2: Copy the configuration of private virtual interface 2. You can use the describe-virtual-interfaces CLI command to do this. The key information to capture is as follows. You can reuse this in step 4) to reduce router configuration changes.

1. 1. VLAN
   2. Customer ASN
   3. Customer Peer IP
   4. AWS Peer IP
   5. BGP Auth Key

• Step 3: Delete private virtual interface 2 (on Direct Connect Connection 2).
• Step 4: Create the new transit virtual interface, selecting Direct Connect connection 2 and specifying the exact configuration parameters as collected in step 2). If you set everything up correctly, then the transit virtual interface will show the status as available and the BGP status as up. This will be seamless, with no change to the on-premises router configuration. However, if you’ve changed any of the virtual interface configuration, then you can always download the new router configuration from the transit VIF console page and change the router config accordingly. For example, reconfigure the router if you used a different ASN for Direct Connect gateway, a different VLAN, a different AWS/Customer peer IP, or a different BGP Auth Key, while configuring the transit VIF.
• Step 5: Attach Direct Connect Gateway with Transit Gateway.
• Step 6: Specify the Test VPC CIDR that you want to reach from on-premises in the allowed prefixes.
• Step 7: Create a new Transit Gateway route table and associate it with the Test VPC attachment.
• Step 8: Propagate Direct Connect attachment routes to this new Transit Gateway route table. Verify the Test VPC route advertisements are received on-premises over the new Transit VIF.

After this stage, the traffic flows will be:

• Production VPC (Existing flow) – Traffic from the Production VPC will continue to use the existing Transit Gateway route table. Traffic will go over the existing VPN attachment, which is via the third-party router in the Transit VPC and Direct Connect connection 1.
• Test VPC (New flow) – Traffic from the Test VPC will use a new Transit Gateway route table that sends traffic to the Direct Connect attachment. Traffic will use the Direct Connect attachment and Direct Connect connection 2 to on-premises

Figure 2: Intermediate Stage 1 : Hosted Direct Connect Connections with Transit VPC and native Direct Connect connectivity for Test VPC using Transit Gateway

Stage 2: Build Transit Gateway Direct Connect- connectivity for Production VPCs on secondary Direct Connect connection

Migration steps:

• Specify the production VPC(s) CIDR that you want to reach from on-premises in the allowed prefixes.
• Use the new Transit Gateway route table and associate it with the Prod VPC(s) attachments. This way, the routes from the Direct Connect attachment will be available for traffic from the existing Prod VPC via Transit Gateway.
• For the existing Direct Connect connection 1, you would stop advertising Prod VPC routes (over VPN attachments) via Transit VPC to the on-premises router.
• Verify that the on-premises router has received all the AWS route advertisements over the Direct Connect connection 2.

Figure 3: Intermediate Stage 2: Hosted Direct Connect Connections with Transit VPC and native Direct Connect connectivity for Production VPC and Test VPC using Transit Gateway

The traffic flow for all the VPCs now goes over the Direct Connect connection 2 using Transit VIF as shown in the previous figure.

Stage 3: Migrate to active/passive connections using Transit Gateway and decommission Transit VPC

Migration steps:

• The final migration step is to delete the private VIF and create a new transit VIF on Direct Connect Connection 1.
• On-premises routes received from both the transit VIF 1 and transit VIF 2 propagate to the new Transit Gateway route table.
• Traffic leaving from the Test VPC and Production VPC reaches on-premises using the Direct Connect attachment. Once both of the transit ViFs are setup, the original BGP preferences on the on-premises router are used. Direct Connect connection 1 becomes active and Direct Connect connection 2 becomes passive for all the traffic flows to and from on-premises.
• Verify if all the VPC CIDR ranges are being received correctly on the customer gateway from both active and passive Direct Connect connections.
• Once the verification is completed, you can delete the transit VPC and its associated components.

The following figure shows the final state where all the VPCs are using active/passive Direct Connect with Transit Gateway. Note that the third-party appliances, VPN tunnels, Transit Gateway attachments, and Transit VPC which were present in the original architecture, are no longer required.

Figure 4: Final Stage 3: Direct Connect connectivity using Transit Gateway

Note that for customers who wish to continue to encrypt traffic between Transit Gateway and their on-premises network, AWS Site-to-Site VPN Private IP VPNs is now supported.

Case B: Migrating from Transit VPC with third party Next-Generation Firewall appliances

Consider the case shown in the following figure, where the third-party appliances inside of the Transit VPC are inspecting North-South traffic. Other connectivity elements of the network remain the same.

Figure 5: Direct Connect connectivity using Transit VPC and Next Generation firewall

To maintain the inspection facility, an inspection VPC can be added as depicted in the following figure. The inspection VPC contains next generation firewall appliances with Gateway Load Balancer as in the post Centralized inspection architecture with AWS Gateway Load Balancer and AWS Transit Gateway.

The inspection VPC can be established before or after the Direct Connect migration, as traffic is directed to be inspected based on route tables in Transit Gateway. This configuration also allows for East-West traffic inspection.

Figure 6: Direct Connect connectivity using Transit Gateway and inspection VPC

Conclusion:

In this post, we took a close look at a migration approach for using a native integration of Direct Connect sub 1 Gbps hosted connections with Transit Gateway instead of using a Transit VPC. As AWS continues to launch new features and services, you should re-asses your AWS hybrid network connectivity architecture and look at options that will reduce your network connectivity cost and operational complexity. By utilizing Transit Gateway/Direct Connect connectivity for hosted connections, you can simplify your existing hybrid connectivity architectures, optimize costs, and allow seamless scaling for your cloud infrastructure.

To learn more about AWS hybrid networking patterns and design considerations, you can refer the Hybrid Connectivity whitepaper. If you need help with planning a migration, talk to your AWS Technical Account Manager (for Enterprise Support customers) or AWS Solutions Architect.

About the Author