AWS Transit Gateway simplifies multi-VPC and hybrid connectivity by replacing many point-to-point links with a hub, but the routing model becomes more important as the number of attachments grows. At small scale, a single route table may appear convenient. At enterprise scale, route-table associations, propagations, static routes, blackholes, peering, appliance paths, and Direct Connect integration determine whether the hub enforces segmentation or quietly becomes a flat network.<\/p>\n
The current AWS Certified Advanced Networking \u2013 Specialty (ANS-C01)<\/a> exam includes Transit Gateway, multi-account and multi-Region routing, hybrid connectivity, and network operations. Candidates should be able to reason from an attachment to its associated route table, understand which destinations are propagated, and predict the path that wins when static and propagated routes overlap.<\/p>\n A Transit Gateway attachment connects a VPC, VPN, peering relationship, or other supported network to the transit hub. The attachment is associated with one Transit Gateway route table for route lookup. It can also propagate its learned or attached routes into one or more route tables depending on the architecture. These two actions\u2014association and propagation\u2014are often confused, and that confusion causes many routing mistakes.<\/p>\n Association answers \u201cwhich route table does traffic from this attachment consult?\u201d Propagation answers \u201cwhich route tables should learn routes that this attachment represents?\u201d A spoke VPC might be associated with a restricted route table while propagating its CIDR into an inspection or shared-services table. Draw these relationships explicitly instead of relying on the console\u2019s default route table behavior.<\/p>\n The network segmentation<\/a> principle becomes a routing-table design problem at Transit Gateway scale. Security boundaries should be visible in the tables themselves, not only in a spreadsheet describing what teams intend.<\/p>\n Route-table naming should reflect policy, not attachment count. Names such as Production-Spokes, Inspection, Shared-Services, and Hybrid-Egress make reviews easier than generic numbered tables. Tagging can also drive automation that validates whether an attachment is associated with the route domain allowed for its account or organizational unit.<\/p>\n Separate Transit Gateway route tables can represent production, development, shared services, inspection, partner networks, or business units. Attachments in one domain do not need to learn direct routes to another. Instead, traffic can be sent through an inspection attachment, shared-services VPC, or controlled egress path before reaching a different zone.<\/p>\n Do not create more tables than the team can operate. Excessive micro-segmentation can produce hundreds of nearly identical route tables and fragile propagation rules. Group attachments that share the same trust and connectivity policy. The route table should express a meaningful network domain, not become a per-VPC object that defeats central routing.<\/p>\n Default association and default propagation settings are convenient during initial deployment but risky in mature environments. Disable or tightly control defaults when new attachments must not automatically join the broadest route domain. An attachment that is created today should not gain enterprise-wide reachability just because nobody remembered to change two checkboxes.<\/p>\n Overlapping destinations deserve explicit handling. A static route may be intentionally more specific than a propagated route to force one application through inspection or a partner link. Capture those exceptions in documentation and tests. Otherwise a later engineer may \u201csimplify\u201d the table by removing the route that was enforcing a critical traffic path.<\/p>\n Transit Gateway route tables can contain propagated routes from attachments and static routes configured by administrators. Static routes can deliberately steer traffic to an inspection VPC, VPN, peering attachment, or blackhole. When multiple routes match, longest-prefix match is fundamental, so a more-specific route can override a broader default even if the broader route represents the preferred architecture.<\/p>\n Blackhole routes are useful for enforcing isolation or preventing a less-specific route from attracting traffic that should not be reachable. They should be documented because an operator troubleshooting a \u201cmissing path\u201d may otherwise see the destination prefix and assume the table is incomplete. A blackhole can be an intentional security control rather than a failed propagation.<\/p>\n Summarization reduces route count but changes failure behavior. If a summarized static route points to an attachment that cannot reach every contained subnet, the hub can black-hole specific destinations. Advertise or configure aggregates only where the downstream network truly owns the whole range or where more-specific exceptions are deliberate.<\/p>\n Hybrid propagation can also expose route-scale issues. On-premises networks may advertise thousands of prefixes that are operationally unnecessary for most VPCs. Summarize where possible and propagate only what each route domain needs. Reducing route volume improves auditability and lowers the chance that a new on-premises prefix unexpectedly becomes reachable across every AWS account.<\/p>\n Direct Connect and Site-to-Site VPN frequently connect through Transit Gateway. A Direct Connect gateway can associate with Transit Gateways through transit virtual interfaces, while VPN attachments can terminate directly on Transit Gateway. The route-table design determines which VPCs can use those hybrid paths and which on-premises prefixes they learn.<\/p>\n Keep hybrid route domains intentional. Development VPCs may need only shared build services on premises, while production VPCs need business systems and data centers. Propagating every on-premises prefix into every Transit Gateway table is operationally simple but can defeat segmentation and increase the blast radius of route leaks.<\/p>\n Use BGP policy and Transit Gateway policy together. The route received from Direct Connect or VPN must be accepted at the hybrid edge and then propagated into the correct Transit Gateway tables. Troubleshoot each layer separately. The BGP attribute<\/a> decision explains which hybrid route reaches the gateway; the Transit Gateway route table explains which attachment traffic uses after it enters the AWS transit domain.<\/p>\n Centralized firewalls require Transit Gateway routing that forces selected traffic through the inspection attachment. Spoke route tables can point broad destinations toward inspection, and the inspection-side table can route approved traffic onward. If spokes learn direct routes to each other, they can bypass the firewall even though the inspection VPC is fully deployed.<\/p>\n Enable appliance mode on the inspection VPC attachment when stateful appliances require symmetric handling. Appliance mode helps Transit Gateway keep flows mapped through the appropriate network interface in the appliance VPC. The rest of the architecture still needs correct forward and return routes; appliance mode cannot compensate for a direct bypass route.<\/p>\n Make inspection failures visible. If the security VPC becomes unreachable, decide whether traffic should fail closed or whether a documented bypass exists for specific emergency cases. An undocumented emergency static route can become permanent technical debt and silently undermine the security architecture after the incident ends.<\/p>\n Attachment lifecycle must be automated as accounts are created and retired. Orphaned Transit Gateway attachments and propagated routes can persist after workloads disappear, making the network graph look larger than reality. Include detachment, propagation removal, and route cleanup in account decommissioning so stale connectivity does not survive as hidden infrastructure.<\/p>\n Transit Gateway can be shared across accounts using AWS Resource Access Manager. A central networking account may own the gateway and route tables while application accounts create VPC attachments. This model centralizes the routing policy without requiring the network team to own every VPC.<\/p>\n Define who approves attachments, who selects the route table association, and who controls propagation. An application team should not be able to attach a VPC to a protected production route domain solely because it can create the attachment. Tags, automation, and approval workflows can map account metadata to the allowed Transit Gateway policy.<\/p>\nTreat attachments and route tables as separate design objects<\/h3>\n
Use multiple route tables to create routing domains<\/h3>\n
Understand static, propagated, and blackhole routes<\/h3>\n
Route hybrid traffic through the correct gateway chain<\/h3>\n
Design centralized inspection as a first-class route domain<\/h3>\n
Scale across accounts with AWS RAM and clear ownership<\/h3>\n