AWS Transit Gateway: Architecture, Routing Patterns, and Operations

Purpose of This Lesson

AWS Transit Gateway (TGW) provides a centrally managed network transit hub for connecting multiple VPCs, on-premises networks, and other networking attachments. This lesson focuses on recognizing when Transit Gateway is preferable to VPC peering, understanding its routing-table model, designing isolated or shared-services networks, and selecting the correct integrations for Direct Connect, VPN, SD-WAN, monitoring, and multicast.

Key Concepts

• Central hub: VPCs and external networks attach to a Transit Gateway instead of requiring direct connections to every other network.
• Transitive routing: Transit Gateway can route traffic between attached networks. VPC peering does not provide transitive routing.
• Attachments: A TGW can attach to VPCs, AWS Site-to-Site VPNs, Direct Connect gateways, third-party appliances, and Transit Gateways in other Regions or accounts.
• Availability Zone subnet selection: For a VPC attachment, specify one subnet in each Availability Zone where routing should be enabled.
• Transit Gateway route tables: Multiple TGW route tables can be used to control which attachments can communicate. This allows one Transit Gateway to behave like multiple isolated routers.
• Cross-account sharing: AWS Resource Access Manager (RAM) can share Transit Gateways across accounts.
• Transit VIF: A Direct Connect connection using a Direct Connect gateway to reach a Transit Gateway uses a Transit Virtual Interface (Transit VIF).
• TGW Connect: SD-WAN appliances connect to Transit Gateway Connect through GRE tunnels and BGP.
• Multicast: Transit Gateway supports multicast between subnets of attached VPCs, with membership defined at subnet and elastic network interface levels and managed using IGMP.

Transit Gateway Architecture and Routing

Why Transit Gateway scales better than a peering mesh

With four VPCs, a fully meshed VPC-peering design requires six VPC peering connections. Each additional VPC increases the number of point-to-point relationships and makes route-table management more difficult. If an on-premises network also connects through Site-to-Site VPN, each VPC needs its own connection in the peering-based design. Redundancy requires additional customer gateways and more VPN connections.

A Transit Gateway changes this pattern to a hub-and-spoke model. Each VPC attaches to the TGW, and the TGW provides the transit path between VPCs and connected on-premises networks. The result is fewer direct connections and a more manageable routing configuration while retaining scalable connectivity for many attachments.

VPC attachments

For a VPC attachment, select one subnet per Availability Zone in which the attachment should participate. The VPC route tables must direct non-local destinations toward the Transit Gateway. The TGW route tables then determine whether the destination attachment is reachable.

Transit Gateway can provide a unified routing point for:

• Multiple VPCs
• AWS Site-to-Site VPN connections
• Direct Connect through a Direct Connect gateway
• Third-party network appliances
• Transit Gateways in other Regions or accounts

Direct Connect gateway pattern

In a Direct Connect architecture, the corporate network connects through Direct Connect to a Direct Connect gateway. The Direct Connect gateway is associated with the Transit Gateway, and the connection uses a Transit VIF. This pattern supports transitive routing between the on-premises network, the Transit Gateway, and attached VPCs.

The decisive detail is the attachment path: Direct Connect gateway to Transit Gateway means Transit VIF.

Isolated VPCs and Shared Services

A common design uses three application VPCs—VPC A, VPC B, and VPC C—and a central shared-services VPC, VPC D. The application VPCs should be able to reach VPC D and an on-premises data center, but they must not communicate directly with one another.

This is implemented with multiple Transit Gateway route tables:

• TGW route table 1: Associate VPC A, B, and C. Include routes to the shared-services VPC and the data center, but do not provide routes between A, B, and C.
• TGW route table 2: Associate the shared-services VPC and the VPN attachment representing the data center. Include routes to VPC A, B, and C.

The VPC route tables generally contain the local route plus routes for non-local destinations targeting the TGW. Routes for the data center can be propagated from a VPN attachment, and the shared-services VPC route can be propagated from its attachment.

The result is asymmetric by design:

• VPC A, B, and C can reach VPC D and the data center.
• VPC A, B, and C cannot route to one another because their TGW route table does not contain routes to the other application VPCs.
• VPC D and the data center can reach VPC A, B, and C through their associated TGW route table.

More generally, attachments associated with one isolated TGW routing domain can route among the attachments in that domain, but they cannot route to or receive traffic from attachments associated with another isolated routing domain unless the route-table associations and propagations provide that path.

Transit Gateway Connect and SD-WAN

Software-defined wide area networking (SD-WAN) uses a software control layer to select paths based on link performance and apply traffic policies. It can use multiple links, such as Internet, LTE, and fiber, with automatic failover, replacing or supplementing MPLS.

For AWS integration, deploy a virtual SD-WAN appliance inside a VPC. The appliance connects to Transit Gateway Connect using:

• GRE tunnels for the tunnel connection
• BGP for exchanging routes

Transit Gateway then shares routes between SD-WAN branch sites and connected AWS VPCs. The lecture identifies vendor integrations including Cisco, Aruba, Silver Peak, Aviatrix, and Versa Networks.

Multicast Routing

Transit Gateway supports multicast routing between subnets of attached VPCs. The TGW routes traffic from instances sending to multiple receiving instances.

Important membership details:

• Multicast domain membership is defined at the subnet level.
• Multicast groups identify hosts by IP multicast groups.
• Group membership is defined by individual elastic network interfaces.
• IGMP manages multicast group membership.

Multicast routing is not supported over Direct Connect, Site-to-Site VPN, or VPC peering attachments. Therefore, a design requiring multicast must account for the attachment type and cannot assume that every TGW connectivity method supports it.

Monitoring and Visibility

Transit Gateway monitoring uses several AWS services and data sources:

• Amazon CloudWatch: Provides Transit Gateway metrics in the AWS/TransitGateway namespace, including attachment-level metrics.
• Amazon VPC Flow Logs: Capture information about IP traffic routed through the TGW.
• AWS Transit Gateway Network Manager: Provides centralized global monitoring for AWS and on-premises networks, including topology, routing, and connection-status visibility and alerts when those elements change.

Use CloudWatch for metrics, Flow Logs for traffic-level evidence, and Network Manager for broader topology and hybrid-network visibility.

Transit Gateway Deployment Best Practices

• Use a separate subnet for each Transit Gateway VPC attachment.
• Create one network ACL and associate it with all subnets used for the Transit Gateway attachment, unless the network design requires a different arrangement.
• Associate the same VPC route table with all attachment subnets unless the design requires multiple VPC route tables.
• Enable route propagation for Direct Connect gateway attachments and BGP-based Site-to-Site VPN attachments.
• Use separate TGW route tables when the architecture requires segmentation, such as isolated application VPCs and a shared-services VPC.

Exam- or Assessment-Relevant Takeaways

• Choose Transit Gateway over a large VPC-peering mesh when centralized management, transitive routing, and scalable connectivity are required.
• Remember that VPC peering is non-transitive; a peering mesh is required for direct connectivity among multiple VPCs.
• For Direct Connect through a Direct Connect gateway to a Transit Gateway, select a Transit VIF.
• Identify route-table associations as the control that determines which attachments share a routing domain.
• In an isolated/shared-services pattern, application VPCs can reach the shared-services VPC without having routes to one another.
• TGW Connect uses GRE and BGP for SD-WAN appliance integration.
• Do not select Direct Connect, Site-to-Site VPN, or peering attachments for a design that requires Transit Gateway multicast.
• Distinguish TGW route tables from VPC route tables: VPC tables send traffic to the TGW, while TGW tables determine the attachment-level transit path.

Tool / Feature Decision Guide

Requirement	Appropriate feature or design	Decisive reason
Connect many VPCs and on-premises networks centrally	Transit Gateway	Provides a scalable hub and transitive routing
Connect only a small number of VPCs directly	VPC peering may be suitable	Avoids introducing a central transit hub when the topology is simple, but remains non-transitive
Connect on-premises to VPCs over a Direct Connect gateway and TGW	Direct Connect gateway with a Transit VIF	Transit VIF is required for this TGW attachment path
Connect branches using an SD-WAN appliance	Transit Gateway Connect with GRE and BGP	Exchanges SD-WAN and AWS routes through the TGW
Permit shared services while isolating application VPCs	Multiple TGW route tables and controlled associations	Creates separate routing domains and prevents unwanted paths
Observe attachment metrics	Amazon CloudWatch	Provides TGW and attachment-level metrics
Investigate routed IP traffic	VPC Flow Logs	Captures information about traffic through the TGW
View global hybrid topology and connection changes	Transit Gateway Network Manager	Centralizes topology, routing, status, and alerting
Deliver multicast among attached VPC subnets	TGW multicast, subject to attachment limitations	Multicast is supported for attached VPC subnets but not over DX, VPN, or peering attachments

Common Traps / Misconceptions

• Assuming VPC peering is transitive: A VPC cannot use another VPC’s peering connection as a transit path.
• Assuming a TGW automatically permits every attachment to communicate: TGW route-table associations and routes control reachability; multiple route tables can intentionally isolate attachments.
• Confusing VPC and TGW route tables: A VPC route table must send traffic to the TGW, but the TGW route table must also contain a usable route to the destination attachment.
• Using a standard VIF for the Direct Connect gateway-to-TGW pattern: The relevant interface is the Transit VIF.
• Expecting multicast across every TGW attachment type: Multicast is not supported over Direct Connect, Site-to-Site VPN, or peering attachments.
• Treating route propagation as optional in every hybrid design: The lecture specifically calls out enabling propagation for Direct Connect gateway and BGP Site-to-Site VPN attachments.
• Assuming all TGW subnets need separate route tables: The recommended baseline is to use the same VPC route table and NACL for attachment subnets unless the network design requires otherwise.

Real-World Engineer / Analyst Notes

• Begin a TGW design by documenting the required communication matrix: which VPCs must communicate, which must be isolated, and which on-premises services are reachable.
• Treat TGW route-table associations as security and segmentation boundaries, not merely as routing configuration.
• When troubleshooting, validate both halves of the path: the source VPC route table must target the TGW, and the TGW route table must provide a route to the destination attachment.
• For hybrid connectivity, verify route propagation and BGP-learned routes before investigating application-level failures.
• Use Flow Logs to establish whether traffic is reaching and traversing the expected path, then use CloudWatch metrics and Network Manager for health, topology, and connection-state context.
• Keep multicast requirements explicit during architecture reviews because the supported attachment types differ from ordinary unicast transit designs.

Quick Reference Summary

• Transit Gateway is a scalable central hub for VPC and hybrid connectivity.
• It supports transitive routing; VPC peering does not.
• Four fully meshed VPCs require six peering connections, while a TGW design uses VPC attachments to a central hub.
• VPC attachments use one subnet per participating Availability Zone.
• Direct Connect gateway integration with TGW uses a Transit VIF.
• TGW route tables can create isolated routing domains and shared-services patterns.
• TGW Connect integrates SD-WAN appliances with GRE tunnels and BGP.
• Multicast uses subnet domains, ENI membership, multicast groups, and IGMP, but is not supported over DX, VPN, or peering attachments.
• CloudWatch provides metrics, Flow Logs provide traffic information, and Network Manager provides global hybrid visibility.
• Recommended practices include dedicated attachment subnets, consistent NACLs and VPC route tables, and route propagation for DX gateway and BGP VPN attachments.

Flashcards

Q: Four VPCs need scalable connectivity with fewer direct connections and transitive routing. Which AWS feature should be selected?
A: AWS Transit Gateway. It provides a central hub, supports transitive routing, and avoids the six peering connections required by a fully meshed four-VPC design.

Q: What is the fundamental routing limitation of VPC peering that Transit Gateway addresses?
A: VPC peering does not support transitive routing. Transit Gateway can route between multiple attached VPCs and hybrid attachments through the central hub.

Q: A VPC is attached to a Transit Gateway in three Availability Zones. What subnet configuration is specified for the attachment?
A: Specify one subnet in each Availability Zone where routing through the Transit Gateway should be enabled.

Q: When a Direct Connect gateway is associated with a Transit Gateway, which virtual interface is used?
A: A Transit Virtual Interface, or Transit VIF, is used for the Direct Connect gateway-to-Transit Gateway attachment path.

Q: How can a Transit Gateway enforce that VPCs A, B, and C reach shared-services VPC D but not one another?
A: Use separate TGW route-table associations and routes so A, B, and C share a table containing routes to D and the data center, but not routes to each other.

Q: What is the difference between a VPC route table and a Transit Gateway route table in a TGW path?
A: The VPC route table directs traffic toward the TGW; the TGW route table determines which attached destination network is reachable.

Q: An SD-WAN appliance in a VPC must exchange branch routes with AWS VPCs through Transit Gateway. Which TGW capability and protocols are used?
A: Use Transit Gateway Connect with GRE tunnels and BGP. The TGW can then share routes between SD-WAN branches and attached AWS VPCs.

Q: Which attachment types do not support Transit Gateway multicast routing?
A: Direct Connect, Site-to-Site VPN, and peering attachments do not support TGW multicast routing.

Q: How is multicast group membership managed in a Transit Gateway multicast design?
A: The multicast domain is defined at the subnet level, membership is associated with individual elastic network interfaces, and IGMP manages group membership.

Q: Which AWS service provides Transit Gateway metrics, including attachment-level metrics?
A: Amazon CloudWatch, using the AWS/TransitGateway namespace.

Q: You need evidence about the IP traffic routed through a Transit Gateway. Which tool should you use?
A: Amazon VPC Flow Logs, because they capture information about IP traffic routed through the TGW.

Q: Which service provides global visualization and monitoring of AWS and on-premises Transit Gateway networks?
A: AWS Transit Gateway Network Manager. It provides centralized topology, routing, and connection-status visibility with alerting on changes.

Q: What route-propagation practice is recommended for Direct Connect gateway and BGP Site-to-Site VPN attachments?
A: Enable route propagation for those attachments so their learned routes can populate the relevant routing configuration.

Q: What is the main operational trap when troubleshooting a TGW connection that appears attached but cannot pass traffic?
A: An attachment alone is not sufficient. Confirm that the source VPC route table targets the TGW and that the selected TGW route table has a route to the destination attachment.

Practice Questions

Question 1

A company has four VPCs and wants every VPC to communicate with the others and with an on-premises data center. The network team wants to minimize direct connections and route-table complexity. Which design best fits the requirement?

A. Create six VPC peering connections and one VPN from each VPC to the data center

B. Attach all VPCs and the hybrid connection to one Transit Gateway

C. Create one VPC peering connection and use it as a transit path for the other VPCs

D. Use a separate Direct Connect connection from every VPC to the data center

Correct answer: B

Explanation: Transit Gateway provides centralized, transitive routing and avoids the growing number of connections required by a peering mesh. VPC peering cannot be used transitively.

Question 2

VPC A, B, and C must access shared-services VPC D and an on-premises data center. They must not communicate with each other. Which Transit Gateway design is most appropriate?

A. Associate all four VPCs and the VPN with one TGW route table containing every route

B. Use separate TGW route tables and associate A, B, and C with a table that omits routes to one another

C. Use VPC peering between A, B, and C and attach only D to the TGW

D. Remove the local routes from the VPC route tables

Correct answer: B

Explanation: Multiple TGW route tables can create isolated routing domains. A, B, and C can receive routes to D and the data center without receiving routes to each other.

Question 3

A corporate data center connects to AWS through a Direct Connect gateway that is associated with a Transit Gateway. Which interface should be used for this architecture?

A. Transit VIF

B. GRE tunnel only

C. Standard VPC peering interface

D. Site-to-Site VPN-only interface

Correct answer: A

Explanation: The Direct Connect gateway-to-Transit Gateway pattern uses a Transit Virtual Interface. GRE is associated with Transit Gateway Connect and SD-WAN integration, not this Direct Connect pattern.

Question 4

An organization wants to connect branch offices through a virtual SD-WAN appliance running in a VPC and exchange routes with AWS VPCs through Transit Gateway. Which configuration is correct?

A. Transit Gateway Connect with GRE tunnels and BGP

B. VPC peering with static routes only

C. Direct Connect multicast with IGMP

D. Transit VIF without a Direct Connect gateway

Correct answer: A

Explanation: Transit Gateway Connect integrates virtual SD-WAN appliances using GRE tunnels and BGP for route exchange.

Question 5

An architect proposes using Transit Gateway multicast to deliver traffic to receivers reached through a Site-to-Site VPN attachment. What is the correct assessment?

A. It is supported because all TGW attachments support multicast

B. It is supported only if the VPN uses BGP

C. It is not supported over Site-to-Site VPN attachments

D. It is supported only when the VPN terminates in a shared-services VPC

Correct answer: C

Explanation: Transit Gateway multicast is not supported over Direct Connect, Site-to-Site VPN, or peering attachments.

WordPress Metadata

Suggested Slug:
aws-transit-gateway-architecture-routing-operations-soa-c03

Meta Description:
Study AWS Transit Gateway connectivity, route-table isolation, Direct Connect, SD-WAN, multicast, monitoring, and deployment best practices for CloudOps Engineer Associate preparation.

Tags:
AWS Transit Gateway, AWS networking, VPC routing, VPC peering, AWS Direct Connect, AWS Site-to-Site VPN, AWS RAM, SD-WAN, multicast routing, CloudWatch, Transit Gateway Network Manager, SOA-C03