Centralized inspection on AWS with Transit Gateway: patterns and pitfalls

Who this is for: network and cloud architects who run several VPCs and want one place where traffic is inspected. The article is based on AWS documentation and on design work our engineers have delivered: Gateway Load Balancer with Palo Alto Networks VM-Series transparent inspection, and transit gateway route segmentation for east-west and egress inspection.

What does the pattern consist of?#

AWS describes a transit gateway as “a Regional virtual router” that routes at layer 3 between VPCs and on-premises networks. Centralized inspection adds one place that holds the firewalls:

• Spoke VPCs, whose subnet route tables send traffic for other networks to the transit gateway.
• Transit gateway route tables. Each attachment is associated with exactly one route table and can propagate its routes to one or more. The spokes’ table sends traffic to the inspection attachment; the inspection table routes back to each spoke.
• The inspection point: a VPC you build, with a transit gateway subnet and a firewall subnet per Availability Zone, or the Network Firewall attachment, where AWS places the endpoints in a VPC it manages.
• Appliance mode on the inspection attachment.

Three directions are usually in scope: east-west (spoke to spoke), north-south (on premises, through Site-to-Site VPN or Direct Connect gateway attachments), and egress to the internet.

Why is appliance mode needed?#

Without appliance mode, a transit gateway tries to keep traffic between VPC attachments in the Availability Zone where it started. The result is asymmetric routing: request and response use different network interfaces, and traffic can be dropped. In AWS’s example, the reply returns through the appliance in a second zone, which never saw the request, so the packet is dropped.

With appliance mode on the inspection VPC’s attachment, the transit gateway picks one network interface in that VPC with a flow hash and uses it for both directions for the life of the flow. AWS attaches conditions:

• Attach exactly one transit gateway to the inspection VPC. Transit gateways do not share flow state.
• Stickiness holds while both directions reach the inspection VPC from the same transit gateway attachment. Traffic can drop if source and destination sit on two different attachments, or if the inspection VPC receives traffic from another gateway, such as an internet gateway, and then sends it to the transit gateway after inspection.
• Turning appliance mode on for an existing attachment can change that attachment’s current routes. Treat it as a change with a rollback.

With Gateway Load Balancer, the target group must use 5-tuple stickiness: AWS does not support the 2-tuple and 3-tuple options when transit gateway appliance mode is on.

Which design? The inspection pattern decision table#

AWS Network Firewall is a managed, stateful firewall and intrusion prevention service built on the open-source Suricata engine. Gateway Load Balancer is not a firewall: it distributes traffic to virtual appliances from the vendor you choose, at layer 3, and exchanges traffic with them over GENEVE on port 6081.

The inspection pattern decision table compares the three designs. Rows marked (author) are our engineering reading; the rest come from the AWS pages in the sources.

AWS’s blog of September 16, 2026, puts it plainly: “For most customers, Transit Gateway Native Attachment provides the simplest operational model.” It keeps the inspection VPC for granular routing control or where a team’s expertise is built around it.

How do you build it?#

1. List the flows that must be inspected, and the ones that must not. Inspection is a policy decision before it is a routing one.
2. Lay out subnets per Availability Zone. In AWS’s layout, the transit gateway subnet routes to the firewall endpoint in the same zone, and the endpoint’s subnet routes back to the transit gateway. A Network Firewall endpoint cannot filter traffic entering or leaving its own subnet, so the firewall subnets are dedicated.
3. Design the transit gateway route tables. The spokes’ table sends the default route, or the inspected prefixes, to the inspection attachment; the inspection table routes to each spoke. The most specific prefix wins first; for the same prefix, a static route beats a propagated one.
4. Turn on appliance mode on the inspection attachment. The native Network Firewall attachment has it on already.
5. Place firewalls in every enabled zone. AWS recommends multiple Availability Zones for transit gateway VPC attachments. A Gateway Load Balancer target group needs at least one registered target in each enabled zone, and cross-zone load balancing is off by default.
6. Test outside production. Send a flow whose source and destination sit in different zones through the inspection path. Then remove one appliance and watch existing flows: by default, Gateway Load Balancer keeps them on the failed target, where they drop, and sends new flows to healthy targets.

The inspection failure-mode checklist#

One more check follows from AWS’s route order rather than from an AWS statement: if spoke VPC routes propagate into the spokes’ table, those more specific routes beat the static default, and east-west traffic skips the firewall. AWS’s example spoke table holds only the static default route.

What about multiple Regions?#

Transit gateways are Regional. Two of them connect through a peering attachment, which supports static routes only, and AWS recommends a unique autonomous system number for each peered transit gateway. Our default (author) is one inspection point per Region, with static routes between Regions.