AWS Network Firewall Centralized Inspection: The Transit Gateway Pattern

The simplest way to ruin network security is to let every VPC invent its own firewall story. The cleaner pattern is still centralized inspection: one inspection VPC, one firewall policy set, and routing that forces traffic through the inspection path before it reaches shared services, the internet, or another spoke.

AWS Network Firewall fits that pattern well, and AWS kept improving it in 2026. In February, AWS cut some pricing for service-chained configurations and removed extra data processing charges for Advanced Inspection in several regions. In January, AWS added web-category-based filtering for GenAI traffic. The service has not become simpler to explain, but it has become easier to justify.

The Pattern

The classic design is still the right one:

Spoke VPCs -> Transit Gateway -> Inspection VPC -> Transit Gateway -> Shared services or internet

The key point is that Transit Gateway is the hub and the inspection VPC is the enforcement point. AWS’s own deployment guidance says the centralized model assumes a Transit Gateway, a dedicated inspection VPC, and route tables that send traffic to the firewall endpoint in the same AZ.

That architecture is good for east-west traffic between VPCs, north-south traffic to the internet, and on-prem traffic that arrives through VPN or Direct Connect. It is also the pattern AWS uses in its Cloud WAN security stories when service insertion or central inspection is required.

Why It Matters In 2026

The feature that still sells the pattern is control. Network Firewall can inspect TLS flows, surface traffic metrics, and sit in the path without forcing every application team to own a separate appliance lifecycle.

The feature that helps the economics is the 2026 pricing change. AWS reduced some of the overhead around service-chained NAT Gateway use and removed extra data processing charges for Advanced Inspection. That makes centralized inspection more realistic for environments that were hesitating because of cost.

The feature that feels most relevant to current workloads is the GenAI web-category filtering. A lot of teams are trying to govern model access, prompt tooling, and browser-like traffic patterns. Network Firewall now has a native policy hook for that instead of requiring a separate one-off proxy decision.

The Routing Contract

The hard rule is this: if traffic should be inspected, it must cross the inspection VPC before it reaches the destination.

That means:

• one route table per AZ for the TGW attachment path
• a default route in the spoke path that points at the firewall endpoint in the same AZ
• non-overlapping CIDRs everywhere
• a maintenance window when you shift existing attachments over to the new inspection route tables

If that sounds operationally picky, it is. Network security usually is. The upside is that once the topology is stable, the policy engine is much easier to reason about than a pile of distributed firewalls.

The Gotchas

The first gotcha is asymmetry. If return traffic does not follow the same path, stateful inspection gets weird very quickly.

The second gotcha is CIDR hygiene. The inspection VPC CIDR itself cannot overlap with anything already attached to the Transit Gateway. AWS calls that out directly in the deployment walkthrough because route overlap breaks the whole design.

The third gotcha is scale by AZ, not by hope. Centralized inspection is Multi-AZ by design. If you underbuild the route tables, or try to force all traffic through one endpoint, you create a bottleneck and then blame the firewall.

The fourth gotcha is that HOME_NET matters. Once the inspection point is central, the firewall needs to know about every relevant source range, not just the inspection subnet.

When To Use It

Centralized inspection is worth the trouble when one security team needs one policy boundary for many VPCs. That is usually the case once the environment has Transit Gateway, shared services, and more than one way into AWS.

If the environment is small, the centralized model is usually too much ceremony. A couple of VPCs do not need a whole inspection VPC just to prove the architecture works.

The useful mental model is still simple: AWS Interconnect brings traffic into AWS, Transit Gateway moves it around, and Network Firewall decides what gets through. When those jobs stay separate, the path is easier to reason about and much easier to debug. If you want the broader security context around that traffic, the AWS Security Hub guide and AWS GuardDuty guide are the right companion posts.