How to interconnect AWS Cloud WAN core networks

Introduction

AWS Cloud WAN is a managed wide-area networking (WAN) service for building, managing, and monitoring a unified global network, as well as connecting resources running across your cloud and on-premises environments. With AWS Cloud WAN, you have a central place to create and manage your global routing configuration by creating a policy and achieving traffic segmentation between resources in several AWS Regions.

This blog post will address challenges that may arise for use cases that require interconnectivity between AWS Cloud WAN core networks. You might have AWS Cloud WAN core networks in multiple AWS accounts under an organization in AWS Organizations that need to communicate. A second use case may emerge from a merger or acquisition.

Prerequisites

The blog post assumes you are familiar with the AWS Cloud WAN, traffic segmentation, and the global core network key concepts. You should also be familiar with AWS Transit Gateway and using it in a federation model with AWS Cloud WAN. Transit Gateway federation is explained in the blog post Achieving traffic segmentation in multi-AWS Region environments using AWS Transit Gateway and AWS Cloud WAN.

Deployment models

Scenario one: Connect two AWS Cloud WAN core network segments or business units under the same or different AWS Organizations with no traffic inspection.

In this use case, the core networks are managed by different teams. They might be different accounts under the same organization, or they could be under different organizations. This case applies to a situation where there is no need to inspect traffic, but in which you still need to extend some or all of your segmentation across the two core networks.

The following diagram, Figure 1, shows what the build for this option. In this example, we connect the production segments for Account A and Account B.

Figure 1 Connecting two AWS Cloud WAN core network segments with no inspection

Walkthrough

Follow these steps in both accounts to implement this architecture.

1) Follow the steps in this link to Create the transit gateway.

1. When you enter an Autonomous System Number (ASN) for this transit gateway for the Amazon side of the BGP session ensure it is unique.
2. If you want to automatically share across accounts, check the box Auto accept shared attachments.
3. Repeat these steps for Account B.

Figure 2 Create a transit gateway

2) Follow the steps in this link to Create transit gateway peering attachment to the second account’s transit gateway:

Note: if you checked the box Auto accept shared attachments in Step 1, the attachment will become available. If you did not, you will need to accept the attachment in the second account.

Figure 3 Create an attachment to the second account’s transit gateway

3) Create a peering to the transit gateway from AWS Cloud WAN

1. Navigate to the VPC console in Account A.
2. Select Cloud WAN, and then select your global network.
3. Select Peerings and then select Create peering. Name the peering and select the Edge location from the dropdown. This must be the same Region the transit gateway is in.
4. Next, choose the transit gateway you created in the previous step. Then, associate either a new or existing policy table.
   1. New — Creates a new policy routing table.
   2. Existing — Allows you to associate this peering with an existing policy table. If you choose this option, you’ll be prompted to choose an existing transit gateway policy table to associate with the peering. The transit gateway policy table is for transit gateway dynamic routing. Transit Gateway uses policy tables to route network traffic for AWS Cloud WAN.
5. Choose Create peering.
6. Repeat these steps for Account B.

Figure 4 Create a core network peering to the transit gateway

4) Create an attachment over the peering to the transit gateway from AWS Cloud WAN

1. Navigate to the VPC console in Account A.
2. Select AWS Cloud WAN, and then select your global network.
3. Select Attachments and then select Create attachment. Name the attachment and select the Edge location from the dropdown.
4. For Attachment type choose transit gateway route table from the dropdown.
5. Next, choose the transit gateway peering you created in the previous step.
6. Then choose a transit gateway route table from the dropdown. This is the route table you want to use with the AWS Cloud WAN segment. It is recommended to create a dedicated route table for each AWS Cloud WAN segment that needs to be connected over the transit gateways.
7. Next under Tags you need to enter a Key and a Value. In order for the routes to populate dynamically, the correct AWS Cloud WAN segment attachment policy needs to be applied to this attachment.
8. Choose Create attachment.
9. Repeat the preceding steps for Account B.

Figure 5 Create a core network attachment

5) Configure static routes on the transit gateway route table

1. Navigate to the VPC console in Account A.
2. Select Transit gateway route tables and then select the route table you associated to the attachment in the previous step.
3. Select the routes tab, then choose Create static route.
4. You will want to add a static entry for Account B production CIDR ranges and choose the Transit Gateway peering attachment you created in Step 2.
5. Repeat the preceding steps for Account B using the Account A production CIDR ranges this time.

Figure 6 Create static routes in transit gateway route table

Since the peering from the transit gateway to AWS Cloud WAN is dynamic, you should see routes from AWS Cloud WAN propagated into the transit gateway route table, and you should now see the static routes you entered in route table as propagated in the other accounts in the AWS Cloud WAN console.
You can do the same process for any other segment, but depending on the number of segments that need to be interconnected, this may become more administrative overhead, and costs for additional transit Gateway attachments and data processing will increase.

Scenario two: Connecting two or more AWS Cloud WAN core network segments with traffic inspection.

In this architecture we connect two cloud core networks with inspection points for traffic flowing between them. This is generally a best practice when providing connectivity between two organizations in the case of mergers and acquisitions.
In this model, we introduce an inspection VPC with an AWS Network Firewall in each of the accounts and attach it to the associated transit gateway as shown in Figure 7. This will allow each organization to apply its security policy independently and make sure that only traffic agreed upon and explicitly allowed through both firewalls is allowed to flow through the interconnect. You may be able to accomplish this with one inspection VPC under one centralized networking account or one central IT in the same organization model to optimize costs.

Figure 7 Interconnecting two AWS Cloud WAN core networks through inspection points

In the architecture shown in Figure 7, we see that both the production and nonproduction segments in the AWS Cloud WAN core network are extended into the transit gateway and attached to production and nonproduction route tables, respectively.
Also note that we have created an inspection segment in each core network and attached it to the inspection route table in the transit gateway. This will allow us to share the routes from the production and nonproduction segments with the inspection segment in AWS Cloud WAN, which in turn will allow them to be learned by the inspection route table in the transit gateway through dynamic routing.

Figure 8 depicts the route tables for AWS Cloud WAN core networks as well as the transit gateways resulting from both dynamic route propagation as well as static routes.
Note that unlike the first scenario, in this model, we are not extending segments across the two organizations but rather ensuring the application of the desired security zoning model through the policy applied on the network firewalls on either side of the interconnect.

Figure 8 Interconnecting two AWS Cloud WAN core networks through inspection points – route tables

In Figure 8, the blue arrow shows the path forward traffic will take, whereas the red arrow shows the path for return traffic. Note how traffic in both directions crosses both firewalls, which is the desired behavior.

Walkthrough

For this scenario complete Steps 1–4 of the previous scenario to start. Complete step 4 for the nonproduction attachment if you want to route another segment across the interconnect. It is assumed that you are familiar with the steps to configure transit gateway route tables and that these are deployed as shown in Figure 8.
The deployment of the inspection VPC and AWS Network Firewall are covered in Deployment models for AWS Network Firewall. In this scenario, we are using the centralized AWS Network Firewall deployment model.

1) Configure the inspection segment in AWS Cloud WAN Core Network A and configure route sharing

1. Navigate to the VPC console in Account A.
2. Select Cloud WAN, Global Networks, and select your global network.
3. Under Core network, select Policy versions and Edit your LIVE Policy version.
4. Select the Segments tab and choose Create.
5. Under Segment name, enter InspectionASegment and enter a description.
6. For Segment filter, select Allow selected.
7. For Limit to specific Edge locations – optional, select the Region where you have your transit Gateway. In this example, it is US East (N. Virginia.).
8. For Allow segment list, select your production and nonproduction segments previously created and then choose Create segment.
9. Repeat these steps for Core Network B

Figure 9 Configuration for inspection segment on Core Network A

Note that the inspection segmentation does not need to be attached to any VPC because it is only used to propagate production and non-production routes to the transit gateway.

2) Apply changes to the AWS Cloud WAN policy and attach the inspection segment to the inspection route table on the transit gateway.

1. Once you have created the configuration for the inspection segment, choose Create Policy.
2. Select the policy marked as LATEST and select View or apply change set.
3. On the following page, select Apply change set, which will deploy your changes to the AWS Cloud WAN core network.
4. Once the changes have been applied, attached the new inspection segment to the inspection route table on the transit gateway, as described in Step 4 of the first scenario.
5. Repeat these steps for Core Network B.

Once the environment is deployed, we will have four route tables per transit gateway, which will have some routes being propagated and others configured as static. The route tables need to look as follows:

Transit gateway A route tables

Figure 10 Transit gateway A route tables

Transit gateway B route tables

Figure 11 Transit gateway B route tables

Considerations

The use case interconnects were in the same Region and the inspect VPCs were all in US East (N. Virginia). Consider creating the AWS Transit Gateway interconnnect in the Region where you have the most workloads to lessen AWS Transit Gateway costs. You are charged for the number of connections that you make to the transit gateway per hour and the amount of traffic that flows through AWS Transit Gateway as well as inter-regional data transfer.
In order to keep the traffic flows symmetric for stateful network appliances, you must enable appliance mode on the inspection VPC attachment to the transit gateway.

Cleanup

If you do not want to incur costs for the above scenarios delete the transit gateway and the peering that were created.

• Delete a transit gateway peering attachment
• Deleting a transit gateway

Delete the Cloud WAN attachments and peering that were created.

• Delete a Cloud WAN attachment
• Delete a Cloud WAN peering

Conclusion

AWS Cloud WAN provides customers with the ability to enhance their inter-region connectivity providing dynamic routing, automation, cross-Region segmentation, and improved visibility. In this post, we showed how it is possible to interconnect and extend AWS Cloud WAN segments between the core networks using AWS Transit Gateway in Scenario 1. In scenario 2 we showed how to enable traffic segregation through the insertion of inspection points at either side of the interconnect link. The latter approach allows customers to inspect traffic and have full control of what traffic is allowed to flow between the two core networks.

A correction was made on February 6, 2024: An earlier version of this post included missing links, minor typos and an incorrect order of paragraphs.