AWS Transit Gateway route tables can be used as routing domains that segment groups of VPC, VPN, Direct Connect, peering, and other supported attachments. The useful mental model is similar to virtual routing and forwarding: an attachment sends traffic into one associated transit gateway route table, and that table determines which destination attachment receives the packet. Separate route tables let the same transit gateway support different trust and connectivity domains.
For teams designing AWS Architecture and Operations, this is more than a scaling convenience. Route-table association and propagation become segmentation controls. Amazon AWS SAA-C03 candidates should understand how those controls differ from VPC route tables and why a route being known to the transit gateway does not automatically mean every attachment can use it.
Association selects the table used for traffic entering from an attachment
Each transit gateway attachment can be associated with one transit gateway route table. When a packet enters through that attachment, the associated table is the lookup domain used to decide the next hop. This makes association an ingress routing decision: it answers which policy table governs traffic coming from that VPC, VPN, or other attachment.
One route table can be associated with many attachments, so a group of VPCs can share a common routing domain. Development VPCs might share one table while production VPCs use another. The transit gateway itself is shared, but the route lookup context differs by source attachment.
The design relationship to VPC subnets and route tables is important. The VPC route table decides whether traffic leaves the VPC through the transit gateway attachment. Once the packet reaches the transit gateway, the attachment’s associated transit gateway route table makes the next routing decision.
Propagation controls which attachment routes appear in which tables
Association and propagation are separate. An attachment can be associated with one route table while propagating its routes to one or more route tables. For a VPC attachment, VPC CIDR blocks can be propagated. For VPN or Direct Connect-related dynamic routing, learned BGP routes can be propagated into selected transit gateway route tables.
This creates useful one-way knowledge patterns. A spoke VPC can use a spoke route table that knows only shared services and egress destinations, while the shared-services table can learn all spoke CIDRs. The fact that a route is propagated into one table does not cause it to appear automatically in every other table.
That separation is the foundation of Transit Gateway segmentation. If every attachment is associated with the default table and propagates everywhere, the design behaves like one large flat routing domain. Multiple tables create value only when associations and propagations intentionally express who needs to reach whom.
Design domains around communication policy, not organization charts
A common pattern is to create domains such as production, non-production, shared services, inspection, and on-premises. Those names are useful only if they correspond to different routing requirements. Two business units that are organizationally separate but need identical connectivity may not need separate route domains, while two workloads in the same team may need isolation because one handles regulated data.
The broader hybrid AWS networking design should start from allowed flows. Which VPCs need east-west connectivity? Which must reach on-premises? Which should reach only centralized DNS, identity, logging, or egress services? Which traffic must pass through inspection? Build route domains from those flows.
This avoids a common failure mode where route tables are created per account or per team without a clear traffic policy. The result can be many route tables that still propagate everything to each other, adding operational complexity without meaningful isolation.
Use static and blackhole routes to express exceptions deliberately
Transit gateway route tables can contain propagated and static routes. Static routes are useful for explicit next hops, including centralized egress, inspection, or backup paths. Transit gateway route tables can also contain blackhole routes that intentionally drop traffic matching a prefix.
Blackhole routes can reinforce segmentation by denying a more specific destination even when a broader route would otherwise match. As with any routing policy, specificity and evaluation order matter. Operators should document why a static or blackhole route exists because unexplained exceptions become difficult to troubleshoot later.
The mental model in IP route selection still applies: routing follows the best matching destination, not the human intention written in an architecture document. Route-domain design needs to be validated against actual prefixes.
Centralized inspection changes the return-path problem
A shared inspection VPC is a common Transit Gateway architecture. Traffic from a spoke is routed to an inspection attachment, passes through stateful appliances, and then continues toward another domain or egress path. The difficult part is not drawing the firewall in the middle; it is preserving symmetric flows so the stateful appliance sees both directions.
AWS Transit Gateway appliance mode is designed for stateful appliance VPC attachments. When enabled, the transit gateway maintains Availability Zone affinity for the lifetime of flows in the relevant scenarios, helping return traffic traverse the same appliance path. Without correct appliance-mode and route-table design, return traffic can take a different path and be dropped by a stateful device that never saw the original flow.
Inspection route domains should therefore be modeled as complete forward-and-return paths. Check the spoke VPC route, the spoke attachment association, propagation into the inspection table, inspection VPC subnet routes, post-inspection transit routing, and the reverse direction. One correct transit gateway table does not guarantee end-to-end symmetry.
Hybrid BGP routes need propagation discipline
VPN and Direct Connect connectivity can propagate dynamically learned routes into transit gateway route tables. That makes hybrid reachability scalable, but it also means on-premises route changes can affect cloud routing without a static change in the transit gateway console. Decide which domains should learn those routes and which should remain isolated.
The BGP path-selection model is useful background because hybrid routing depends on both what prefixes are learned and how the surrounding network chooses paths. Transit Gateway route tables do not replace the routing policy on customer gateways or Direct Connect routers.
For VPN-heavy architectures, VPN design constraints also matter. Redundant tunnels and propagated routes can improve resilience, but asymmetric advertisements or unintended propagation can expose one domain to destinations that were not part of the security design.
Peering and overlapping address space require extra care
Transit gateway peering uses static routes rather than dynamic route propagation across the peering attachment. That means inter-Region or inter-transit routing requires explicit route management. Operators need to understand which prefixes are reachable through each peer and how changes are coordinated across both sides.
Overlapping VPC CIDRs create an even more fundamental problem because routing cannot distinguish two destinations represented by the same prefix in the same domain. Segmentation can sometimes keep overlaps isolated, but shared services and on-premises access become difficult. Address planning remains one of the cheapest ways to reduce future Transit Gateway complexity.
If overlap already exists, route domains should make the constraint explicit rather than hiding it behind broad propagations. Network address translation or architectural separation may be required before previously isolated domains can communicate safely.
Operate route domains as policy objects
Large Transit Gateway environments need change control, route export, and automated validation. AWS allows transit gateway route tables to be exported to S3, which can support offline analysis and evidence collection. Infrastructure as code can make associations, propagations, and static routes reviewable before deployment.
Validation should test allowed and denied flows, not only whether attachments are in an Available state. Reachability analysis, flow logs, appliance logs, BGP telemetry, and route-table snapshots each answer different questions. A route-domain change that accidentally enables production-to-development traffic is a policy regression even if no service reports an error.
The strongest Transit Gateway design keeps association, propagation, static routes, and inspection behavior understandable as one policy model. Route tables become domains only when they intentionally control connectivity. When every propagation is explicit and every exception has a reason, a single transit gateway can scale to many networks without turning into one flat, difficult-to-audit routing fabric.
Default association and propagation settings deserve explicit review because they influence how new attachments enter the routing design. In tightly segmented environments, operators should know whether a newly created attachment will use a default route table or propagate routes automatically before application-specific policy is applied. The safe operating model is to make attachment onboarding predictable and to validate the intended association and propagation state as part of deployment.
Route-domain testing should include negative cases. It is not enough to prove that production can reach a shared DNS service; the test plan should also prove that production cannot reach a development-only prefix, that an isolated VPC cannot bypass inspection, and that on-premises advertisements do not appear in unauthorized domains. Those denial tests turn segmentation from an architectural assumption into an observable control.
Change review becomes easier when each route table has a short statement of purpose and a defined owner. A diff that adds a propagation from an application attachment into a shared-services table then has a clear policy meaning rather than appearing as an isolated route change. Naming conventions, infrastructure-as-code modules, and route exports should preserve that context so operators can distinguish intentional connectivity from drift during incidents and audits.
