Crossing Two Non-Transitive AWS Transit Gateway Peerings with an Inspection VPC

AWS Transit Gateway peering is not transitive. If Transit Gateway A is peered with Transit Gateway B, and Transit Gateway B is peered with Transit Gateway C, AWS does not turn B into a native transit path between A and C.

That rule is correct, but it does not describe every packet path that can be built around those peerings.

In this design, workloads behind A and C can communicate even though their regional Transit Gateways have no direct peering. The traffic passes through B, but B does not route it directly from one peering attachment to the other. Instead, B sends the packet into an inspection VPC, through AWS Network Firewall, and back into the same Transit Gateway. That extra VPC hop creates a second route-table lookup. The second lookup sends the packet over the other peering attachment.

The result looks like transitive peering from the workload’s point of view, but the mechanism is different. It is better described as effective transit through an inspection VPC.

I built a small Terraform lab to test the idea. Private connectivity worked between EC2 instances in eu-west-1 and ap-southeast-1, with the only firewall and transit hop in us-east-1. The lab steps are included below so the path can be reproduced and checked.

This post uses one centralized Network Firewall in us-east-1. The edge Regions contain workload VPCs and TGWs, but no inspection VPCs or firewalls. It explains the packet path, the route tables that make it work, and why the result does not contradict AWS’s non-transitive peering rule.

The network

The example uses three AWS Regions:

There are two TGW peering attachments:

eu-west-1 TGW <---- peering ----> us-east-1 TGW
us-east-1 TGW <---- peering ----> ap-southeast-1 TGW

There is no direct peering between eu-west-1 and ap-southeast-1.

The first expectation was that traffic between the two workload VPCs would fail because the use1 TGW would need to forward a packet from one peering attachment directly to another. That would be native transitive peering, which is not the path this design uses.

The important difference

The unsupported mental model is one TGW route-table decision across two peering links:

eu-west-1 peering
    -> use1 TGW
    -> ap-southeast-1 peering

The working path has an inspection VPC in the middle:

eu-west-1 peering
    -> use1 TGW pre-inspection route table
    -> use1 inspection VPC attachment
    -> AWS Network Firewall
    -> use1 inspection VPC attachment
    -> use1 TGW post-inspection route table
    -> ap-southeast-1 peering

The packet leaves the use1 TGW and enters the inspection VPC. After inspection, a VPC route sends it back to the TGW. At that point, the packet is arriving from the inspection VPC attachment, not directly from the eu-west-1 peering attachment. The post-inspection route table can therefore select the ap-southeast-1 peering attachment as its next hop.

The original source and destination IP addresses do not need to change. What changes is the TGW attachment from which the second route lookup receives the packet.

Architecture

The following diagram shows the overall network architecture.

The forward packet path

Assume Instance A connects to a private address on Instance B, such as 10.2.10.10.

1. Instance A sends the packet to the eu-west-1 TGW

The private subnet route table in the source VPC sends non-local traffic to the regional TGW:

A narrower route for 10.2.0.0/16 could be used instead of the default route. The important point is that the packet reaches the euw1 TGW attachment.

2. eu-west-1 sends the remote CIDR toward use1

The euw1 TGW needs a static route for the destination CIDR:

There is no inspection VPC or Network Firewall in eu-west-1. The source VPC attachment and the use1 peering attachment use an edge TGW route table that contains the remote static route and the local VPC route. Forwarding from a VPC attachment to a peering attachment is a normal TGW routing operation; it does not require transitive peering.

3. The use1 peering attachment uses the pre-inspection table

When the packet reaches use1, the euw1 peering attachment is associated with the use1 pre-inspection route table. That table sends traffic to the inspection VPC attachment:

This route is the first half of the service-insertion pattern. The use1 TGW does not try to send the packet directly to the apse1 peering attachment.

4. The inspection VPC forwards the packet through Network Firewall

Inside the inspection VPC, the TGW attachment subnet sends traffic to the Network Firewall endpoint in the same Availability Zone:

AWS Network Firewall applies its stateful and stateless policies. After inspection, the firewall subnet route table recognizes the private workload CIDR and sends the packet back to the TGW:

The specific route for 10.2.0.0/16 matters. Without it, the packet could follow the default egress route toward a NAT gateway instead of returning to the TGW.

5. The packet re-enters use1 through the inspection VPC attachment

The inspection VPC attachment is associated with the use1 post-inspection route table. The packet now gets another TGW route lookup:

This is the step that creates effective transit. The lookup is based on traffic arriving from the inspection VPC attachment. It is not a direct peering-attachment-to-peering-attachment lookup.

6. ap-southeast-1 delivers the packet to Instance B

The packet crosses the use1-apse1 peering. The apse1 TGW then routes 10.2.0.0/16 to the destination VPC attachment.

There is no inspection VPC or Network Firewall in ap-southeast-1. The incoming use1 peering attachment uses an edge TGW route table with a local route for 10.2.0.0/16, learned through VPC route propagation or configured statically. Forwarding from a peering attachment to a VPC attachment is also a normal TGW routing operation.

The return path must match

The central stateful firewall requires a predictable return path. Instance B’s response follows the reverse route:

Instance B
  -> apse1 TGW
  -> use1-apse1 peering
  -> use1 pre-inspection route table
  -> use1 inspection VPC and Network Firewall
  -> use1 post-inspection route table
  -> use1-euw1 peering
  -> euw1 TGW
  -> Instance A

The use1 post-inspection table must therefore contain both regional prefixes:

10.2.0.0/16 -> use1-apse1 peering
10.1.0.0/16 -> use1-euw1 peering

The edge TGWs also need correct return routes. A working forward route with a missing return route often looks like a firewall or security-group problem because the first packet leaves successfully but the session never completes.

Why this is not native TGW peering transitivity

We need to be strict with the wording.

Native transitive peering would mean that the central TGW accepts a packet from one peering attachment and routes it straight to another peering attachment as one transit operation. This design does not rely on that behavior.

Instead, the path consists of two forwarding operations separated by a VPC:

Operation 1:
euw1 peering attachment -> use1 TGW -> inspection VPC attachment

Operation 2:
inspection VPC attachment -> use1 TGW -> apse1 peering attachment

The inspection VPC is an active Layer 3 forwarding point. Network Firewall is the appliance on that path, but filtering is not the feature that changes the routing boundary. The important event is that the packet leaves the TGW through a VPC attachment and comes back through that attachment.

From the applications’ point of view, the network provides transit between eu-west-1 and ap-southeast-1. From the TGW control-plane point of view, there is still no native route propagation or native transitive relationship between the two peering attachments.

The load-bearing part of this topology is the use1 peer-to-inspection-VPC-to-peer segment. The edge Regions perform standard VPC-attachment-to-peering and peering-to-VPC-attachment forwarding, so they do not need inspection VPCs to preserve the path.

AWS documents those building blocks separately, but it does not present this exact topology as a named transitive-peering feature.

Build and run the test lab

I’ve published the complete Terraform scripts on Github . It creates:

• A source VPC (10.1.0.0/16) and one t3.micro EC2 instance (10.1.10.10) in eu-west-1
• A destination VPC (10.2.0.0/16) and one t3.micro EC2 instance (10.2.10.10) in ap-southeast-1
• A central inspection VPC (10.100.0.0/16) in us-east-1
• Three Transit Gateways and exactly two TGW peering attachments
• One AWS Network Firewall deployed across two Availability Zones in us-east-1
• Pre-inspection and post-inspection TGW route tables
• Network Firewall flow and alert logs in CloudWatch Logs
• An IAM role for Systems Manager access to both EC2 instances

The EC2 instances are in private subnets and have private IPv4 addresses only. Traffic between 10.1.0.0/16 and 10.2.0.0/16 follows the more-specific TGW routes and uses private IP addresses to validate conectivity.

How to verify the real path

A successful ping or TCP connection proves reachability, but it does not prove which path was used. Check the control plane and the data plane.

1. Check TGW routes

For each route table, search for the two workload CIDRs:

aws ec2 search-transit-gateway-routes \
  --transit-gateway-route-table-id <route-table-id> \
  --filters "Name=route-search.exact-match,Values=10.2.0.0/16"

Repeat for 10.1.0.0/16 and for the relevant route tables in all three Regions.

2. Check TGW route-table associations

In use1, confirm that both peering attachments use pre-inspection and the inspection VPC attachment uses post-inspection:

aws ec2 get-transit-gateway-route-table-associations \
  --transit-gateway-route-table-id <route-table-id>

3. Check inspection VPC routes

Confirm that the TGW subnets point to the correct zonal firewall endpoints and that firewall subnets route both workload CIDRs back to the TGW:

aws ec2 describe-route-tables --route-table-ids <route-table-id>

4. Check the central firewall logs

The connection should appear in the us-east-1 Network Firewall logs. Both forward and return records should use the original workload IP addresses:

10.1.10.10 -> 10.2.10.10
10.2.10.10 -> 10.1.10.10

There are no eu-west-1 or ap-southeast-1 firewall logs in this design because those Regions do not contain firewalls. Seeing both directions in use1, together with the expected TGW routes, is strong evidence that the packet crossed the central inspection VPC.

Operational trade-offs

This pattern works, but it is not free transit.

Cost

A cross-Region connection can incur:

• TGW data processing in multiple Regions
• Inter-Region TGW peering data transfer
• Network Firewall processing charges
• NAT charges if a private-prefix route is missing and traffic falls into the egress path
• Cross-Availability Zone charges in some routing layouts

One centralized firewall means one inspection point in each direction. This avoids edge-firewall processing charges, but the flow still crosses multiple TGW attachments and two inter-Region peering links.

Latency

The packet crosses two inter-Region peerings and one central firewall. For eu-west-1 to ap-southeast-1 traffic, use1 is still a geographic detour. Measure application latency rather than assuming that successful connectivity is good enough.

Failure domain

The use1 inspection VPC is a transit dependency for every star path. A bad route, firewall policy error, endpoint problem, or deployment failure in use1 can affect communication between Regions that are otherwise healthy.

Route scale

Because peering routes are static, adding a VPC means updating the use1 post-inspection table and the relevant edge route tables. Per-VPC routes are easy to understand but grow quickly. Route aggregation can reduce table size, but only when the address plan guarantees that an aggregate always points to the same next hop.

Troubleshooting complexity

The packet crosses several routing domains:

1. Source VPC route table
2. euw1 TGW edge route table
3. euw1-use1 TGW peering
4. use1 TGW pre-inspection table
5. use1 inspection VPC routes and Network Firewall
6. use1 TGW post-inspection table
7. use1-apse1 TGW peering
8. apse1 TGW edge route table
9. Destination VPC route table

Write the expected path down before troubleshooting. Then check each boundary in order.

When this pattern makes sense

This design can be useful when:

• Several smaller Regions connect to one primary Region.
• A full mesh would create too many peering attachments.
• Central inspection is already required.
• Static route management is acceptable.
• The added latency is acceptable for the applications.
• The central Region is designed as a shared failure domain.

A direct TGW peering is usually simpler when two Regions exchange a large amount of latency-sensitive traffic. AWS Cloud WAN may be a better fit when the network needs a managed global core, policy-driven segmentation, or a topology that will grow well beyond a small number of Regions.

The practical lesson

The statement “TGW peering is not transitive” remains true. The mistake is treating it as if no packet can ever cross two TGW peering links.

A packet cannot rely on the middle TGW to perform native peering-to-peering transit. It can, however, leave that TGW through an inspection VPC attachment, pass through a forwarding appliance, and re-enter through the VPC attachment. The second route-table lookup can then select another peering attachment.

The inspection VPC is not just observing the flow. It is the routing boundary that makes the end-to-end path possible.

References

• Transit gateway peering attachments — AWS documentation for creating peering attachments and adding static routes.
• How AWS Transit Gateway works — AWS documentation for attachment routing, route-table association, propagation, and appliance mode.
• Appliance in a shared services VPC — AWS documentation for the two-table inspection pattern and appliance-mode flow symmetry.