Why architecture matters here
Network topology is one of the hardest things to change after the fact, because everything above it — application dependencies, security-group references, DNS, monitoring — bakes in assumptions about who can reach whom. The reason TGW's architecture matters is that it turns topology into data: route tables and associations are API objects you can version, review in a pull request, and reason about, instead of an emergent property of dozens of independently managed peering connections. A reviewer can look at a single TGW route table and know, definitively, what the 'prod' segment can reach. With a peering mesh, answering the same question means auditing the route tables of every VPC and every subnet within them, and the answer changes silently whenever someone adds a route.
The design also matters because it makes segmentation the default rather than an afterthought. VPC peering is non-transitive by deliberate design — if A peers with B and B peers with C, A cannot reach C — which people experience as a limitation but which is actually the security property you usually want. TGW is transitive by default (every attachment on the same route table can reach every other), so the discipline inverts: you must actively partition attachments into separate route tables to recreate isolation. This is why the association/propagation model is load-bearing. A shared-services route table that every environment propagates into, combined with per-environment route tables that only propagate their own prefixes plus shared-services, gives you a hub-and-spoke where spokes reach shared services and the internet egress VPC but not each other — the canonical enterprise topology, expressed in maybe a dozen route entries instead of a hundred peering links.
Finally, the architecture matters commercially and operationally because TGW is a metered, quota-bound service sitting on your critical path. It bills per attachment-hour and per gigabyte processed, its route tables have hard limits, and its bandwidth per attachment (currently up to ~100 Gbps aggregate, but ~5 Gbps per VPN tunnel and per-flow ceilings) shapes what workloads can ride it. Teams that treat TGW as 'a free wire in the sky' get surprised by data-processing charges that dwarf their compute bill and by throughput ceilings that throttle a single large flow. Understanding the meter and the limits is as important as understanding the routing.
The architecture: every piece explained
Top row: attachments. An attachment is how something connects to the TGW, and for a VPC attachment it is concretely a set of elastic network interfaces — one per Availability Zone you enable — that AWS places into a subnet you nominate in each AZ. Traffic from an instance destined outside its VPC follows the VPC subnet route table to the TGW ENI in its own AZ, then enters the gateway. This AZ affinity matters: if you don't attach the TGW in an AZ, instances there route cross-AZ to reach it, adding latency and inter-AZ charges. VPN and Direct Connect attachments bring on-prem and branch networks in over IPsec tunnels or dedicated fiber (via a Direct Connect gateway), learning routes through BGP. Peering attachments join two Transit Gateways, typically in different regions, over the AWS global backbone. Connect attachments layer GRE tunnels and BGP on top of an existing VPC or DX attachment so third-party SD-WAN and virtual routers integrate natively.
Middle row: the routing core. Each TGW has one or more route tables, and the two operations that define your topology are association and propagation. An attachment is associated with exactly one route table — that table decides where the attachment's outbound traffic can go. Propagation is the reverse direction: an attachment can propagate its own routes (the VPC's CIDR, or BGP-learned prefixes) into one or more route tables, advertising 'you can reach me here.' You can also add static routes and, crucially, blackhole routes that explicitly drop traffic to a prefix — useful for enforcing isolation but a common cause of mystery outages when left stale. Appliance mode is a per-attachment flag that changes how the TGW hashes flows: with it off, the gateway may send the two directions of a flow through different AZ interfaces, which breaks stateful firewalls that expect to see both halves; with it on, the TGW keeps a flow pinned to one appliance across its lifetime, which is mandatory for any centralized-inspection design.
Bottom rows: segmentation and reach. Segmentation is nothing more than deliberately grouping attachments across multiple route tables — a 'prod' table, a 'dev' table, a 'shared' table — so that association and propagation carve the estate into domains that can or cannot reach each other. Cross-region peering extends a single logical network across regions over the encrypted AWS backbone (no internet transit, no self-managed VPN), though remember peering is not transitive between three TGWs and requires static routes to the remote CIDRs since BGP propagation doesn't cross the peer. The ops strip names what actually breaks clusters at scale: route-table entry limits, attachment quotas per TGW, VPC flow logs and TGW flow logs for visibility, and the blackhole routes that both protect and sabotage you.
End-to-end flow
Follow a packet through a segmented landing zone. A payments service in the prod-app VPC needs to call a shared authentication service in the shared-services VPC, and separately reach an on-prem fraud-scoring system over Direct Connect. Three route tables exist on the regional TGW: prod, shared, and onprem. The prod-app attachment is associated with the prod route table and propagates its CIDR into shared and onprem. The shared-services attachment is associated with shared and propagates into prod. The Direct Connect attachment is associated with onprem and propagates the on-prem prefixes into prod.
The instance sends a packet to the auth service's IP. Its VPC subnet route table has a route for the shared-services CIDR pointing at the TGW, so the packet egresses to the TGW ENI in the instance's AZ. Inside the gateway, the packet is evaluated against the prod route table (because that's what the sending attachment is associated with). That table contains the shared-services CIDR — propagated in from the shared attachment — pointing back out the shared-services attachment. The packet lands on the shared-services TGW ENI, enters that VPC, and its subnet route table delivers it to the auth instance. The return packet traverses the mirror path: shared-services association → shared table → prod CIDR route → back to prod. Note what did not happen: the prod table has no route to the dev VPC's CIDR, so a compromised prod host physically cannot route to dev. Isolation is structural, not a security-group hope.
Now insert a firewall. Compliance requires all prod-to-onprem traffic to pass a stateful inspection appliance living in a security VPC. You add that VPC as an attachment with appliance mode enabled, and adjust routes so the prod table's route to on-prem points at the security attachment, and the security VPC's internal routing sends traffic through the firewall and back to the TGW toward on-prem. Because appliance mode is on, the TGW hashes the whole flow to one firewall ENI and keeps both directions there — so the firewall sees the full bidirectional conversation and its state table stays consistent. Had appliance mode been off, the reply might arrive on a different AZ's TGW interface, hash to a different firewall node, be dropped as an unknown flow, and produce the classic 'intermittent connection resets that only happen across AZs' incident.
Finally, extend to a second region. A DR region has its own TGW, peered to the primary. To let prod-app reach a replica in the DR region you add a peering attachment and — because peering does not carry BGP propagation — static routes on each side: the primary prod table gets the DR CIDR pointing at the peering attachment, and vice versa. Traffic now rides the encrypted AWS backbone between regions with no public internet exposure. Every hop in this journey — VPC to TGW, table lookup, attachment to attachment, firewall pinning, cross-region peer — is a place where a missing or stale route turns reachability into a black hole, which is exactly why the failure modes below dominate real operations.