AWS Transit Gateway: Three Best-Practice Architecture Patterns

AWS Transit Gateway (TGW) has become the default way to connect VPCs, VPNs, and Direct Connect at scale, replacing the operational headache of full-mesh VPC peering. But once it's live, the decisions that actually determine whether your network is secure, auditable, and easy to operate come down to one thing: route table design.

This is a walkthrough of three proven patterns, in order of increasing control — how the route tables are built, when to use each one, and the trade-offs, with a reference architecture diagram for each.

At a glance

CORE MECHANISMRoute table association (1 per attachment) and propagation (many per attachment)
PATTERNS COVEREDHub-and-spoke, segmented isolation, centralized inspection
KEY TRADE-OFFOperational simplicity vs. network-layer isolation vs. inspection coverage
BEST FORAnyone designing or auditing a multi-VPC AWS network with TGW at the core

01 How TGW Routing Actually Works

Every VPC, VPN, Direct Connect Gateway, or peering connection you attach to a Transit Gateway is called an attachment. Each attachment has two independent relationships to a TGW route table:

Association — which single route table an attachment uses to make its own forwarding decisions (an attachment can only be associated with one route table at a time).
Propagation — which route table(s) learn that attachment's routes automatically (an attachment can propagate into many route tables).

This association/propagation split is the entire toolkit for building segmentation on TGW. You don't need separate gateways for separate security zones — you need separate route tables and a deliberate propagation strategy. Everything below is a variation on that same primitive.

02 Hub-and-Spoke — Single Default Route Table

This is what you get "for free" when you create a Transit Gateway with default route table association and propagation enabled. Every attachment — VPCs, VPN, Direct Connect — is associated with the single default route table, and every attachment propagates its routes into that same table.

Figure 1 — Hub-and-spoke: every attachment associates and propagates into one shared TGW route table.

Route table	Association	Propagation
TGW-RT-Default	All attachments	All attachments

When to use it

Early-stage landing zones or proof-of-concept environments where segmentation isn't yet a requirement.
Small estates (a handful of VPCs) where operational simplicity outweighs the lack of network-layer isolation.
Environments where applications are already isolated by account boundaries, and TGW is purely there for shared connectivity (e.g., to on-premises).

Trade-off. The convenience is also the risk: this pattern gives you any-to-any connectivity by default. There's nothing in the routing layer stopping a compromised dev workload from reaching a production database if the CIDRs and route propagation allow it. Segmentation has to be bolted on afterwards via security groups or NACLs. It's a fine starting point, but most organizations outgrow it the moment they have more than one environment or a compliance boundary to enforce.

03 Segmented Isolation — Prod / Non-Prod with Shared Services

This pattern replaces the single default route table with purpose-built route tables per environment, and uses a Shared Services VPC as the one deliberate crossover point.

Figure 2 — Segmented isolation: dedicated Prod and Non-Prod route tables, with Shared Services propagating into both.

Route table	Association	Propagation
Prod-RT	Prod VPC attachments	Prod VPCs + Shared-Services VPC
NonProd-RT	Dev/Test VPC attachments	Dev/Test VPCs + Shared-Services VPC
Shared-Services attachment	Its own or a dedicated RT	Propagates into both Prod-RT and NonProd-RT

The key mechanic: each spoke VPC is associated only with its own environment's route table, while the Shared-Services VPC propagates its routes into both tables. Production and Dev/Test never receive each other's propagated routes, so — as far as the routing layer is concerned — they are unreachable from one another. Both can reach the shared layer for things like Active Directory, DNS resolvers, CI/CD runners, or a NAT/proxy fleet.

When to use it

Any environment with a formal separation requirement between production and lower environments (common in finance, healthcare, government).
Multi-account landing zones (e.g., AWS Control Tower / Landing Zone Accelerator) where account-level isolation should be reinforced at the network layer, not just IAM.
Reducing blast radius — a misconfiguration or compromise in Dev/Test structurally cannot reach production, regardless of security group hygiene.

Trade-off. You now have more route tables to manage, and every new VPC attachment requires a deliberate decision about which table(s) it associates with and propagates into — this needs to be codified (e.g., in Terraform/CloudFormation) rather than done by hand, or drift creeps in. Many organizations extend this same pattern with additional route tables per business unit, per data classification tier, or per regulatory boundary — it scales well because it's just more tables and more deliberate propagation, not a different mechanism.

04 Centralized Inspection

This pattern goes a step further than isolation: it assumes no VPC should talk to any other VPC — or the internet, or on-prem — without passing through inspection first. All traffic, east-west between VPCs and north-south to the internet or on-premises, is forced through a dedicated Inspection VPC containing a firewall (AWS Network Firewall, or a third-party NGFW such as Palo Alto or Fortinet, typically fronted by a Gateway Load Balancer).

Figure 3 — Centralized inspection: spoke traffic is forced to an Inspection VPC/firewall, with a dedicated return-path route table.

Route table	Association	Routes
Spoke-RT	All spoke VPC attachments	Propagates only the Inspection VPC attachment; includes a 0.0.0.0/0 (and often more specific inter-VPC CIDRs) route pointing at it
Inspection-RT	Inspection VPC attachment	Propagates routes from every spoke VPC, so the firewall can return traffic after inspection

The effect: a spoke VPC has no route back to any other spoke VPC directly — every packet destined for another VPC, the internet, or on-premises is sent to the Inspection VPC first. The firewall appliance evaluates the traffic, and if it's permitted, forwards it back into the Transit Gateway, where Inspection-RT's propagated spoke routes let it reach its actual destination.

When to use it

Mandates for IDS/IPS, deep packet inspection, or centralized logging of all inter-VPC and egress traffic.
A single, auditable egress point to the internet (rather than per-VPC NAT gateways with inconsistent filtering).
Organizations standardizing on a third-party firewall vendor across all workloads, where per-VPC appliances would be cost-prohibitive and hard to keep consistent.

Trade-off. This is the most powerful pattern but also the most expensive and highest-latency: every cross-VPC packet now makes an extra hop through the inspection layer, and the firewall/GWLB endpoints need to be sized and deployed across multiple Availability Zones — a single-AZ inspection VPC is a single point of failure for your entire network. Route table design is also less forgiving here: a missing propagation on Inspection-RT silently blackholes return traffic. It's common to combine this pattern with segmented route tables that all funnel through the same (or per-environment) inspection VPC.

05 Choosing Between the Three

	Hub-and-Spoke	Segmented Isolation	Centralized Inspection
Route tables	1	2+ (per environment/boundary)	2+ (spoke vs. inspection)
VPC-to-VPC traffic	Direct, unrestricted	Direct within environment only	Always via firewall
Operational complexity	Low	Medium	High
Cost	Lowest (no extra hops)	Low-medium	Higher (firewall + GWLB + extra hops)
Typical use case	POCs, small/simple estates	Multi-environment landing zones	Regulated/high-security environments

In practice, many mature AWS environments don't pick just one — they layer them. It's common to see Segmented Isolation for environment separation combined with Centralized Inspection for anything crossing a security boundary (e.g., internet egress or connectivity to on-premises), while allowing free intra-environment traffic to skip inspection for cost and latency reasons.

06 Closing Recommendations

A few practices apply regardless of which pattern (or combination) you land on:

Manage TGW route tables as code. Association and propagation rules are easy to get subtly wrong by hand, and the failure mode — a silently blackholed route, or an accidental cross-environment path — is exactly the kind of thing you want caught in a pull request, not in production.
Turn on Transit Gateway Flow Logs and Network Manager. Route tables tell you what's allowed; flow logs tell you what's actually happening — essential for validating segmentation and inspection are working as intended.
Design your CIDR strategy before your TGW routing strategy. Overlapping CIDRs between VPCs will constrain every pattern above; get IP address management right first.
Revisit the pattern as you grow. It's entirely reasonable to start with Hub-and-Spoke and migrate to Segmented Isolation or Centralized Inspection as compliance or security requirements mature — the attachments don't need to move, only the route table associations and propagations around them.

07 Summary

Transit Gateway's real power isn't the gateway itself — it's the flexibility of its route table model. Once association and propagation click, all three of these patterns are really just different answers to the same two questions: who gets a say in where this attachment's traffic goes, and who gets to know how to reach it.