Transit Gateway hub-and-spoke
Hub-and-spoke connectivity with AWS Transit Gateway
One Regional router replaces a mesh of VPC peerings, and its route tables decide which spokes can talk.
The hub replaces the mesh
AWS Transit Gateway (TGW) is a Regional, Layer 3 virtual router. Packets are forwarded to a specific next-hop attachment based on the destination IP address, and the service scales elastically with traffic volume. Every VPC and every hybrid connection (Site-to-Site VPN, Direct Connect gateway) attaches to the same hub, so the entire Region's routing policy lives in one place instead of being smeared across dozens of point-to-point links.
Contrast this with connecting VPCs by peering. VPC peering is non-transitive: if A peers with B and B peers with C, A still cannot reach C through B. To give N VPCs full any-to-any reachability you therefore need a full mesh of N(N-1)/2 peering connections. Ten VPCs is 45 connections; every new VPC forces you to touch the route tables of all the others. With a Transit Gateway each VPC needs exactly one attachment, and a single gateway supports up to 5,000 attachments (default, adjustable), connecting thousands of VPCs in one Region while routing transitively through the hub.
The topology diagram shows the payoff: prod, dev, and shared-services spokes each carry a single attachment, and the same hub also terminates the Direct Connect gateway and the Site-to-Site VPN, so on-premises reachability is consolidated onto the identical control plane rather than bolted onto each VPC separately.
Attachments, associations, and propagations
An attachment is both a source and a destination of packets. Supported types include VPC, Site-to-Site VPN, Direct Connect gateway, Transit Gateway Connect (GRE + BGP for SD-WAN), transit gateway peering, VPN Concentrator, and network-function attachments. For a VPC attachment the gateway drops an elastic network interface into one subnet per enabled Availability Zone; resources can only reach the TGW in AZs where the attachment has a subnet.
Two independent mechanisms control reachability. Association: each attachment is associated with exactly one route table, and that route table decides the next hop for traffic arriving FROM that attachment. Propagation: an attachment's routes (a VPC's CIDR blocks, or the prefixes a VPN/Direct Connect gateway learns over BGP) can be installed into one or more route tables. You cannot filter which routes propagate. A brand-new transit gateway has one default route table that is simultaneously the default association route table and the default propagation route table, which is exactly why an out-of-the-box TGW behaves as a flat any-to-any router.
When a static route and a propagated route share the same destination CIDR, the static route wins and the propagated one is suppressed. Route evaluation always prefers the most specific prefix first, then applies a fixed attachment-type priority (static, then prefix-list, then VPC-propagated, then Direct Connect gateway, then Connect, then VPN, and so on). A static blackhole route is the deliberate way to drop matching traffic at the hub.
Segmenting spokes with route tables
The reason to build extra route tables is isolation. Each additional table acts like a VRF in a traditional router: associate development VPCs with one table and production VPCs with another, and the two groups can no longer route to each other because neither table carries a route to the other. Isolation here is achieved by omission, not by an access list. Transit Gateway route tables have no NACLs or security groups; if there is no matching route, the packet is dropped at the hub.
The shared-services pattern layers onto this cleanly, and the topology diagram traces it. Prod and Dev are each associated with their own route table that only contains a route to the Shared Services VPC, so both can reach shared resources (directory, DNS, patch/repo) while remaining blind to each other. The Shared Services attachment, meanwhile, is associated with a route table into which every spoke's CIDR is propagated, giving it return reachability to all of them. A single hub thus enforces partial connectivity that would be tedious and error-prone to reproduce with peering.
Two constraints shape the design. VPC CIDRs attached to one TGW must not overlap (TGW does not support ECMP across VPC attachments, precisely because their prefixes must be unique), so IP address planning up front is mandatory. And where you want an explicit, auditable drop rather than silent absence of a route, add a static blackhole route for the CIDR you want killed at the hub.
Appliance mode and centralized inspection
A common hub-and-spoke goal is to force east-west traffic through a central stateful firewall. You build an Inspection VPC with a firewall appliance in each Availability Zone, associate the spokes with a route table whose default route (0.0.0.0/0, static) points at the Inspection VPC attachment, and associate the Inspection attachment with a route table that has each spoke's CIDR propagated into it. The inspection diagram traces a full A-to-B hairpin through this design.
The subtle failure mode is asymmetry. By default a transit gateway keeps traffic in the Availability Zone it originated in. For a stateful appliance that is fatal: the forward packet may be inspected by the appliance in AZ1, but the return packet, hashed to the appliance in AZ2, hits a box that has never seen the flow and is dropped. Enabling appliance mode support on the Inspection VPC attachment fixes this: the TGW uses a flow-hash algorithm to pin each flow to a single appliance ENI for the life of the flow, and uses that same ENI for the return traffic, guaranteeing symmetric routing.
Two rules bound the design. You must connect exactly one transit gateway to the appliance VPC, because multiple gateways do not share flow state and so cannot guarantee stickiness. And enabling appliance mode on an existing attachment can change how that attachment's traffic is placed across AZs, so treat it as a routing change, not a toggle. AWS Network Firewall can also be attached to the TGW directly as a service-managed network-function attachment, which is created with appliance mode already enabled and supports static routing only.
Sharing across accounts with RAM, and the limits that matter
In a multi-account organization the transit gateway lives in a central Network Services account. You share it with the application accounts using AWS Resource Access Manager (RAM), within the same AWS Organization and the same Region. Once shared, each application account owns and creates its own VPC attachment to the hub, and a user in either account can delete that attachment. This keeps the routing hub under the network team's control while letting workload teams self-service their connections, with no peering connections required between accounts.
Because a transit gateway is Regional, you typically run one per Region and let AWS provide high availability by design, rather than deploying several for redundancy (though separate gateways are a valid way to shrink the blast radius of a misconfiguration). Reaching another Region is done with a transit gateway peering attachment, which supports static routing only and, like VPC peering, rides encrypted AWS backbone infrastructure.
Know the boundaries that constrain a growing hub: 5,000 attachments per TGW and 20 route tables per TGW (both defaults, adjustable), up to 10,000 combined routes across all of a gateway's route tables, and a maximum of one static route per prefix per attachment. MTU is 8,500 bytes for VPC, Direct Connect, Connect, and peering traffic but only 1,500 bytes over VPN, and migrating from VPC peering can drop jumbo frames if the two sides' MTUs mismatch. Finally, the hub is not free the way peering's hourly cost is: Transit Gateway adds a per-attachment hourly charge plus a per-gigabyte data-processing charge, so for a handful of VPCs a couple of peerings can be cheaper, while the hub wins decisively on operational simplicity as the VPC count climbs.
Sources
Practice what you just read