AWS Transit Gateway can connect many VPCs and hybrid attachments through one regional routing hub, but central connectivity does not mean every network should be able to reach every other network. Transit Gateway route tables let architects create routing domains that control which attachments can send traffic toward which destinations. Association and propagation are the two mechanisms that make those domains work.
In AWS architecture, this becomes a segmentation problem as much as a routing problem. The goal is to centralize connectivity without accidentally flattening security boundaries. A well-designed Transit Gateway can support shared services, isolated application tiers, inspection paths, and hybrid connectivity while keeping the intended reachability explicit.
Association and propagation control different sides of routing policy
Each Transit Gateway attachment can be associated with one Transit Gateway route table at a time. That associated table is the table used to route traffic arriving from the attachment. In practical terms, association selects the routing policy for the source. If a production VPC is associated with a production route table, the routes in that table define where traffic from that VPC can be forwarded through the transit gateway.
This is different from a VPC subnet route table, but the mental model from VPC routing is still useful: route selection is directional. The fact that one side has a route to another network does not automatically prove the return path or the security policy allows the conversation.
Route propagation controls whether routes from an attachment are inserted into a Transit Gateway route table. An attachment can propagate its routes to multiple route tables even though it is associated with only one. That asymmetry is powerful because a shared-services VPC can publish its prefixes to several routing domains without making those domains mutually reachable.
Designers should draw propagation explicitly instead of assuming the transit gateway will behave like a single flat routing table. A route table for isolated workloads might learn only shared services and on-premises prefixes, while a flat development domain might learn the routes of peer development VPCs. The route tables are therefore policy objects, not merely containers for prefixes.
Multiple route tables create routing domains
A routing domain is a group of attachments that share a reachability policy. One domain may permit east-west communication between application VPCs. Another may allow only north-south access to inspection and on-premises networks. A shared-services domain can publish DNS, directory, tooling, or logging services to multiple groups without allowing those groups to talk directly to each other.
Network segmentation depends on deliberate routing boundaries: permitted east-west paths must be explicit and reinforced by security controls rather than inferred from labels such as “prod” or “isolated.” Segmentation is not accomplished by naming a network “prod” or “isolated.” It is accomplished by controlling actual reachable paths and then reinforcing those paths with security controls. Transit Gateway route tables provide a scalable routing layer for that policy.
Shared services require asymmetric thinking
Shared services often need to be reachable from many spokes while spokes must remain isolated from each other. A useful design associates spoke VPCs with an isolated route table that contains routes to shared services and other approved destinations. The shared-services attachment can be associated with a different table that knows how to return traffic to each spoke.
That design is a routing version of hub-and-spoke networking. Centralization reduces the number of point-to-point connections, but it also creates concentration risk. The shared-services domain needs careful capacity planning, failure isolation, logging, and change control because a mistake can affect many spokes at once.
Inspection paths need routing on both sides of the appliance
Central inspection is a common reason to use Transit Gateway route domains. Workload traffic can be routed toward an inspection VPC before it reaches another VPC, the internet, or a hybrid network. The design must account for the forward and return paths, appliance behavior, and the need for symmetric routing where a stateful firewall requires it.
Adding a firewall does not automatically create microsegmentation. Transit Gateway route tables must force the relevant flows through the intended inspection path; an alternate route around that control point invalidates the segmentation claim. The routing design therefore has to prove where enforcement occurs for every permitted east-west path.
Static routes and propagated routes solve different problems
Propagation is useful when routes should follow attachment prefixes automatically. Static routes are useful when the desired path is not represented by straightforward propagation, such as a default route to an inspection attachment or a blackhole route that intentionally prevents reachability. Static entries can also provide controlled failover behavior when an architect deliberately manages the preference of alternate paths.
Route-table exports and inventory checks are valuable in larger environments because the intended policy can be difficult to infer from the console after dozens of attachments and propagations accumulate. Automation should validate that each attachment is associated with the correct domain and propagates only where expected. Routing drift is a security issue when an unintended propagation silently creates a path between networks that were meant to stay separated.
Hybrid connectivity extends the same domain model on premises
VPN and Direct Connect gateway attachments can participate in the same Transit Gateway route-table system. That makes it possible to decide which cloud domains can learn on-premises prefixes and which on-premises routes are advertised toward cloud attachments. Hybrid connectivity should therefore be modeled as part of the segmentation policy rather than as a separate edge project.
The broader idea from routing behavior is that reachability emerges from several cooperating route tables and devices. A route on the transit gateway is necessary but not sufficient. VPC route tables, on-premises routes, security groups, network ACLs, firewalls, and sometimes NAT behavior also determine whether a flow succeeds.
Overlapping CIDRs, default routes, and blackholes expose weak designs
Large Transit Gateway estates often become difficult when address plans overlap or when teams use broad default routes without documenting their intent. Transit Gateway does not make overlapping networks magically routable. If two attachments advertise indistinguishable prefixes, the architecture needs another boundary, a translation strategy, separate routing domains, or a redesign of the address plan. Allowing overlap to accumulate can turn later mergers or multi-account integrations into expensive network projects.
Default routes are equally powerful and dangerous. A route such as `0.0.0.0/0` can intentionally send all unmatched traffic to a centralized inspection or egress attachment, but it can also hide missing specific routes and create asymmetric return paths. Designers should understand which table owns the default, which attachments can use it, and whether the target path has routes back to every permitted source. Route priority and the longest-prefix-match rule still determine forwarding; a central hub does not replace those fundamentals.
Blackhole routes can be useful when the policy is to make a destination explicitly unreachable even if another route might otherwise be learned. They can reinforce isolation or prevent traffic from following an unintended fallback path. The operational benefit is clarity: a deliberate blackhole tells an investigator that the lack of reachability is policy, whereas an absent route may be a configuration error. In mature environments, route-table intent should be version-controlled and validated against a desired connectivity matrix so that new propagations cannot quietly dissolve segmentation.
Route-domain governance keeps intent from drifting
Change management is the final defense against accidental reachability. A new attachment should not be considered complete merely because it is connected to the transit gateway. Its association, propagations, expected prefixes, inspection path, and return routing should be reviewed as one unit. Automated tests can probe approved and forbidden flows from representative VPCs. That turns the connectivity matrix from a diagram into a verifiable contract and catches route-domain drift before it becomes an outage or segmentation failure.
Route domains also need naming and ownership conventions. A table called `shared` or `prod` is not a policy specification by itself. Document the intended source attachments, reachable destination classes, propagation rules, and inspection requirements next to the automation that creates the table. Clear ownership reduces the chance that a later network change treats an intentionally isolated table as an incomplete configuration and ‘fixes’ it by enabling broad propagation.
In multi-account organizations, network teams should also decide who is allowed to associate or propagate attachments. Central routing policy can be undermined if application accounts can independently change the controls that define their isolation. Resource sharing should therefore be paired with clear IAM boundaries and an approval path for routing changes. That control boundary should be tested just like the routes themselves, because administrative reach can dissolve segmentation even when the forwarding tables look correct.
SAA-C03: design the connectivity matrix first
For SAA-C03, remember the relationship: an attachment associates with one Transit Gateway route table, while its routes can propagate to multiple tables. Use separate route tables to build routing domains and control east-west reachability. Shared services and inspection designs often depend on asymmetric propagation rather than a single flat table.
The strongest answers begin with the required connectivity matrix. Decide which domains may communicate, which shared destinations every domain needs, where inspection belongs, and what hybrid routes should be visible. Then use Transit Gateway association, propagation, and static routes to implement that intent. Amazon AWS provides the routing primitives; the architecture comes from how deliberately they are combined.
