Amazon AWS SAA-C03: Transit Gateway Architecture Patterns
AWS Transit Gateway is a regional network transit hub that connects VPCs, VPNs, Direct Connect gateways, peering attachments, and supported network integrations through centralized route tables. Its architectural value is not merely fewer VPC peering connections. Transit Gateway creates a policy point where route-table associations and propagations can segment environments, share services, insert inspection, and connect hybrid networks without turning every VPC into a mesh.
Each attachment associates with one transit gateway route table for traffic leaving that attachment, while routes from attachments can propagate into one or more route tables. Static routes and prefix-list references add explicit control. This association/propagation model is the foundation for segmentation patterns such as production, nonproduction, shared services, inspection, or isolated partner networks.
Transit design belongs inside AWS Architecture in Practice.
Use Transit Gateway when the network has real transit
Small environments can remain simpler with direct VPC peering or other targeted connectivity.
transit patterns is a pattern, not an automatic default.
Transit Gateway becomes valuable when many networks need shared routing policy, hybrid connectivity, centralized services, or future growth beyond manageable peer-to-peer relationships.
Use route tables for segmentation
An attachment’s associated route table controls where traffic from that attachment can go.
Propagations decide which attachment routes appear in other route tables.
A common pattern gives production, nonproduction, and shared-services attachments different route tables so each environment sees only intended destinations.
Separate shared services from universal trust
DNS, directory services, patching, logging, inspection, and other common platforms can be placed in shared-service VPCs.
Private connectivity should still apply least access; connection to a transit hub does not mean every spoke should route to every shared system.
Use route-table segmentation plus security groups and application authorization to keep the shared network from becoming a flat enterprise LAN.
Use appliance mode for stateful inspection
AWS documents appliance mode for VPC attachments that contain stateful network appliances.
Appliance mode keeps a flow in the same Availability Zone for that appliance attachment and helps preserve symmetric traffic through stateful inspection.
Without the correct mode and subnet design, return traffic can traverse a different appliance path and break stateful sessions.
Integrate Direct Connect deliberately
Transit Gateway can connect to on-premises networks through a Direct Connect gateway.
TGW and Direct Connect should be designed around advertised prefixes, segmentation, route scale, and which VPCs are allowed to reach the corporate network.
Central hybrid attachment can simplify connectivity while increasing the blast radius of one incorrect route advertisement.
Plan inter-Region peering
Transit Gateway peering can connect transit gateways in different AWS Regions.
Inter-Region routes remain explicitly managed and the application still needs regional service/data architecture.
Do not treat TGW peering as automatic multi-Region application resilience; it provides network reachability between regional transit domains.
Watch route scale
Large enterprises can propagate thousands of VPC, VPN, and on-premises prefixes into transit tables.
Use summarized addressing, prefix lists, and clear ownership so route tables remain understandable and within current quotas.
Overlapping VPC CIDRs complicate or prevent straightforward routing and should be addressed in the network-planning stage.
Design Availability Zone attachments correctly
VPC attachments use selected subnets in Availability Zones to connect the VPC to Transit Gateway.
Architecture should include the AZs where workloads need transit and understand how traffic reaches the attachment ENI.
A regional transit hub still depends on correct VPC route tables, subnets, and failure-domain design inside every spoke.
Operate Transit Gateway through route evidence
When traffic fails, inspect the source VPC route, transit route-table association, propagated/static TGW route, target VPC route, security controls, and return path.
For SAP-C02, the durable pattern is attachments → associations → propagations → segmentation → inspection/hybrid services → route scale → return-path verification.
Transit Gateway is most useful when it reduces network complexity without hiding routing intent.
Address planning becomes more important when Transit Gateway centralizes connectivity because overlapping CIDRs can prevent ordinary routing between attachments. Enterprises should allocate VPC ranges from an IPAM strategy early and reserve space for growth, acquisitions, and secondary Regions. NAT can bridge some overlaps but adds complexity that a clean address plan avoids.
Transit Gateway route-table associations are a security architecture tool as much as a networking feature. A production attachment can associate with a route table that contains only shared services and approved hybrid prefixes, while a separate nonproduction table includes different spokes. Segmentation remains explicit even though every VPC uses the same transit gateway.
Propagation should be reviewed separately from association. An attachment can associate with one table but propagate its routes into several. This flexibility enables shared services but also creates the possibility that one VPC becomes reachable from more environments than intended. Maintain a route-intent matrix for important attachments.
Blackhole static routes can intentionally prevent traffic to a prefix even when a propagated route might otherwise appear. Use them as controlled segmentation tools where appropriate and document why the route exists; unexplained blackholes are difficult to distinguish from outage-causing configuration.
Appliance VPC design typically needs dedicated TGW attachment subnets and careful routes that steer traffic through firewalls without loops. The inspection VPC should be highly available across required Availability Zones, and stateful appliances should use appliance mode when the vendor pattern depends on symmetric flow handling.
Gateway Load Balancer can complement Transit Gateway for scalable virtual appliance fleets. In such patterns, Transit Gateway provides network transit while GWLB distributes traffic to security appliances. The architecture should follow vendor and AWS reference designs because return routing, GENEVE encapsulation, and state symmetry matter.
Direct Connect gateway integration should specify which Transit Gateway route domains can reach on-premises. Centralizing Direct Connect through one transit gateway can simplify hybrid networking, but a mistaken route propagation can expose a development VPC to sensitive corporate networks immediately.
Site-to-site VPN attachments can provide branches or backup hybrid connectivity. Dynamic BGP routes from VPN can propagate into TGW route tables, but route preference and failover between VPN and Direct Connect should be intentional and tested under circuit loss.
Transit Gateway peering does not propagate routes automatically across peer route tables. Inter-Region static routes must be configured according to the desired design, which can be an advantage because it prevents accidental full-mesh reachability between regions.
Shared services should avoid becoming one availability zone dependency. DNS resolvers, firewalls, directory services, and egress stacks in centralized VPCs need multi-AZ architecture and adequate capacity because their failure can affect many spokes simultaneously.
Flow Logs and Network Manager can improve visibility into centralized routing, but route-table exports and effective VPC routes remain valuable during troubleshooting. An operator should be able to follow one packet from source subnet route to TGW table to target attachment and back.
Cost should be included in topology. Transit Gateway charges for attachments and data processing, and centralized egress or inspection can create additional NAT, firewall, or cross-AZ costs. A mesh-reduction benefit can still be expensive if every byte takes an unnecessary transit path.
Multi-account ownership should be explicit. AWS RAM can share a Transit Gateway with other accounts while a central network account owns the transit service. Workload teams should know which routes they control in their VPC and which central routes require network-team approval.
Change testing should include route propagation and isolation. After adding a spoke, verify it can reach intended shared services and cannot reach prohibited environments. Negative routing tests are as important as successful pings in a segmented enterprise network.
A mature Transit Gateway architecture is not “all VPCs attached.” It is an intentional set of routing domains with known owners, inspectable propagation, protected shared services, hybrid boundaries, and route-scale headroom that can grow without turning AWS into one flat network.
Transit Gateway multicast, Connect attachments, and other specialized features should be added only when the workload requires them. A core enterprise routing design is easier to operate when uncommon capabilities remain isolated instead of expanding the standard architecture unnecessarily.
Quota monitoring should include attachments, route tables, routes, and prefix limits before expansion projects start. Acquisitions or large spoke onboarding can consume capacity quickly; quota planning is cheaper than emergency transit redesign after a hard service limit is reached.
Keep architecture diagrams synchronized with actual TGW tables and attachments. Central networking becomes risky when the diagram says production is isolated but the route table has accumulated exceptions over years of changes.
Transit Gateway sharing through AWS Resource Access Manager should use an onboarding process that records account, attachment, route-table association, propagated prefixes, owner, and required isolation tests. This keeps cross-account growth from becoming informal transit access.
Security groups and network ACLs still enforce traffic inside VPCs after Transit Gateway routing succeeds. Network reachability and application authorization should remain separate layers so the central hub does not become a substitute for workload security.
For critical hybrid paths, include TGW behavior in disaster-recovery tests. A recovery VPC can be healthy but unreachable if its attachment, inter-Region route, Direct Connect gateway, or DNS path was never added to the DR design.
Review transit architecture after every major account, region, acquisition, or inspection change so routing domains remain simpler than the VPC mesh they replaced.