Amazon ANS-C01: Transit Gateway and Network Topology — Study Guide
Part of the AWS Advanced Networking Specialty ANS-C01 — Study Guide. Practice with verified answers in the Amazon exam hub, or take timed practice tests on ExamRoll.io.
Core concepts
AWS Transit Gateway (TGW) is a regional network transit hub that centralizes routing between Amazon VPCs, VPNs, Direct Connect gateways, and other Transit Gateways. At its simplest, a TGW acts as a routing plane: you create attachments (for example with the EC2 API call CreateTransitGatewayVpcAttachment for VPCs, CreateTransitGatewayAttachment for appliances, or CreateTransitGatewayPeeringAttachment for peering) and then control how those attachments exchange routes by associating and propagating into one or more Transit Gateway route tables. Route tables on a TGW provide the isolation and segmentation primitives that let the TGW act like multiple virtual routers (VRFs). For each attachment you decide which TGW route table it is associated with (using AssociateTransitGatewayRouteTable) and which attachments propagate their routes into which tables (via the route table propagation settings). The TGW forwards packets based on longest-prefix match across all route tables that the source attachment is associated with, so careful design of association/propagation boundaries is how you implement hub-and-spoke, segmented hubs, or partial meshes.
Transit Gateway peering creates an encrypted, private inter-region or inter-account path between TGWs that still relies on route table configuration to enable traffic flow. You create the peering with CreateTransitGatewayPeeringAttachment from the requester side and then AcceptTransitGatewayPeeringAttachment on the accepter side; after that you must add routes to the appropriate TGW route tables so the peering attachment is used. The peering is not transitive: traffic will not flow from TGW-A to TGW-C via TGW-B unless explicit peering and route table mappings permit it. TGW also supports Connect attachments for high-performance connectivity to SD-WAN or third-party appliances, created with the CreateTransitGatewayConnect API, which enables encapsulation (GRE, VXLAN) and high-throughput forwarding to specialized devices.
Key services and configuration
Configure VPC attachments using CreateTransitGatewayVpcAttachment and be sure to set the attachment options you need: for example, enable ApplianceModeSupport on VPC attachments that forward traffic to network appliances so the TGW keeps the original destination when sending traffic to the appliance. After creating attachments, use CreateTransitGatewayRouteTable to create additional TGW route tables beyond the default, then call AssociateTransitGatewayRouteTable and enable propagation for chosen attachments so their prefixes appear in the route table. For multicast use cases, create a multicast domain with CreateTransitGatewayMulticastDomain, then AssociateTransitGatewayMulticastDomain for the attachments that will participate and use RegisterTransitGatewayMulticastGroupMembers and RegisterTransitGatewayMulticastGroupSources to establish group membership and sources; multicast domains are separate from unicast route tables and are required for IGMP-style group delivery across VPCs and appliances.
For global topology visibility and policy enforcement use AWS Transit Gateway Network Manager (part of AWS Network Manager). Create a Global Network in Network Manager (console or networkmanager:CreateGlobalNetwork) and register Transit Gateways so you gain a north/south view across regions and on-prem connections. Network Manager provides automated performance monitoring, core-periphery visualizations, and route analytics; it can ingest CloudWatch metrics and VPC flow logs and correlate them with TGW attachments and VPN/Direct Connect links. Integration with AWS Resource Access Manager (RAM) lets you share a centrally managed TGW with other AWS accounts using CreateResourceShare and the appropriate principal attachments; remember to set the TGW option AutoAcceptSharedAttachments or manage acceptances programmatically.
Design patterns and trade-offs
A hub-and-spoke topology implemented with a single Transit Gateway is the most common pattern for multi-VPC multi-account architectures because it centralizes connectivity, simplifies route distribution, and enables consolidating shared services, security appliances, and on-prem connectivity. Use one or more TGW route tables to provide segmentation between business units: associate spokes with a spoke-specific route table and propagate shared-service prefixes only into the tables that should see them. The trade-off is that centralization can become a single chokepoint for traffic and a single blast radius for misconfiguration; large east-west flows through the TGW may require careful traffic engineering, deployment of Connect attachments for high-throughput appliances, or placement of regional TGWs to keep traffic local.
A full mesh (pairwise peering between TGWs or many VPC peering links) provides direct connectivity and reduces dependence on a central hub for some traffic patterns, but it introduces operational complexity as the number of links grows and complicates security policy enforcement across many administrative domains. Transit Gateway peering (CreateTransitGatewayPeeringAttachment + AcceptTransitGatewayPeeringAttachment) allows inter-region backbone connectivity with encryption across the AWS global network and is useful when you want regional isolation plus some shared services, but you must manage route table mappings explicitly and accept that peering is not transitive. You can combine patterns: a regional hub-and-spoke TGW per region and peering between hubs for cross-region traffic often balances scale, latency, and failure domains.
When integrating on-premises networks, attach the Direct Connect Gateway to the TGW using the Direct Connect association features (configure a private virtual interface on Direct Connect and create an association with the TGW via the Direct Connect console or API). Consider whether to use route-based VPNs (BGP over IPSec) for dynamic routing or static routes for tightly controlled flows. For appliance-based inspection and mutual TLS termination use cases, avoid terminating TLS at a central appliance if end-to-end encryption is required between clients and backends; instead perform TLS termination at the application layer (for example, at pods in EKS) and use TGW routing to front traffic through an ALB or Network Load Balancer that preserves client IPs with Proxy Protocol or use the ALB X-Forwarded-For headers.
Common pitfalls and decision criteria
A common operational mistake is assuming TGW provides implicit segmentation; it does not. You must explicitly create and associate route tables and enable propagation to control which attachments can reach which prefixes. Another frequent pitfall is misconfiguring security groups and NACLs: TGW only handles routing, so all VPC security groups and NACLs still apply and must be aligned with the intended end-to-end connectivity. Expect that stateful security groups are evaluated at the instance or load balancer; if you need client IP preservation across TLS termination at the ALB, enable the ALB’s X-Forwarded-For and, for Network Load Balancers, preserve source IP by using target type IP and proxy-protocol where required.
Scale decisions often hinge on traffic volume and administrative boundaries. Centralizing many high-throughput flows through a single TGW can complicate performance and outage recovery; use Transit Gateway Connect attachments for high-bandwidth appliance links, consider multiple TGWs with peering for isolation, and use Network Manager to monitor and trigger alarms on saturation. Always review soft limits for the number of attachments, route tables, and multicast domains and request increases where necessary rather than relying on default quotas.
Practical Problem: Use-Case Scenario
Company: Atlas Financial Services. Challenge: Atlas must connect ten business unit VPCs in us-east-1 to a central shared-services VPC, enforce least-privilege network access between units and shared services, scale to dozens more business units over time, and provide per-business-unit traffic accounting to troubleshoot bursts that occasionally saturate their Direct Connect link.
Approach (numbered):
- Provision a regional Transit Gateway with CreateTransitGateway and create a dedicated Transit Gateway route table for each business unit plus one for shared services using CreateTransitGatewayRouteTable; this enables per-unit segmentation without VPC peering explosions.
- Attach each business unit VPC via CreateTransitGatewayVpcAttachment and AssociateTransitGatewayRouteTable to the per-unit route table; attach the shared-services VPC and associate it only with the shared-services route table.
- Enable propagation selectively: have each business unit attachment propagate into its own route table and have the shared-services attachment propagate its prefixes into a separate shared-services table; then add static routes in each unit’s route table that point to the shared-services attachment for the allowed prefixes, enforcing least privilege by not propagating unit prefixes into the shared-services table.
- Share the TGW with other AWS accounts using AWS RAM (CreateResourceShare) so onboarding a new business unit is a VPC attachment and a route table association, minimizing admin overhead.
- For traffic accounting and troubleshooting, enable Flow Logs on the TGW and associated VPCs, and onboard the TGW to AWS Network Manager (CreateGlobalNetwork and register the TGW) to visualize topology and monitor bandwidth. Correlate TGW flow logs and CloudWatch metrics to identify which attachment is causing Direct Connect saturation.
- If Direct Connect capacity is saturated during predictable peaks, create a Direct Connect Gateway and use Direct Connect association to the TGW; implement per-business-unit route tagging and, if needed, configure routing policies (on-prem BGP communities or route filters) at the Direct Connect gateway to limit or shape traffic per unit.
AWS rationale: Using a TGW with per-unit route tables provides strong segmentation and scales linearly as more units are added without peer-to-peer complexity. Sharing the TGW with AWS RAM minimizes cross-account management. Selective propagation and static route entries enforce least privilege at the routing plane while security groups and NACLs enforce access at the instance level. Flow logs plus Network Manager provide the visibility necessary to pinpoint which attachment or business unit is saturating Direct Connect so Atlas can apply quota controls or request capacity increases targeted to the offending unit.
← Hybrid Connectivity: VPN and Direct Connect · All domains · DNS and Route 53 →
Practice these questions → · Timed practice on ExamRoll.io →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Pass your exam →