AWS Transit Gateway Routing and Hybrid Connectivity – SAP-C02 Study Guide | AWS Systems Architect Professional

Study guide

Technical reference and lesson notes

Purpose of This Lesson

AWS Transit Gateway is a core networking service for building scalable, centralized connectivity between VPCs, on-premises networks, VPNs, Direct Connect, SD-WAN appliances, and other transit gateways.

For the AWS Certified Solutions Architect – Professional SAP-C02 exam, Transit Gateway is important because many scenario questions involve large-scale network design. AWS often expects you to recognize when VPC peering becomes operationally complex and when Transit Gateway is the better architecture for centralized routing, hybrid connectivity, segmentation, and shared services.

Transit Gateway is especially relevant when designing:

Multi-VPC networks
Hybrid cloud connectivity
Shared services VPCs
Network segmentation
Cross-account network architectures
Direct Connect and VPN integration
SD-WAN connectivity into AWS
Centralized monitoring and network operations

Key Concepts

What Is AWS Transit Gateway?

AWS Transit Gateway is a managed network transit hub that connects multiple VPCs and external networks through a central gateway.

Instead of building many individual point-to-point network connections, you attach VPCs, VPNs, Direct Connect gateways, SD-WAN appliances, and other supported network resources to the Transit Gateway.

This simplifies network architecture by replacing a large mesh of connections with a hub-and-spoke design.

Why Transit Gateway Matters

Without Transit Gateway, connecting many VPCs together usually requires multiple VPC peering connections. As the number of VPCs increases, the number of peerings and route table entries increases quickly.

Transit Gateway solves this by acting as a centralized router.

Key benefits include:

Centralized connectivity between VPCs
Support for transitive routing
Scalable multi-VPC networking
Integration with Site-to-Site VPN
Integration with Direct Connect through Direct Connect Gateway
Cross-account sharing through AWS Resource Access Manager
Support for segmented routing through multiple Transit Gateway route tables
Easier operational visibility with CloudWatch, Flow Logs, and Transit Gateway Network Manager

Transit Gateway vs VPC Peering

VPC Peering Limitations

VPC peering creates a direct network connection between two VPCs. It works well for simple one-to-one connectivity, but it does not support transitive routing.

This means if VPC A is peered with VPC B, and VPC B is peered with VPC C, VPC A cannot automatically communicate with VPC C through VPC B.

Each VPC pair must have its own peering connection.

Example: Four VPCs Without Transit Gateway

For four VPCs that all need to communicate with each other, a full mesh requires six VPC peering connections.

If on-premises connectivity is also required, each VPC may need separate VPN connectivity back to the corporate network. If redundancy is required, the number of VPN connections increases further.

This creates several problems:

More network connections to manage
More route table entries
More operational complexity
More troubleshooting overhead
Less scalable design
No native transitive routing through peering

Transit Gateway as a Hub-and-Spoke Model

With Transit Gateway, each VPC attaches to the central Transit Gateway. The Transit Gateway then handles routing between the attached networks.

Instead of every VPC needing a direct connection to every other VPC, each VPC only needs an attachment to the Transit Gateway.

This allows the architecture to scale more cleanly.

Benefits Over Full Mesh VPC Peering

Area	VPC Peering	Transit Gateway
Routing model	Point-to-point	Hub-and-spoke
Transitive routing	Not supported	Supported
Multi-VPC scalability	Becomes complex quickly	Designed for large-scale connectivity
Route table management	Many routes across many VPCs	More centralized control
Hybrid connectivity	Often duplicated per VPC	Centralized through TGW
Network segmentation	More difficult	Supported with TGW route tables

Transit Gateway Attachments

Transit Gateway connects to other network resources using attachments.

Common Transit Gateway attachment types include:

VPC attachments
Site-to-Site VPN attachments
Direct Connect Gateway attachments
Transit Gateway Connect attachments
Peering attachments to other Transit Gateways
Third-party virtual appliances

VPC Attachments

When attaching a VPC to a Transit Gateway, you select subnets in Availability Zones. Transit Gateway uses these subnets to route traffic between the VPC and the Transit Gateway.

A common best practice is to use dedicated subnets for Transit Gateway attachments rather than mixing them with application workloads.

This improves network isolation, route control, and operational clarity.

Site-to-Site VPN Attachments

Transit Gateway can be used as the AWS-side hub for Site-to-Site VPN connectivity.

This is useful when an on-premises data center or branch office needs access to multiple VPCs.

Instead of building separate VPN connections to each VPC, the VPN can terminate into the Transit Gateway. From there, routing can be extended to attached VPCs based on Transit Gateway route table configuration.

Direct Connect Gateway Attachments

Transit Gateway can integrate with AWS Direct Connect through a Direct Connect Gateway.

In this design:

The on-premises network connects to AWS using Direct Connect.
The Direct Connect connection uses a Direct Connect Gateway.
The Direct Connect Gateway is associated with the Transit Gateway.
The Transit Gateway routes traffic to attached VPCs.

When connecting a Direct Connect Gateway to a Transit Gateway, a Transit Virtual Interface, or Transit VIF, is used.

Why This Matters for the Exam

If the scenario involves Direct Connect connectivity to multiple VPCs through Transit Gateway, the expected design is usually:

Direct Connect connection → Direct Connect Gateway → Transit VIF → Transit Gateway → attached VPCs

This supports centralized hybrid connectivity and transitive routing between on-premises and AWS networks.

Transitive Routing

Transitive routing is one of the major reasons to use Transit Gateway.

With Transit Gateway, attached networks can route through the gateway to reach other attached networks, assuming the route tables allow it.

For example:

VPC A can reach VPC B through Transit Gateway.
VPC A can reach an on-premises data center through Transit Gateway.
On-premises can reach multiple AWS VPCs through a single Transit Gateway-connected design.

This is different from VPC peering, where VPCs cannot use a peered VPC as a transit path to another VPC.

Transit Gateway Route Tables

Transit Gateway has its own route tables. These are separate from VPC route tables.

Two important concepts are:

Route table association
Route propagation

Route Table Association

A Transit Gateway attachment is associated with one Transit Gateway route table.

The associated route table determines where traffic from that attachment is allowed to go.

Think of association as choosing which logical router an attachment belongs to.

Route Propagation

Route propagation allows routes from an attachment to be automatically added to a Transit Gateway route table.

For example:

A VPN attachment can propagate on-premises routes into a Transit Gateway route table.
A VPC attachment can propagate its VPC CIDR block into a Transit Gateway route table.
A Direct Connect Gateway attachment can propagate routes learned through BGP.

Route propagation is especially useful for BGP-based connections such as Site-to-Site VPN and Direct Connect.

Shared Services and Isolated VPC Architecture

A common Transit Gateway design pattern is the shared services VPC model.

In this architecture, multiple application VPCs need to access a central shared services VPC, but they should not be able to communicate with each other.

Example:

VPC A = application VPC
VPC B = application VPC
VPC C = application VPC
VPC D = shared services VPC
On-premises data center connected through VPN

The goal:

VPC A, B, and C can access VPC D.
VPC A, B, and C can access on-premises if allowed.
VPC A, B, and C cannot communicate directly with each other.
VPC D and on-premises may need access back to the application VPCs.

How Transit Gateway Route Tables Enable Segmentation

Transit Gateway can use multiple route tables to act like multiple isolated routers.

For example:

Transit Gateway Route Table 1

Associated with:

VPC A
VPC B
VPC C

Contains routes to:

Shared services VPC D
On-premises network

Does not contain routes between VPC A, VPC B, and VPC C.

Result:

Application VPCs can reach shared services.
Application VPCs can reach on-premises.
Application VPCs cannot route to each other.

Transit Gateway Route Table 2

Associated with:

Shared services VPC D
VPN attachment to on-premises

Contains routes to:

VPC A
VPC B
VPC C
VPC D
On-premises networks as needed

Result:

Shared services and on-premises can reach the application VPCs.
Application VPCs remain isolated from each other.

This is a powerful pattern for centralized services, inspection, logging, Active Directory, DNS, shared tooling, patching, or other common infrastructure services.

Transit Gateway and SD-WAN

What Is SD-WAN?

Software-defined WAN, or SD-WAN, is a networking approach that uses software-based policies to manage traffic across multiple network links.

SD-WAN can use:

Internet circuits
LTE
Fiber
MPLS
Broadband
Other WAN transport options

SD-WAN appliances monitor link health and steer traffic based on policy, performance, availability, and application requirements.

Transit Gateway Connect

AWS Transit Gateway Connect is used to connect SD-WAN appliances to Transit Gateway.

A common design is:

Deploy a virtual SD-WAN appliance in a VPC.
Connect the appliance to Transit Gateway using Transit Gateway Connect.
Use GRE tunnels and BGP between the SD-WAN appliance and Transit Gateway.
Exchange routes between SD-WAN branches and AWS VPCs.

Transit Gateway Connect is useful when integrating AWS networking with third-party SD-WAN platforms.

Examples of SD-WAN vendors commonly associated with this type of architecture include:

Cisco
Aruba / Silver Peak
Aviatrix
Versa Networks

Transit Gateway Multicast

Transit Gateway supports multicast routing between subnets in attached VPCs.

Multicast allows one sender to send traffic to multiple receivers using multicast group addresses.

Important multicast concepts:

Multicast domains are defined at the subnet level.
Multicast group membership is associated with individual elastic network interfaces.
IGMP is used to manage multicast group membership.
Transit Gateway routes multicast traffic between participating subnets.

Multicast Limitations

Transit Gateway multicast is not supported across:

Direct Connect attachments
Site-to-Site VPN attachments
Transit Gateway peering attachments

This is an important exam detail because AWS may include multicast in hybrid connectivity scenarios as a distractor.

Cross-Account Transit Gateway Sharing

Transit Gateways can be shared across AWS accounts using AWS Resource Access Manager, or AWS RAM.

This is useful in multi-account AWS environments where networking is centralized in a dedicated network account.

A common enterprise pattern is:

Networking account owns the Transit Gateway.
Application accounts attach their VPCs to the shared Transit Gateway.
Central networking team controls route tables, propagation, segmentation, and connectivity policies.

This fits well with AWS Organizations and multi-account landing zone designs.

Monitoring and Operations

Amazon CloudWatch Metrics

Transit Gateway provides metrics through Amazon CloudWatch.

CloudWatch can be used to monitor Transit Gateway and attachment-level behavior, such as traffic volume and packet-related metrics.

For operational teams, this is useful for identifying abnormal traffic patterns, validating connectivity, and monitoring network utilization.

Transit Gateway Flow Logs

Transit Gateway Flow Logs capture information about IP traffic routed through the Transit Gateway.

This is useful for:

Troubleshooting connectivity
Reviewing allowed or rejected flows
Security investigations
Network traffic analysis
Validating route behavior

Transit Gateway Flow Logs are conceptually similar to VPC Flow Logs, but focused on traffic handled by the Transit Gateway.

AWS Transit Gateway Network Manager

AWS Transit Gateway Network Manager provides centralized visibility into AWS and on-premises networks.

It helps with:

Global network topology visualization
Route monitoring
Connection status monitoring
Alerting on topology changes
SD-WAN integration visibility
Operational monitoring across hybrid environments

For large enterprise networks, Network Manager can help cloud and network teams understand how AWS and on-premises connectivity fit together.

Transit Gateway Best Practices

Use Dedicated Subnets for VPC Attachments

Use separate subnets for Transit Gateway VPC attachments. This keeps Transit Gateway routing infrastructure separate from workload subnets and makes the design easier to manage.

Standardize Network ACLs

A common approach is to create a network ACL for the Transit Gateway attachment subnets and associate it consistently.

This helps avoid inconsistent subnet-level filtering.

Standardize VPC Route Tables Where Possible

Use the same VPC route table for subnets associated with Transit Gateway attachments unless the design requires separate route tables.

This reduces operational complexity and makes troubleshooting easier.

Enable Route Propagation for BGP-Based Attachments

For Direct Connect Gateway and BGP-based Site-to-Site VPN attachments, enable route propagation where appropriate.

This allows learned routes to be dynamically added to Transit Gateway route tables instead of relying entirely on static route management.

Design Route Tables Intentionally

Do not treat Transit Gateway as a flat network by default.

Transit Gateway route tables are a major control point. Use them to define which attachments can communicate.

This is especially important for:

Segmented environments
Shared services designs
Production and non-production separation
Multi-account AWS environments
Security inspection architectures
Hybrid network access control

Exam-Relevant Takeaways

For SAP-C02, remember these points:

Transit Gateway is the preferred design for scalable, centralized connectivity across many VPCs.
VPC peering does not support transitive routing.
Transit Gateway does support transitive routing when route tables allow it.
Transit Gateway reduces the number of peering connections and route table entries in large multi-VPC environments.
Direct Connect connectivity to Transit Gateway uses a Direct Connect Gateway and Transit VIF.
Transit Gateway route tables control segmentation.
Route table association determines which route table an attachment uses.
Route propagation automatically adds learned routes into Transit Gateway route tables.
AWS RAM can share a Transit Gateway across accounts.
Transit Gateway Connect is used for SD-WAN integration with GRE and BGP.
Transit Gateway multicast is limited to supported VPC subnet use cases and does not work over Direct Connect, VPN, or peering attachments.
CloudWatch, Transit Gateway Flow Logs, and Network Manager are used for monitoring, visibility, and troubleshooting.

Architecture Decision Guide

Scenario	Best AWS Choice	Why
Two VPCs need simple private connectivity	VPC Peering	Simple and cost-effective for limited point-to-point connectivity
Many VPCs need centralized routing	Transit Gateway	Avoids complex full-mesh peering and supports transitive routing
VPCs need access to shared services but not each other	Transit Gateway with multiple route tables	Enables routing segmentation and shared services access
On-premises network needs access to multiple VPCs over VPN	Transit Gateway with Site-to-Site VPN attachment	Centralizes hybrid connectivity instead of building VPNs to each VPC
On-premises network uses Direct Connect to reach multiple VPCs	Direct Connect Gateway associated with Transit Gateway using Transit VIF	Provides centralized private connectivity from on-premises to attached VPCs
SD-WAN branches need access to AWS VPCs	Transit Gateway Connect	Supports SD-WAN integration using GRE tunnels and BGP
Multi-account AWS environment needs centralized network control	Shared Transit Gateway through AWS RAM	Allows a network account to own TGW while application accounts attach VPCs
Multicast is required between VPC subnets	Transit Gateway multicast	Supports multicast between participating VPC subnets
Multicast is required over VPN or Direct Connect	Not Transit Gateway multicast	TGW multicast is not supported over VPN, Direct Connect, or peering attachments
Global hybrid network visibility is required	Transit Gateway Network Manager	Provides centralized topology, route, and connection visibility

Common Exam Traps

Trap 1: Choosing VPC Peering for Transitive Routing

VPC peering does not support transitive routing.

If an exam question requires VPC A to reach VPC C through VPC B, VPC peering is not the correct answer.

Use Transit Gateway when transitive routing is required.

Trap 2: Assuming Full Mesh Peering Scales Well

VPC peering may seem reasonable with two or three VPCs, but it becomes difficult to manage as the number of VPCs grows.

For large multi-VPC environments, AWS generally expects Transit Gateway.

Trap 3: Confusing VPC Route Tables and Transit Gateway Route Tables

VPC route tables and Transit Gateway route tables are separate.

Traffic leaving a subnet must first be routed from the VPC route table to the Transit Gateway. Then Transit Gateway route tables determine where that traffic can go next.

Both sides matter.

Trap 4: Thinking All TGW Attachments Can Communicate Automatically

Transit Gateway does not mean every attachment can automatically talk to every other attachment.

Communication depends on:

Transit Gateway route table associations
Transit Gateway route propagation
Static TGW routes
VPC route tables
Security groups
Network ACLs
On-premises routing and firewall rules

Trap 5: Forgetting Transit VIF for Direct Connect to Transit Gateway

When connecting Direct Connect to Transit Gateway through Direct Connect Gateway, the expected virtual interface type is a Transit VIF.

A private VIF is not the right choice for this specific Transit Gateway pattern.

Trap 6: Assuming TGW Multicast Works Everywhere

Transit Gateway multicast does not support multicast over Direct Connect, Site-to-Site VPN, or peering attachments.

If the scenario requires multicast across those attachment types, be careful.

Trap 7: Ignoring Route Table Segmentation

Transit Gateway route tables are not just for reachability. They are also used for segmentation.

If the question says VPCs must access shared services but not each other, use separate TGW route tables and selective route propagation.

Real-World Engineer Notes

In real environments, Transit Gateway is often the backbone of an AWS network design.

Migration Considerations

When migrating from VPC peering to Transit Gateway, plan carefully.

You need to review:

VPC CIDR overlap
Existing peering routes
VPC route tables
Security group dependencies
DNS resolution requirements
On-premises routing
Firewall rules
Application dependencies
Cutover sequencing

A common mistake is assuming that moving to Transit Gateway is just a routing change. In practice, it can affect firewall policy, DNS, monitoring, logging, latency paths, and governance.

Operations and Troubleshooting

When troubleshooting Transit Gateway connectivity, verify each layer:

Source subnet route table points to Transit Gateway.
Transit Gateway attachment exists and is available.
Correct TGW route table is associated with the source attachment.
TGW route table has a route to the destination attachment.
Destination VPC route table has return routes.
Security groups allow the traffic.
Network ACLs allow the traffic.
On-premises firewall and routing allow the traffic if hybrid connectivity is involved.
BGP routes are being advertised and propagated if using VPN or Direct Connect.
Flow Logs show whether traffic is being accepted, rejected, or misrouted.

Cost Considerations

Transit Gateway simplifies architecture, but it is not free. In production, you should evaluate:

Attachment hourly costs
Data processing costs
Cross-AZ data paths
Hybrid connectivity charges
Data transfer costs
Traffic inspection architecture costs

For small environments, VPC peering may still be cheaper and simpler. For large environments, Transit Gateway usually wins operationally.

Governance Considerations

In enterprise AWS environments, Transit Gateway is commonly placed in a central network account.

This allows a cloud networking team to control:

Route table design
Attachment approval
Cross-account sharing
Segmentation
Hybrid network connectivity
Inspection and monitoring patterns

This aligns well with AWS Organizations and multi-account governance.

Security Considerations

Transit Gateway is not a firewall by itself. It routes traffic.

Security still depends on:

Security groups
Network ACLs
AWS Network Firewall or third-party appliances if inspection is required
Route table segmentation
IAM permissions around TGW sharing and attachment creation
Flow Logs and monitoring
On-premises firewall controls

For exam scenarios involving centralized inspection, Transit Gateway may be part of the architecture, but you may also need AWS Network Firewall or third-party security appliances depending on the question.

Quick Reference Summary

AWS Transit Gateway is a centralized routing hub for connecting VPCs, on-premises networks, Direct Connect, VPN, SD-WAN, and other supported attachments.

Use Transit Gateway when you need scalable multi-VPC networking, transitive routing, hybrid connectivity, cross-account network sharing, or segmented shared services architectures.

VPC peering is better for simple point-to-point VPC connectivity but does not support transitive routing and becomes operationally difficult at scale.

Transit Gateway route tables are critical. They determine which attachments can communicate and can be used to isolate VPCs while allowing access to shared services or on-premises networks.

Direct Connect connectivity to Transit Gateway uses a Direct Connect Gateway and Transit VIF.

Transit Gateway Connect supports SD-WAN integration using GRE and BGP.

Transit Gateway multicast supports multicast between attached VPC subnets, but not across Direct Connect, VPN, or peering attachments.

Monitor Transit Gateway using CloudWatch metrics, Transit Gateway Flow Logs, and Transit Gateway Network Manager.

Flashcards

Q: What problem does AWS Transit Gateway solve?
A: It simplifies scalable network connectivity by acting as a central routing hub for VPCs, VPNs, Direct Connect, SD-WAN, and other supported attachments.

Q: Does VPC peering support transitive routing?
A: No. VPC peering does not support transitive routing.

Q: Does Transit Gateway support transitive routing?
A: Yes, Transit Gateway supports transitive routing when route tables are configured to allow it.

Q: When should you prefer Transit Gateway over VPC peering?
A: Use Transit Gateway when many VPCs need centralized connectivity, transitive routing, hybrid connectivity, or route segmentation.

Q: What AWS service can share a Transit Gateway across accounts?
A: AWS Resource Access Manager, or AWS RAM.

Q: What virtual interface type is used when connecting Direct Connect Gateway to Transit Gateway?
A: Transit VIF.

Q: What are Transit Gateway route tables used for?
A: They control routing between Transit Gateway attachments and can be used to segment network traffic.

Q: What is the difference between TGW route association and propagation?
A: Association determines which route table an attachment uses. Propagation automatically adds routes from an attachment into a TGW route table.

Q: What Transit Gateway feature is commonly used for SD-WAN integration?
A: Transit Gateway Connect.

Q: What protocols are commonly associated with Transit Gateway Connect?
A: GRE tunnels and BGP.

Q: Can Transit Gateway multicast be used over Site-to-Site VPN?
A: No. Transit Gateway multicast is not supported over Site-to-Site VPN attachments.

Q: Can Transit Gateway multicast be used over Direct Connect?
A: No. Transit Gateway multicast is not supported over Direct Connect attachments.

Q: What AWS service provides global visibility for Transit Gateway and hybrid network topology?
A: AWS Transit Gateway Network Manager.

Q: What logging feature captures IP traffic routed through Transit Gateway?
A: Transit Gateway Flow Logs.

Q: In a shared services architecture, how can application VPCs access shared services without talking to each other?
A: Use multiple Transit Gateway route tables with selective route propagation and association.

Practice Questions

Question 1:
A company has 12 VPCs across multiple AWS accounts. Each VPC needs private connectivity to several other VPCs and to an on-premises data center. The network team wants to reduce the number of peering connections and simplify routing. Which design is most appropriate?

A. Create a full mesh of VPC peering connections between all VPCs
B. Create separate Site-to-Site VPN connections from the data center to each VPC
C. Use AWS Transit Gateway as a central hub and attach the VPCs and hybrid connection
D. Use internet gateways and public IP addressing between VPCs

Correct Answer:
C

Explanation:
Transit Gateway is designed for scalable, centralized connectivity across many VPCs and hybrid networks. Full-mesh VPC peering becomes complex and does not support transitive routing.

Question 2:
A company has VPC A, VPC B, and VPC C. VPC A is peered with VPC B, and VPC B is peered with VPC C. The company wants VPC A to communicate with VPC C through VPC B. What should the solutions architect understand?

A. This works automatically with VPC peering
B. This requires enabling route propagation on the VPC peering connection
C. This is not supported with VPC peering because peering is not transitive
D. This requires a NAT gateway in VPC B

Correct Answer:
C

Explanation:
VPC peering does not support transitive routing. VPC A cannot use VPC B as a transit path to reach VPC C. Transit Gateway is the better option when transitive routing is required.

Question 3:
A company uses AWS Direct Connect and wants to connect its on-premises data center to multiple VPCs through AWS Transit Gateway. Which virtual interface type should be used with the Direct Connect Gateway?

A. Public VIF
B. Private VIF
C. Transit VIF
D. VPN VIF

Correct Answer:
C

Explanation:
When Direct Connect Gateway is associated with Transit Gateway, the connection uses a Transit Virtual Interface, or Transit VIF.

Question 4:
A company has three application VPCs and one shared services VPC. The application VPCs must access the shared services VPC, but they must not communicate with each other. What Transit Gateway feature supports this design?

A. A single flat Transit Gateway route table with all routes propagated
B. Multiple Transit Gateway route tables with selective association and propagation
C. VPC peering between all VPCs
D. Internet gateways in each VPC

Correct Answer:
B

Explanation:
Multiple Transit Gateway route tables allow the network team to control which attachments can communicate. This supports shared services access while keeping application VPCs isolated from each other.

Question 5:
A company wants to integrate SD-WAN branch connectivity with AWS Transit Gateway. The SD-WAN appliance will exchange routes dynamically with AWS. Which Transit Gateway feature is most relevant?

A. Transit Gateway Connect using GRE and BGP
B. VPC peering using static routes
C. NAT Gateway using private IP routing
D. Gateway VPC endpoint using route table entries

Correct Answer:
A

Explanation:
Transit Gateway Connect is designed for SD-WAN integration and commonly uses GRE tunnels and BGP to exchange routes between SD-WAN appliances and Transit Gateway.