AWS Transit Gateway Architecture, Routing, and Design Patterns – SAP-C02 Study Guide | AWS Systems Architect Professional

Study guide

Technical reference and lesson notes

Purpose of This Lesson

AWS Transit Gateway (TGW) provides a centralized network hub for connecting multiple VPCs, on-premises networks, VPNs, Direct Connect, and other network appliances. It replaces complicated collections of point-to-point VPC peering connections with a scalable, centrally managed routing model.

This lesson focuses on Transit Gateway architecture, route-table behavior, hybrid connectivity, segmentation, SD-WAN integration, multicast, monitoring, and deployment practices relevant to AWS architecture exams.

Key Concepts

Transit Gateway as a centralized network hub

A Transit Gateway acts as a regional network transit hub. VPCs and other networks connect to it through attachments, and Transit Gateway route tables determine how traffic is forwarded between those attachments.

Common attachment types include:

VPC attachments
AWS Site-to-Site VPN attachments
Direct Connect gateway associations
Transit Gateway Connect attachments for SD-WAN appliances
Peering attachments to Transit Gateways in other Regions
Network function or third-party appliance integrations, where supported

Transit Gateway supports transitive routing. For example, a VPC can communicate with an on-premises network through the Transit Gateway without requiring a separate VPN or peering connection for every VPC.

Why Transit Gateway scales better than VPC peering

With VPC peering, every VPC-to-VPC relationship must be created separately. A fully meshed design with n VPCs requires:

n × (n - 1) / 2 peering connections

For four VPCs, that is six peering connections. Every connection also introduces route-table and operational complexity. VPC peering is not transitive, so traffic cannot use one peering connection to reach another VPC.

Transit Gateway changes the model to a hub-and-spoke design:

Each VPC attaches to the Transit Gateway.
VPC route tables send remote network traffic to the Transit Gateway.
Transit Gateway route tables control which attachments can communicate.
New VPCs generally require one additional attachment rather than new peering links to every existing VPC.

VPC attachment subnets

When creating a VPC attachment, select one subnet in each Availability Zone that should participate in the attachment. These are dedicated attachment subnets through which Transit Gateway sends and receives traffic in that Availability Zone.

Recommended practices include:

Use a dedicated subnet for the Transit Gateway attachment in each participating Availability Zone.
Avoid placing application resources in attachment subnets.
Ensure the VPC route tables associated with workload subnets contain routes for remote networks that target the Transit Gateway.
Confirm that security groups and network ACLs allow the traffic in both directions.

Transit Gateway routing does not eliminate the need for correct VPC-side routing or security controls.

Transit Gateway route tables

A Transit Gateway can have multiple route tables. Each attachment is associated with one Transit Gateway route table, and an attachment can propagate routes into one or more route tables depending on the design.

Two relationships are important:

Association: Determines which Transit Gateway route table an attachment uses for routes received from the attachment.
Propagation: Determines which Transit Gateway route tables learn routes from an attachment.

This separation allows a Transit Gateway to provide segmentation and controlled sharing instead of automatically creating unrestricted connectivity between every attached network.

Hybrid connectivity

Transit Gateway can centralize connectivity to on-premises environments through:

AWS Site-to-Site VPN
AWS Direct Connect through a Direct Connect gateway
SD-WAN appliances using Transit Gateway Connect

For a Direct Connect design, the Direct Connect gateway is associated with the Transit Gateway, and a Transit Virtual Interface (Transit VIF) is used for the Direct Connect connection to the Direct Connect gateway. This supports routing between the on-premises network, the Transit Gateway, and attached VPCs.

BGP is used for dynamic route exchange with Direct Connect and Site-to-Site VPN. Route propagation can reduce the need to manually enter learned routes in Transit Gateway route tables, although VPC route tables and security policies still require appropriate configuration.

Isolated VPCs with shared services

A common enterprise pattern uses a group of isolated workload VPCs and a centrally managed shared-services VPC.

For example:

VPCs A, B, and C host separate applications or business units.
VPC D hosts shared DNS, directory services, inspection services, monitoring, or other common infrastructure.
A corporate data center also connects through the Transit Gateway.
A, B, and C can access VPC D and on-premises resources.
A, B, and C cannot communicate directly with one another.

This is achieved by using separate Transit Gateway route tables and carefully controlling associations and propagations. Conceptually, Transit Gateway can behave like multiple isolated routers operating within one service.

An attachment associated with one isolated routing domain can communicate with attachments in that same domain, but it cannot use that route table to reach attachments in another isolated domain.

Transit Gateway Connect and SD-WAN

Transit Gateway Connect integrates software-defined wide area networking (SD-WAN) appliances with Transit Gateway. A virtual SD-WAN appliance runs in a VPC and establishes:

GRE tunnels to the Transit Gateway Connect attachment
BGP sessions for dynamic route exchange

The SD-WAN appliance can connect branch offices over multiple links, monitor link quality, apply traffic policies, and select paths based on availability or performance. Transit Gateway then provides connectivity between the SD-WAN environment and attached AWS VPCs.

This approach is useful when an organization already operates an SD-WAN platform and wants to extend its routing and policy model into AWS.

Multicast

Transit Gateway supports multicast routing between subnets in attached VPCs. Multicast domains define the participating subnets, while multicast groups identify the recipients and senders.

Important details include:

Multicast group membership is associated with individual network interfaces.
IGMP can manage multicast group membership.
Multicast is not supported over Direct Connect, Site-to-Site VPN, or peering attachments.
The feature is intended for multicast traffic between supported VPC attachment environments, not as a general-purpose extension of multicast to every Transit Gateway attachment type.

Monitoring and operations

Transit Gateway can be monitored using several AWS capabilities:

Amazon CloudWatch: Provides Transit Gateway and attachment-level metrics.
VPC Flow Logs: Capture information about IP traffic associated with network interfaces and can help investigate traffic involving attached VPCs.
Transit Gateway Network Manager: Provides centralized visibility into global AWS and on-premises network topology, connection state, routing changes, and alerts.

Monitoring should cover both the Transit Gateway and the attached VPCs. A healthy Transit Gateway attachment does not prove that VPC route tables, security groups, network ACLs, or application listeners are correctly configured.

Exam-Relevant Takeaways

Transit Gateway is a scalable hub for connecting many VPCs and hybrid networks.
Unlike VPC peering, Transit Gateway supports transitive routing.
VPC peering does not provide transitive routing and becomes operationally complex in a full mesh.
Use Transit Gateway route-table associations and propagations to implement segmentation.
A shared-services design can allow multiple isolated VPCs to access central services without allowing lateral traffic between those VPCs.
A Direct Connect gateway connected to Transit Gateway uses a Transit VIF.
Site-to-Site VPN and Direct Connect commonly use BGP for dynamic route exchange.
Transit Gateway Connect uses GRE tunnels and BGP to integrate SD-WAN appliances.
Transit Gateway multicast has attachment-type limitations; it does not work over Direct Connect, Site-to-Site VPN, or peering attachments.
Transit Gateway does not replace VPC route tables or security controls. Both sides of a flow must have valid routes and permitted traffic.
Transit Gateway can be shared across AWS accounts using AWS Resource Access Manager (RAM).

Architecture Decision Guide

Requirement	Recommended approach	Main consideration
Connect a small number of VPCs with limited routing requirements	VPC peering may be sufficient	No transitive routing; complexity increases as VPC count grows
Connect many VPCs using centralized routing	Transit Gateway	Requires deliberate route-table and attachment design
Connect VPCs to an on-premises network over encrypted tunnels	Site-to-Site VPN attached to Transit Gateway	Consider throughput, redundancy, BGP, and VPN limitations
Connect many VPCs to on-premises over dedicated connectivity	Direct Connect gateway associated with Transit Gateway	Use a Transit VIF and design for resiliency
Provide shared services while isolating application VPCs	Multiple Transit Gateway route tables	Control associations and route propagation carefully
Extend an existing SD-WAN fabric into AWS	Transit Gateway Connect	Requires a supported virtual appliance, GRE, and BGP
Distribute multicast traffic between supported VPC subnets	Transit Gateway multicast	Not supported across DX, VPN, or peering attachments
Share centralized networking across accounts	Transit Gateway shared through AWS RAM	Requires account and organizational governance

Common Exam Traps

Assuming VPC peering is transitive: If VPC A peers with VPC B and VPC B peers with VPC C, A cannot reach C through B unless another supported connectivity design is introduced.
Assuming Transit Gateway automatically enables all connectivity: Attachments, Transit Gateway route-table associations, route propagation, VPC routes, and security controls must all be correct.
Confusing a Direct Connect gateway with a Transit Gateway: The Direct Connect gateway provides the Direct Connect-side association; the Transit Gateway provides centralized routing to attached networks. A Transit VIF is used in this integration.
Using one Transit Gateway route table for every security domain: This can unintentionally permit lateral traffic between otherwise isolated VPCs.
Forgetting return routes: A route from a workload VPC to an on-premises CIDR is insufficient if the on-premises network or another VPC lacks a return route.
Placing resources in attachment subnets: Attachment subnets should generally be dedicated to Transit Gateway connectivity.
Assuming multicast works over every attachment type: Multicast is not supported over Direct Connect, Site-to-Site VPN, or Transit Gateway peering attachments.
Treating Transit Gateway as a firewall: Transit Gateway provides routing, not application-layer inspection or a replacement for security groups, network ACLs, or dedicated inspection appliances.

Real-World Engineer Notes

Plan CIDR ranges before connecting VPCs. Overlapping CIDRs make routing and future connectivity significantly more difficult.
Use dedicated Transit Gateway attachment subnets in each participating Availability Zone and deploy attachments across multiple Availability Zones for resilience.
Keep Transit Gateway route tables aligned with security domains, ownership boundaries, and traffic-inspection requirements.
Enable route propagation where dynamic routing is appropriate, but review propagated routes to prevent accidental reachability.
Document both VPC-side routes and Transit Gateway routes. Troubleshooting only one routing layer often leads to false conclusions.
For centralized inspection, explicitly design the routing path through the inspection VPC or appliance. A Transit Gateway route table alone does not guarantee that traffic traverses a firewall.
Use AWS RAM when a central networking account must share a Transit Gateway with application accounts. Define who can create attachments and who owns route-table changes.
Use CloudWatch metrics, flow logs, and Transit Gateway Network Manager together: metrics indicate service behavior, flow logs provide traffic evidence, and Network Manager provides topology and connection visibility.

Quick Reference Summary

Primary role: Centralized, scalable network hub.
Connectivity: VPCs, VPN, Direct Connect gateway, SD-WAN, and other Transit Gateways.
Routing: Transitive; controlled by Transit Gateway route tables.
Segmentation: Use multiple route tables, associations, and propagations.
Direct Connect integration: Direct Connect gateway plus Transit VIF.
SD-WAN integration: Transit Gateway Connect with GRE and BGP.
Multicast: Supported for eligible VPC attachments; not over DX, VPN, or peering.
Cross-account sharing: AWS RAM.
Monitoring: CloudWatch, VPC Flow Logs, and Transit Gateway Network Manager.
Deployment practice: Dedicated attachment subnet per participating Availability Zone.

Flashcards

Q: What problem does AWS Transit Gateway solve?

A: It centralizes connectivity between many VPCs and hybrid networks, reducing the point-to-point complexity of VPC peering.

Q: Does Transit Gateway support transitive routing?

A: Yes. An attached network can route through Transit Gateway to another permitted attachment.

Q: Does VPC peering support transitive routing?

A: No.

Q: What formula gives the number of connections in a fully meshed design of n VPCs?

A: n × (n - 1) / 2 connections.

Q: What controls which routes an attachment uses on Transit Gateway?

A: The Transit Gateway route table associated with that attachment.

Q: What does route propagation control?

A: Which Transit Gateway route tables learn routes from an attachment.

Q: What virtual interface is used when connecting a Direct Connect gateway to Transit Gateway?

A: A Transit Virtual Interface, or Transit VIF.

Q: What protocols are used by Transit Gateway Connect for SD-WAN integration?

A: GRE tunnels and BGP.

Q: How can isolated VPCs access a shared-services VPC without communicating with one another?

A: Use separate Transit Gateway route tables and controlled attachment associations and route propagation.

Q: Can multicast use Direct Connect, Site-to-Site VPN, or Transit Gateway peering attachments?

A: No.

Q: Which service can share a Transit Gateway across AWS accounts?

A: AWS Resource Access Manager (RAM).

Q: Does Transit Gateway replace VPC route tables?

A: No. VPC route tables must still direct traffic to the Transit Gateway, and return routes must exist.

Practice Questions

Question 1

A company has 20 VPCs across multiple AWS accounts. Each VPC must communicate with a central services VPC and selected on-premises networks. The networking team wants to avoid maintaining a large number of VPC peering connections and needs transitive routing. Which architecture best meets the requirements?

A. Create a full mesh of VPC peering connections and use static routes
B. Create a Transit Gateway and share it with the accounts using AWS RAM
C. Create one Site-to-Site VPN directly from every VPC to the data center
D. Use an internet gateway and public IP addresses between VPCs

Correct answer: B

Explanation: Transit Gateway provides centralized, transitive routing and can be shared across accounts through AWS RAM. The other options either do not scale, add unnecessary VPN complexity, or expose traffic through public networking.

Question 2

A company uses a Transit Gateway to connect three application VPCs, a shared-services VPC, and an on-premises data center. The application VPCs must access the shared-services VPC and the data center, but they must not communicate with one another. Which design should the architect use?

A. Associate every attachment with one route table and propagate every route
B. Use VPC peering between each application VPC and the shared-services VPC
C. Use separate Transit Gateway route tables with controlled associations and propagations
D. Remove the application VPC routes to the Transit Gateway

Correct answer: C

Explanation: Multiple Transit Gateway route tables can create isolated routing domains. The application VPCs can receive routes to shared services and on-premises networks without learning routes to one another.

Question 3

An organization connects its corporate data center to a Direct Connect gateway and wants centralized connectivity to several VPCs through Transit Gateway. Which configuration is required for the Direct Connect connection?

A. An Internet gateway and a public VIF
B. A Transit VIF associated through the Direct Connect gateway
C. A Site-to-Site VPN connected to each VPC
D. A peering VIF directly attached to each VPC

Correct answer: B

Explanation: Direct Connect integration with Transit Gateway uses a Direct Connect gateway and a Transit VIF. This enables routing between the on-premises network, Transit Gateway, and permitted VPC attachments.

Question 4

A company is migrating to an SD-WAN solution and wants branch routes exchanged dynamically with VPCs connected to Transit Gateway. Which implementation should the architect recommend?

A. Run the SD-WAN appliance behind an internet gateway and use static routes
B. Use Transit Gateway Connect with GRE tunnels and BGP
C. Use multicast over a Direct Connect attachment
D. Establish VPC peering between every branch appliance VPC and every workload VPC

Correct answer: B

Explanation: Transit Gateway Connect is designed for SD-WAN integration. It uses GRE tunnels and BGP between the Transit Gateway and the virtual SD-WAN appliance, allowing dynamic route exchange.

Question 5

Network engineers confirm that a VPC attachment is available, but instances in the VPC cannot reach an on-premises CIDR through Transit Gateway. Which troubleshooting action is most appropriate first?

A. Replace the Transit Gateway with an internet gateway
B. Check only the instance security group
C. Verify VPC route tables, Transit Gateway route-table association and propagation, return routes, and filtering controls
D. Enable multicast on the Transit Gateway

Correct answer: C

Explanation: Successful Transit Gateway connectivity requires valid routes on both sides, correct attachment association and route propagation, and permitted traffic through security groups and network ACLs. Multicast and an internet gateway are unrelated to this unicast routing problem.