DEV Community

Pooria Ghaedi
Pooria Ghaedi

Posted on

AWS Cloud WAN Internet Egress and Deep Packet Inspection: Design Patterns and Best Practices

#aws #cloudwan #awsnetworking

This article is the second part of our AWS Cloud WAN series. In the first part, we explored the main components of Cloud WAN and how they fit into modern AWS networking — read it here.

Introduction

Centralized internet egress is one of the most common and often overlooked challenges in large AWS environments. In multi-account, multi-region, and multi-VPC architectures, having a NAT Gateway in every VPC (and sometimes in every AZ) can quickly drive up costs and make it harder to monitor or control outbound traffic.

In this article, we’ll explore how AWS Cloud WAN can be used to consolidate internet egress into a single, scalable architecture. Improving visibility, security, and cost efficiency. We’ll walk through both a basic egress VPC design and an enhanced design with AWS Network Firewall for traffic inspection, including architecture diagrams, routing details, and best practices.

If you’re a cloud architect, systems administrator, or NetOps engineer, you’ll learn how to design an egress solution that scales globally, aligns with security policies, and is easy to operate.Problem

The Hidden Costs and Risks of Distributed Egress

Without a centralized egress architecture, AWS environments often face two major challenges: cost inefficiency and loss of control over outbound traffic.

Cost Inefficiency

In a distributed egress model, each VPC typically has its own NAT Gateway in every Availability Zone for high availability. For example:

  • 5 VPCs × 3 AZs per VPC = 15 NAT Gateways
  • 15 NAT Gateways × $0.045/hour = $0.675 per hour
  • Monthly cost (730 hours) ≈ $492.75
  • Annual cost (8,760 hours) ≈ $5,913

One might argue that deploying a single NAT Gateway per region could reduce hourly costs. However, this approach often shifts expenses rather than eliminating them. When traffic from workloads in other Availability Zones or VPCs traverses that centralized NAT Gateway, you’ll incur data processing fees ($0.045 per GB) and potentially cross-AZ data transfer charges, both of which can significantly increase the overall bill.

Loss of Control & Visibility

With multiple distributed NAT Gateways, outbound traffic is spread across many exit points. This makes it difficult to:

Apply consistent security and compliance policies
Monitor traffic patterns effectively
Centralize logging and threat detection
Block or inspect suspicious destinations
As the environment grows, this lack of centralized control increases operational complexity and security risks.

Architecture Overview

For simplicity, we assume that we are working on a single AZ deployment.

Figure 1: CloudWAN Architecture

In this architecture, we have AWS Cloud WAN with two Core Network Edges (CNEs) deployed across two regions, and two workload VPCs connected to the Dev and Prod segments. To handle centralized outbound internet access, we created a Network Function Group (NFG) named Egress. While NFGs are implemented using dedicated segments under the hood, they serve a special purpose enabling service insertion to route traffic through network functions such as firewalls or inspection appliances.

Here’s how we send traffic from the Prod segment to the Egress VPC. The Cloud WAN policy propagates a route from the Prod segment to the Egress NFG:

{
"action": "send-to",
"segment": "Prod",
"via": {
"network-function-groups": [
"Egress"
]
}
}

The Egress VPC is attached to the Egress NFG just like any other VPC attachment: you specify the Core Network ID, choose the subnets where the attachment ENIs will be placed, and associate the attachment with the relevant Cloud WAN route table. Once attached, a Cloud WAN policy can steer traffic from the Prod segment through the Egress NFG for inspection before it exits to the internet.

Figure 2: Traffic path through private → public subnets via NAT GW

In this design, the Egress VPC contains two subnets. The private subnet is the landing point for the Cloud WAN attachment. When it receives traffic from workloads, it forwards it to the NAT Gateway. The NAT Gateway resides in the public subnet, which sends outbound traffic to the Internet Gateway (IGW) and then to the internet.

For return traffic, the NAT Gateway uses its route table to direct responses back to the Cloud WAN attachment in the private subnet, ensuring symmetric routing.

  • Private subnet: Receives traffic from Cloud WAN and forwards it to the NAT Gateway.
  • Public subnet: Hosts the NAT Gateway and sends traffic to the IGW for internet access.

Deep Packet Inspection with AWS Network Firewall and Cloud WAN
Now that we’ve come this far, let’s make the design a little more complex — and more exciting. With a small change to the Egress VPC, we can introduce traffic inspection. In this example, we’ll use AWS Network Firewall.

AWS Network Firewall is a managed firewall service that supports both stateless and stateful rules. With stateful rules, you can implement advanced features such as URL filtering and deep packet inspection.

So here’s the question: What should we add to the Egress VPC to enable inspection?

Figure 3: Traffic path through private → inspection → public subnets via Network Firewall

We need to add a new subnet. We’ll call it the inspection subnet. When you create an AWS Network Firewall, you’ll be prompted to select its landing subnet. Once chosen, AWS automatically provisions a Network Firewall endpoint (powered by a Gateway Load Balancer) in that subnet.

Once the endpoint is in place, the final step is to update the route tables so that traffic passes through the inspection subnet and Network Firewall before reaching the NAT Gateway or returning to Cloud WAN. The route updates are as follows:

Figure 4: Inpsection VPC route table

And we are good to go. You can go and check the network firewall monitoring to see if the packet is flowing through your firewalls.

Conclusion

We started with a simple centralized egress VPC and then took it one step further by adding inspection with AWS Network Firewall. The idea here is not just to save on NAT Gateway costs, but to actually gain visibility and control over outbound traffic. With Cloud WAN’s service insertion and NFGs, you can steer traffic exactly where you want it — whether that’s straight out to the internet, or through an inspection layer.

Like most AWS networking patterns, the design will depend on your requirements. Sometimes you only need a single egress point without inspection. Other times, compliance and security policies demand deep packet inspection and URL filtering. The good news is that with Cloud WAN, both models can live side-by-side and scale globally.

Lessons Learned

Here are a few key takeaways from deploying this architecture:

  • When you create a VPC attachment to Cloud WAN, AWS provisions an interface endpoint of the Transit Gateway type. From my experience, the Cloud WAN backbone is built on Transit Gateway.
  • When creating stateless rules in AWS Network Firewall, if you don’t explicitly set actions = [“aws:forward_to_sfe”], traffic will not be forwarded to the stateless rule groups for evaluation.
  • Even with Cloud WAN, you still need to update the route tables in each attached VPC manually (or via automation) to direct internet-bound or inspected traffic to the correct Cloud WAN attachment.
  • Create AWS Managed Prefix Lists containing the CIDR ranges you want to route (e.g., internal networks). Then, reference these prefix lists in your route tables and forward them to the Cloud WAN attachment. This simplifies management and reduces the chance of configuration drift across multiple VPCs.
  • Network Firewall endpoints scale with traffic, but NAT Gateways have throughput limits (45 Gbps per AZ). Plan for horizontal scaling if needed.
  • Remember, AWS Network Firewall adds its own data processing fees (~$0.065 /GB) and NAT GW data transfer — these are important to model accurately before rollout.

Top comments (0)