AWS Cloud WAN is a managed wide area networking (WAN) service that helps you build, manage, and monitor a unified global network connecting cloud and on-premises resources. In 2024, we launched service insertion, an AWS Cloud WAN feature that streamlines integrating security and inspection services into global networks. Using AWS Network Manager console or JSON policies, you can define network function groups (NFGs) and traffic redirection rules to steer global network traffic between HAQM Virtual Private Clouds (HAQM VPCs), AWS Regions, on-premises locations, and the internet through security appliances or inspection services. After configuration, it automatically routes traffic through security services for east-west and north-south communication patterns.

This post focuses on implementing AWS Cloud WAN with service insertion for greenfield deployments, particularly for filtering and inspecting internet-bound (north-south) traffic (egress traffic). To keep latency low and optimize costs, we recommend keeping your egress traffic within the Region where your resources are deployed. AWS Cloud WAN operates globally, but security inspection using centralized AWS Network Firewall or third-party appliances behind Gateway Load Balancer (GWLB) is deployed within a Region. Filtering and inspecting traffic within an HAQM VPC or in transit between HAQM VPCs (also known as east-west traffic) is a valid use case but isn’t discussed here.

In this post, we examine three scenarios:

1. Single-Region Egress (North/South) Inspection
2. Multi-Region Egress (North/South) Inspection with egress stack in all the Regions
3. Multi-Region Egress (North/South) Inspection with Geo Clustering and Edge Override

Prerequisites

This post expands upon the concepts introduced in our previous post, Simplify global security inspection with AWS Cloud WAN service insertion. That post covered key benefits and architecture patterns for inter-Region, intra-Region, and inter-segment scenarios. Before proceeding with this post, you must have a solid understanding of the Global and core network key concepts discussed previously.

For all the scenarios, while we show IPv4 addressing, AWS Cloud WAN supports both IPv4 and IPv6 addressing.

Scenario 1: Single Region Egress (North-South) Inspection

Figure 1 shows Scenario 1, which depicts a single Region (Region 1) containing two VPCs:

1. Prod VPC 1 (10.1.0.0/16): Attached to the Prod segment.
2. Inspection VPC 1 (100.64.1.0/24): Attached to the Inspection NFG and housing security appliances.

In this scenario, all traffic exiting from Prod VPC 1 to the internet is first routed through Inspection VPC 1. Return traffic follows the same path. This inspection process is facilitated by service insertion through the Inspection NFG, which enhances security by screening all internet-bound traffic.

Figure 1: Internet Egress inspection in a single Region

We can examine a walkthrough that outlines the process of inserting a security construct into the egress traffic path between Prod VPC 1 and the internet within the us-east-1 Region using AWS Cloud WAN Service Insertion’s Network Function Group (NFG).

Step 1: Create an InspectionNFG NFG using the following sample:

"network-function-groups": [
    {
      "name": "InspectionNFG",
      "description": "Route segment traffic to the inspection VPC",
      "require-attachment-acceptance": false
    }
  ],

Step 2: Create an Inspection VPC 1 attachment with key-value tag. You can create an attachment using the AWS Command Line Interface (AWS CLI) by following the following sample:

aws networkmanager create-vpc-attachment \
--core-network-id "<core-network-id>" \
--vpc-arn "<vpc-arn>" \
--subnet-arns "<subnet-arn>" \
--tags Key=environment,Value=InspectionNFG

Step 3: The attachment policy analyzes the Cloud WAN attachment key-value tag that we specified in Step 2, not the tags associated with the VPC resource. The following sample attachment policy analyzes the attachment and maps attachments with the tag “environment“: “InspectionNFG” to an InspectionNFG NFG. The Inspection VPC 1 attachment must be mapped to the InspectionNFG NFG before inserting it into the traffic path using segment actions:

"attachment-policies": [
    {
      "rule-number": 100,
      "condition-logic": "or",
      "action": {
        "add-to-network-function-group": "InspectionNFG"
      },
      "conditions": [
        {
          "type": "tag-value",
          "value": "InspectionNFG",
          "operator": "equals",
          "key": "environment"
        }
      ]
    },
],

Step 4: Use the following sample segment-actions send-to parameter to insert the InspectionNFG NFG into the internet egress traffic path. This step should be performed after creating the Inspection VPC 1 attachment and associating it with the InspectionNFG NFG:

"segment-actions": [
    {
      "segment": "Prod",
      "action": "send-to",
      "via": {
        "network-function-groups": [
          "InspectionNFG"
        ]
      },
      "when-sent-to": {
        "segments": "Prod"
      }
    }
  ]

When you insert the InspectionNFG NFG into the traffic path using the send-to parameter, a default route is added to the segments on which the action is applied. As a result, all internet egress traffic from the Prod segment is steered through the firewall in the Inspection VPC 1. AWS Cloud WAN performs the following actions:

• Propagate the Prod VPC 1 CIDR (10.1.0.0/16) into the InspectionNFG route table, with Prod VPC 1 attachment as the next hop. Routes propagated within the same Region have their next hop redirected to the local NFG attachment.
• Add a 0.0.0.0/0 and ::/0 routes in the Prod Segment route table, with the next hop set as the local NFG attachment.

Figure 2: Internet egress inspection traffic flow

Packet walkthrough

This walkthrough (Figure 2) shows how packets flow when a resource in Prod VPC 1 sends traffic to the internet within the same Region:

• (A) When a resource in Prod VPC 1 initiates a connection to a destination on the internet, it performs a lookup in the Prod VPC 1 route table. The packet matches the default route entry with the core network HAQM Resource Name (ARN) as the target, and is subsequently routed to the core network.
• (B) Upon arrival at the core network, a lookup is performed in the Prod segment route table, with US East-1 as the edge location (since Prod VPC 1 is associated with the Prod segment). The packet matches the default 0.0.0.0/0 CIDR entry, which has the Inspection VPC attachment as its target. Consequently, the packet is routed to the Inspection VPC.
• (C) The Core Network ENI in the Inspection VPC forwards the packet to the firewall/security appliances (Network Firewall or GWLB) through a firewall endpoint (not shown here) for inspection. If the packet is allowed, then the endpoint forwards it to a Network Address Translation (NAT) Gateway (not shown). Then, the NAT Gateway forwards the packet to an Internet Gateway (IGW), which sends it out to the internet.
• (D) For returning traffic, the IGW sends the packet back to the NAT Gateway in the same Availability Zone (AZ) where the traffic originated.
• (E), (F) Return traffic follows the same path in the opposite direction.

Scenario 2: Multi-Region Egress (North-South) Inspection with Egress Stack in All the Regions

Figure 3 shows the distribution of resources across three AWS Regions: us-east-1, us-west-1, and us-west-2. Each AWS Region comprises two VPCs: a Prod VPC and an Inspection VPC. The Prod VPCs are mapped to the Prod segment, while the Inspection VPCs are mapped to the InspectionNFG NFG. This multi-Region deployment expands upon the previously described single-Region architecture.

Figure 3: Multi-Region architecture with egress stack in all AWS Regions

AWS Cloud WAN segments can be configured as either a global or regional objects. This configuration allows you to design your routing so that each AWS Region has a regional attachment for specific destination CIDRs. As a result, you maintain control over the exit point for egress traffic. When we insert the InspectionNFG NFG into the traffic path using the send-to parameter, AWS Cloud WAN adds a default route to the segment where the action is applied. This default route uses the corresponding regional Inspection VPC attachment as the next hop.

This routing behavior occurs because, for routes with the same destination IP address but different targets, AWS Cloud WAN prefers the same/local Region’s routes over remote Region routes. For more detailed information about this behavior, consult the Route Evaluation section in the AWS Cloud WAN documentation.

Figure 4: Traffic flow for Scenario 2

Packet walkthrough

The packet flow (Figure 4) follows the process outlined in Scenario 1. In each AWS Region, resources connect to the internet through their designated regional firewalls (label (A)).

Scenario 3: Multi-Region Egress (North-South) Inspection with Geo-Clustering and Edge Override

For internet egress, you can choose between two approaches: deploying an egress VPC (security stack) in each AWS Region (as described in Scenario 2), or implementing an egress VPC in a single Region to inspect and process traffic from multiple AWS regions. For example, you can deploy firewalls and NAT Gateways according to geographical areas, such as the Americas (AMER) or Europe (EMEA), to manage egress traffic for each respective AWS Region.

Without edge override

Figure 5 demonstrates Scenario 3, in which Region 1 (us-east-1) and Region 2 (us-west-2) each maintain their own Inspection VPCs with firewalls, while Region 3 (us-west-1) operates without one.

Figure 5: Multi-Region architecture without egress stack in all AWS Regions

When deploying an egress VPC in one AWS Region to inspect and process traffic from multiple AWS Regions, careful consideration of the next hop selection is essential. By default, when multiple attachments with similar attributes are received from multiple Core Network Edges (CNEs), the system uses an ordered list to choose which Region (and thus which attachment) forwards the traffic. This can result in suboptimal routing behavior.

For example, although us-west-1 (N. California) is geographically closer to us-west-2 (Oregon), by default, egress traffic from us-west-1 (N. California) is routed through the us-east-1 (N. Virginia) firewall instead of the closer us-west-2 (Oregon) firewalls. This occurs because, according to the ordered list, us-east-1 has a higher priority than us-west-2. This behavior is shown in Figure 6.

Figure 6: Traffic flow without edge override

Packet walkthrough

The packet flow (Figure 6) is similar to Scenario 2. In the us-east-1 and us-west-2 Regions, resources connect to the internet through their designated regional firewalls (label (A)). However, for us-west-1, which does not have its own regional egress VPC, resources connect to the internet through the firewalls in us-east-1 (label (B)).

With edge override

AWS Cloud WAN Service Insertion’s edge override attribute allows you to modify the default next hop selection process. When configuring AWS Cloud WAN policies, you can use edge override to redirect traffic from a specific source Region through a firewall (Inspection VPC) in your preferred AWS Region. The following is an example of an edge override policy configuration:

"segment-actions": [
    {
      "action": "send-to",
      "segment": "Prod",
      "via": {
        "network-function-groups": [
          "InspectionNFG"
        ],
        "with-edge-overrides": [
          {
            "edge-sets": [
              [
                "us-west-1"
              ]
            ],
            "use-edge-location": "us-west-2"
          }
        ]
      },
      "when-sent-to": {
        "segments": "Prod"
      }
    }
  ],

Using edge override allows you to route traffic from the us-west-1 Region through a firewall in the us-west-2 Region, instead of routing through the firewall in the us-east-1 Region. Figure 7 shows this configuration.

Figure 7: Traffic flow with edge override

Packet walkthrough

The packet flow (Figure 7) is similar to Scenario 2. In the us-east-1 and us-west-2 Regions, resources connect to the internet through their designated regional firewalls (label (A)). However, for us-west-1, which doesn’t have its own regional egress VPC, resources connect to the internet through the firewalls in us-west-2 instead of us-east-1, due to the edge override configuration (label (B)).

Considerations

 For details refer to the following:

• AWS Cloud WAN documentation
• The Considerations section in the post, ‘Simplify global security inspection with AWS Cloud WAN Service Insertion’

Conclusion

This post has explored internet egress (north-south) inspection architecture patterns using AWS Cloud WAN service insertion. This capability streamlines traffic steering through network functions (such as firewalls and security appliances) deployed in VPCs or on-premises networks. Using either AWS Network Manager or JSON, you can define policies and NFGs to redirect traffic between segments through specified attachments. This supports internet egress, as well as Regional, and cross-Regional traffic flows. For more information, consult the AWS Cloud WAN documentation.

About the authors