Introduction

Since its launch, AWS Cloud WAN has sparked a lot of interest from customers and has seen a number of enhancements. The latest is service insertion, a new capability that lets you easily insert AWS and third-party networking and security services onto AWS Cloud WAN using a central policy document. Using this feature, you can easily steer VPC-to-VPC, VPC-to-on-premises, or egress traffic through network or security appliances by defining simple policy statements or alternatively with just few actions in the UI. Service insertion is explained in detail in Simplify global security inspection with AWS Cloud WAN Service Insertion.

Most customers today have an implementation that includes multiple Regions with each having centralized inspection. This post provides a step-by-step approach to migrate from:

• Centralized security inspection built with transit gateways to AWS Cloud WAN with service insertion, while at the same time maintaining connectivity and minimizing downtime during the migration phase.
• AWS Cloud WAN implementation without service insertion to one with service insertion.

AWS Transit Gateway is an integral part of Amazon Web Services (AWS) networking solutions and plays a crucial role in facilitating scalable and efficient connectivity between virtual private clouds (VPCs), virtual private networks (VPNs), and on-premises networks. This post is intended for customers interested in adopting AWS Cloud WAN to use specific features such as policy-based management, single-click segmentation, and native automation. It offers insights and considerations for such adoption within the AWS environment. Readers are encouraged to assess their networking needs and explore available options before making decisions.

Solution Overview

AWS Cloud WAN service insertion takes away the complexity of inserting network services, such as firewalls, in the path of traffic. It does it through the use of simple intent-based policy statements or a few actions in the UI to redirect traffic to inspection VPCs.

It introduces a new construct called network function group (NFG), which is a global container for your inspection VPC attachments. It manages the redirection of traffic to the desired firewall based on the intent defined in the policy. This includes inter-segment and intra-segment, VPC-to-VPC, Region-to-Region, on-premises-to-VPC, and VPC- or on-premises-to-internet. Service insertion eliminates the complexity of having to configure Regional inspection segments and managing static routes for traffic redirection because both the NFG and route propagation are managed automatically for you.

There are no additional charges for using service insertion other than the regular AWS Cloud WAN Pricing.

Prerequisits

For the following sections, we assume that you are familiar with fundamental networking constructs on AWS – Amazon VPC, AWS Transit Gateway, AWS Cloud WAN and AWS Network Firewall.

We won’t focus on the detailed steps for deploying initial infrastructure and services, so we assume you will deploy the following setup in your test environment. Our setup makes use of the following services that need to be pre-deployed:

• For scenario 1: deploy workload VPCs, Inspetion VPCs with AWS Network Firewall, AWS Transit Gateways and the associated route tables, attachments and peering.
• For scenario 2: deploy workload VPCs, Inspetion VPCs with AWS Network Firewall, AWS Cloud WAN without service insertion and the associated segments, attachments and routing.

Migration use cases

Scenario 1: Migration from Transit Gateway to AWS Cloud WAN with service insertion

In this scenario we cover the migration from an architecture based on transit gateways and centralized inspection to one with AWS Cloud WAN with service insertion.

Current state, without AWS Cloud WAN

A common architecture we see customers adopting in a multi-Region deployment is the use of peered Transit Gateways with centralized inspection in each Region. The benefits of such architecture are that it is well-understood, predictable, and allows you to redirect traffic to inspection VPCs as required. This is of particular relevance to inter-Region traffic, where firewalls are used to ensure that traffic going over the peering link is only authorized if it adheres to the segmentation policy. However, such architecture requires the management of a number of static routes and often the implementation of a double inspection resulting in additional cost.

The architecture (Figure 1) shows two Regions and two workload types that need to be segmented. As an example, we are using production and non-production workloads, but it could be any other type of segmentation. This will be used as the starting point because it represents what many customers may have in place today.

Figure 1: Multi-Region deployment with transit gateways and security inspection

Phase 1: Deploying AWS Cloud WAN and transit gateway peering

The first step is to deploy AWS Cloud WAN core network across both Regions and create the peering with the transit gateways in each of the Regions, as shown in Figure 2.

Figure 2: Deploying AWS Cloud WAN with transit gateway peering

Refer to blog posts Deploying hybrid networks using AWS Cloud WAN and AWS Direct Connect and Achieving traffic segmentation in multi-AWS Region environments using AWS Transit Gateway and AWS Cloud WAN, which cover the configuration details shown in phase 1 (Figure 2).

You will need to apply the policy change to proceed. However, at this stage, we have not yet configured any segments, attachments, or routing, so there will be no change to your routing. The path across Regions remains over transit gateways peering.

Phase 2: Configure segments and create transit gateway route table attachments

The next step is to extend the production and non-production route tables configured on the transit gateway across the two Regions over AWS Cloud WAN. By doing so, the segmentation defined within each of the Regions can be extended over the core network. This eliminates the need to rely on the firewalls to maintain the segmentation across Regions. This will improve performance by reducing the number of hops and also reduce the cost associated with inspection and processing charges for traffic remaining within the same segment.

To do that, we need to create the segments in AWS Cloud WAN and configure the associated route table attachments in both Regions. We will not go over the details of this configuration because it was covered in the blog posts provided in the phase 1 section.

Figure 3: Extending production and non-production segments across the core network

The production route table in us-east-1 on the transit gateway is now learning the route of the production VPC in eu-west-2 over the core network and the other way around. These are shown in red in the route tables in Figure 3. The same applies to the non-production route tables.

This means that traffic from the production VPC in us-east-1 to the production VPC in eu-west-2 will flow over AWS Cloud WAN, as shown by the purple arrow in Figure 3. This is because the route tables on the transit gateway are learning more specific routes, which take precedence over the default route originally configured to send all traffic for nondirectly attached VPCs through the inspection VPC.

If more specific static routes were used instead of a default route, these would need to be deleted in order for the traffic to go over AWS Cloud WAN. This is because for the same prefix, a static route takes precedence over a dynamically learned route. You will need to coordinate that on both Regions to avoid asymmetric routing. Refer to the Route evaluation section in the Transit Gateway documentation for more details.

At this stage, however, traffic going between production and non-production workloads will continue to match the default route. It will be sent through the inspection VPCs attached to the transit gateways and over the peering between them for cross-Region traffic.

The following is an example of the core network policy configuration required to associate production and non-production transit gateway route tables and VPC attachments to the respective AWS Cloud WAN segments:

Core network policy

   "segments": [
      {
          “name”: “Production”,
          ”Isolated”: “False”

          “name”: “Non-Production”,
          ”Isolated”: “False”
      }, …

   “attachment-policies” [
      {
          “rule-number”: 100
          “description”: “Production VPCs”,
          “conditions”:[
           {
             “type”: “tag-exists”,
             “key”: “Segment”,
             “operator”: “equal-to”
             “value”: “Production”
            }
           ],
     ”action”:{
             “add-to-segment”: “Production”
         }
      {
          “rule-number”: 200
          “description”:“Non-Production VPCs”,
          “conditions”:[
           {
             “type”: “tag-exists”,
             “key”: “Segment”,
             “operator”: “equal-to”
             “value”: “NonProduction”
            }
           ],
       ”action”:{
               “add-to-segment”: “NonProduction”
           }
      } ]

Transit gateway route table attachments configuration

Configure the transit gateway route table attachment for both the production and non-production route tables. Figure 4 shows how to do this for the production route table in us-east-1. Make sure to replicate the configuration for the remaining route tables. Ensure that the attachment tag matches the attachment policy defined in the core network policy.

You will need to apply the changes to the policy first before being able to configure the attachments. This will not alter your routing. However, configuring attachments will propagate new routes and modify routing as described above.

Figure 4: Configuring transit gateway route table attachments

Phase 3: Configure the NFG and attach the inspection VPCs

In this step, we configure the NFG in AWS Cloud WAN and use the attachment policy to add two new inspection VPCs to it (Figure 5). The configuration of the firewall appliance (AWS Network Firewall, as shown) is beyond the scope of this post. Refer to Getting started with AWS Network Firewall in the documentation to learn more.

Figure 5: Configuring the NFG and attaching inspection VPCs

The reason we deploy two new inspection VPCs is to minimize any potential downtime as we transition the inter-segment inspection from the transit gateways to AWS Cloud WAN. It also allows us to keep the existing deployment in place for the transition phase and in case there is a need to roll back. After successfully transitioning all VPCs to AWS Cloud WAN, we will retain the inspection VPCs within AWS Cloud WAN only.

A configuration example for creating the NFG and the attachment policy for the inspection VPCs is shown in the following JSON policy:

Core network policy

   "network-functions-group": [
       {
             “name”: “InspectionVpcs”,
             “require-attachment-acceptance”: false
       }
      ]
   “attachment-policies” [
       {
             “rule-number”: 500
             “description”: “Service Insertion Inspection VPCs”,
             “conditions”:[
                {
                   “type”: “tag-exists”,
                   “key”: “Network-Function-Group”,
                   “operator”: “equal-to”
                   “value”: “InspectionVpcs”
                 }
                ],
     ”action”:{
              “add-to-network-functions-group”: “InspectionVpcs”
               }
   } ]

Inspection VPC attachments configuration

Configure the attachment for both inspection VPCs to the NFG as shown in Figure 6 for us-east-1 and eu-west-1 Regions. Ensure that the attachment tag matches the attachment policy defined in core network policy and that Appliance mode support is selected.

You will need to apply the changes to the policy first before being able to configure the attachments. Routing will not be altered at this stage even after configuring the attachments.

Figure 6: Configure inspection VPC attachment to the NFG

Phase 4: Move inter-Region inspection to AWS Cloud WAN

In this phase, we redirect the inter-Region inter-segment traffic through the NFG on AWS Cloud WAN. Service insertion will send the traffic through the new inspection VPCs, as shown by the route tables and the purple arrow in Figure 7.

By default, service insertion will select a single inspection point for all traffic between Region-pairs. In this case, the inspection VPC selected by default is us-east-1 (you can also specify the inspection VPC for each Region-pair), with the other used as backup. Using a single inspection point improves performance and further reduces costs associated with both inspection and AWS Cloud WAN processing charges by eliminating the need for a double inspection, as is usually implemented in traditional deployments.

Figure 7: Transition inter-Region inspection to AWS Cloud WAN using service insertion

Insert inspection between production and non-production segments

To do this, we use service insertion to insert the inspection points in the path of traffic going between the production and non-production segments in both directions. This is achieved by adding a send-via statement to the policy, as shown in the following example. To learn more about send via segment action, refer to the AWS Cloud WAN documentation.

{
    “segment-actions”:
            “send-via”,
                “segment”: “Production”,
                “when-sent-to”:{ “segments”: [“Non-Production”]},
                ”via”: { “network-function-group”: [“InspectionVpcs”]}
  }

Note that a single send-via segment action is sufficient to inspect traffic going between the production and non-production segments in both directions. There is no need for a separate statement for traffic initiated from the non-production segment going to production.

If we examine the transit gateway route tables in Figure 7, looking at the routes shown in red, we can see that the production route tables are now learning routes to the non-production VPCs in the other Region from the core network. Similarly, the non-production route tables are learning routes to the production VPCs, again in the other Region, also from the core network. This is because service insertion and the managed NFG segment are dynamically propagating these routes based on the segment action and the send-via policy defined previously.

These routes will override the static default route originally configured to send traffic to the inspection VPCs attached to the transit gateways for inter-Region traffic and will instead send it to the inspection VPC attached to the NFG. However, within the same Region, traffic going between production and non-production VPCs will continue to flow through the inspection VPC attached to the transit gateway. This is the case until one or both workload VPCs are migrated to AWS Cloud WAN as described in the next phase.

You will need to apply the policy changes at this stage. Once the changes are applied, the routing will need to reconverge and propagate the new routes, potentially causing a brief interruption of some flows. It is, therefore, best practice to apply these configurations during a scheduled maintenance window to ensure a smooth transition with minimal disruption.

Phase 5: Migrate VPCs from Transit Gateway to AWS Cloud WAN

At this stage, all inter-Region traffic is going over AWS Cloud WAN, and if it is inter-segment, it will be routed through the inspection VPCs attached to the NFG. We can now start migrating production and non-production VPCs from the transit gateways to their corresponding segments on AWS Cloud WAN. This is best done in phases to minimize the risk of a potential misconfiguration impacting a large number of VPCs.

The approach to migrate VPCs from Transit Gateway to AWS Cloud WAN is detailed in AWS Cloud WAN and AWS Transit Gateway migration and interoperability patterns.

Figure 8 shows the migration of the non-production VPCs from the transit gateways to AWS Cloud WAN, the updated route tables, and the traffic flows.

Figure 8: Migrating VPCs from AWS Transit Gateway to AWS Cloud WAN

As the non-production VPCs are moved from the transit gateways to AWS Cloud WAN, the non-production segment will learn their Classless Inter-Domain Routings (CIDRs). It will also dynamically propagate them to the non-production route tables on the transit gateways over the attachments configured in phase 2. This allows for a gradual migration by maintaining reachability between migrated VPCs and those still on the transit gateways.

Similarly, these routes are also dynamically propagated to the production segment on AWS Cloud WAN and the production route tables on the transit gateways, but this time by means of service insertion and the NFG. Because the production route table on the transit gateway now has a more specific route to the non-production VPCs learned from AWS Cloud WAN, it will prefer it over the default route pointing to the inspection VPC attached to the transit gateway. Therefore, traffic will be routed to AWS Cloud WAN through the NFG and the inspection VPC attached to it and onto the non-production VPCs. This is shown in Figure 8 by the blue arrows, and the purple arrow shows traffic going between segments across Regions.

Moving VPCs from Transit Gateway to AWS Cloud WAN will require the routing to reconverge and propagate the new routes, potentially causing a brief interruption of some flows. So, here again, it is best practice to apply these configurations during a scheduled maintenance window to ensure a smooth transition with minimal disruption.

Phase 6: Finalizing migration

Once all workload VPCs have been migrated and all testing has been conducted successfully, we can now safely delete the old inspection VPCs and the transit gateways, as shown in the end-state architecture in Figure 9. Note that the NFG route tables are managed and are populated based on the service insertion policy. While you have full visibility into these routes, you cannot add, delete, or share routes within a NFG.

Figure 9: End-state implementation and AWS Cloud WAN route tables

Scenario 2: Brownfield migration from AWS Cloud WAN Regional inspection to service insertion

In this scenario (Figure 10), we look at the use case where AWS Cloud WAN has been implemented with Regional inspection segments using static routes to redirect traffic to the respective inspection VPCs. We explain how to transition to using service insertion.

Figure 10: Initial state: AWS Cloud WAN with Regional inspection segments (without service insertion)

Step 1: Create (Figure 11) the network function group (Figure 12) in the AWS Cloud WAN network policy UI.

Figure 11: Create policy – Network function group

Figure 12: Create network function group

Step 2: Add a rule to the attachment policy to map one or more attachments that contain inspection devices (such as firewalls) to the network function group (NFG). Here we use Key: Network-Functions-Group, Value: InspectionVpcs. This will be used later when you move the inspection VPCs from the Regional inspection segments to the newly created NFG.

Figure 13: Create a new attachment policy for the NFG

Step 3: As described in scenario 1, in order to direct traffic going between the production and non-production segments to the inspection VPCs, you need to create a service insertion policy for these two segments. Figures 14 and 15 show how you do that in the UI:

1. Edit current policy version, go to Service insertion and click Create
2. Select Send via for Action and Single hop for Mode
3. Select Production for Segment from and NonProdcution for Segment to
4. Under Send traffic via select your NFG
5. Leave the Edge overrides section empty because it does not apply in this use case.

Figure 14: Create service insertion

Figure 15: Configure service insertion

At this stage, you need to apply the policy changes in order to proceed. This will not impact routing or existing flows.

Step 4: Once the service insertion has been created and the policy applied, you can now move the inspection VPCs to the NFG. To do that, you need to modify the existing attachments to the Regional inspection segments by adding a new tag and removing the old one. This will change the attachment from being associated to the Regional inspection segments over to the newly configured NFG.

Figure 16: Update attachment tags

Add the new tag that matches the attachment policy created in Step 2 (Key: Network-Functions-Group, Value: InspectionVpcs) and remove the tag that was assigned for the Regional inspection segments (Key:segment, Value: InspectionUSWest2).

 Figure 17: Add new tag and remove old tag

Once the tags are updated, routing will need to reconverge and propagate the new routes, potentially causing brief interruption of some flows. It is, therefore, best practice to apply these configurations during a scheduled maintenance window to ensure a smooth transition with minimal disruption.

Verify the attachments to the inspection VPCs have now changed to the NFG attachment policy and are Available.

Figure 18: Verify attachments have been updated

Step 5: At this stage, traffic is dynamically routed to the inspection VPCs using service insertion and the NFG. You can now safely remove the configurations associated with the Regional inspection segments because these are not used anymore.

Start by removing any static routes in AWS Cloud WAN segment options, which previously sent traffic to the Regional inspection VPC attachments.

Figure 19: Delete static routes

Delete the old attachment policies for the old Regional inspection segments.

Figure 20: Delete attachment policies for Regional inspection segments

Delete the Regional inspection segments.

Figure 21: Delete Regional inspection segments

Figure 22 shows the end state with NFG and service insertion configured for inspection.

Figure 22: End state with service insertion

Considerations

• Egress inspection is not covered in this post. If egress is combined with east-west inspection, additional considerations will be required, including the use of the send-to segment action.
• The security policy should be replicated across all firewalls before starting migration.
• Some use cases, such as the use of an AWS Direct Connect connection, will require you to keep the transit gateways in place.
• As workload VPCs are moved from AWS Transit Gateway to AWS Cloud WAN, their route tables need to be updated to point to the core network instead of the transit gateway.
• In this post, we assumed that a default route is used on the Transit Gateway production and non-production route tables to direct the traffic to the inspection VPC. If you are using VPC specific static routes instead (for example, for cross-Region traffic), these will need to be deleted for the traffic to go over AWS Cloud WAN. This is because for the same prefix, a static route takes precedence over a dynamically learned route. You will need to coordinate that on both Regions to avoid asymmetric routing.

Cleanup

Follow these steps to remove the resources you deployed in this blog:

• Delete the Cloud WAN attachments, peerings and core network that were created.
  1. Delete a Cloud WAN attachment
  2. Delete a Cloud WAN peering
  3. Delete an AWS Cloud WAN core network
  4. Delete an AWS Cloud WAN global network
• Delete the transit gateway and attachments that were created.
  1. Delete VPC attachments to transit gateways
  2. Delete transit gateways
• Delete the elements of your initial setup including EC2 instances, AWS Network Firewalls and VPCs.

Conclusion

Network inspection plays a vital role in every cloud implementation. Customers aiming to adopt AWS Cloud WAN for its unique advantages, such as policy-based management, single-click segmentation, and native automation, often encounter the challenge of ensuring a seamless and predictable transition, particularly in routing traffic through inspection points.

In this post, we have demonstrated how service insertion can streamline such transitions, minimize disruption, and enhance overall efficiency. We also offered a step-by-step approach to guide you through the process to ensure a smooth and successful implementation. To learn more visit AWS Cloud WAN service insertion.

About the authors