Transitive Routing

Transitive routing is the ability to forward traffic between networks through an intermediate routing domain. If network A connects to network B, and B connects to network C, transitive routing can provide a path from A to C through B. However, the existence of those two connections alone does not establish that path. The intermediate infrastructure must support forwarding between the connections, and routing and security controls must permit traffic in both directions.

This distinction is important in cloud networks because a connectivity service may deliberately restrict transit. AWS VPC peering, for example, provides nontransitive connectivity between two VPCs. If VPC A peers with VPC B, and VPC B peers with VPC C, A cannot communicate with C through those peering connections. Adding route-table entries does not remove this restriction. A direct A-to-C peering connection or a supported transit architecture is required.

Direct peering is appropriate when a small number of VPCs need straightforward, pairwise connectivity without a shared routing hub. A full mesh of n VPCs requires n(n−1)/2 peering connections, so connection and route management become increasingly complex as the estate grows. A transit hub reduces the number of connections by letting participating networks attach to a common routing service. This simplifies connectivity management, but does not imply that every attached network should communicate with every other network.

For example, consider application VPCs using 10.10.0.0/16 and 10.20.0.0/16, plus an on-premises network using 172.16.0.0/16. With an AWS Transit Gateway architecture, each VPC needs subnet routes for remote destinations pointing to the transit gateway. The transit gateway needs routes directing those destinations to the correct VPC, VPN, or Direct Connect gateway attachment. The on-premises routers also need return routes toward the application networks. Route propagation can populate supported transit gateway routes, but it does not automatically configure the VPC subnet route tables.

Transit routing is a reachability mechanism, not a security policy. Separate routing tables or segments can allow application networks to reach shared services while preventing production and development networks from communicating directly. Security groups, network ACLs, and firewalls still enforce traffic policy. Overlapping address ranges prevent straightforward destination-based routing and generally require renumbering or a carefully designed translation or service-access approach.

Hybrid connectivity requires the same attention to supported paths. A VPC peering connection does not let a peer VPC use the other VPC's VPN connection, Direct Connect connection, NAT device, or internet gateway as a transit path. A supported hub architecture is needed instead. Similarly, attaching networks to different transit gateways and peering those gateways does not automatically exchange all routes; transit gateway peering requires static routing for destinations reached across the peering attachment.

The trade-offs include cost, performance, operational complexity, and failure impact. Compare attachment charges, data processing, data transfer, throughput limits, and expected traffic volumes rather than assuming either peering or transit is always cheaper or faster. Centralized inspection can simplify enforcement but adds dependencies and requires symmetric traffic paths through stateful appliances. For troubleshooting, trace the forward and return paths separately, verify every routing-table lookup and attachment, and check filtering, MTU, and appliance behavior. A route existing in one table is not proof of end-to-end connectivity.