Cargando...
Cargando...
One gateway to connect thousands of VPCs, on-premises networks, and AWS services — at scale.
AWS Transit Gateway is a fully managed, highly available regional network transit hub that enables you to interconnect thousands of Amazon VPCs, AWS accounts, and on-premises networks through a single gateway. It acts as a cloud router — each new connection is made only once and is then available to all other connected networks, eliminating the complexity of peering meshes. Transit Gateway supports transitive routing, multicast, inter-region peering, and integrates natively with AWS Resource Access Manager (RAM) for cross-account sharing.
Simplify and scale network connectivity across hundreds or thousands of VPCs and on-premises environments by replacing complex VPC peering meshes with a centralized, transitive routing hub.
Use When
Avoid When
Transitive Routing
The core differentiator from VPC Peering — traffic can flow A→TGW→B→TGW→C. VPC Peering is non-transitive.
Multiple Route Tables (Routing Domains)
Enables traffic segmentation — e.g., isolate prod VPCs from dev VPCs while both connect to shared services VPC.
Route Propagation (BGP from VPN/DX)
VPN and DX Gateway attachments can dynamically propagate routes into TGW route tables via BGP.
Static Routes
Required for TGW peering attachments (inter-region). Also used for blackhole routes to block traffic.
Blackhole Routes
Drop traffic matching a CIDR prefix — useful for security segmentation without requiring NACLs or SGs.
Inter-Region Peering
Peer TGWs across AWS Regions over the AWS global backbone. Encrypted by default. Static routes only — no BGP.
Cross-Account Sharing via AWS RAM
Share a TGW across AWS accounts in the same Organization or with specific external accounts.
Multicast
Must be enabled at TGW creation. Supports IGMP and static group membership. Not available in all regions.
ECMP (Equal-Cost Multi-Path)
Aggregate bandwidth across multiple VPN tunnels or DX connections. Must be enabled on the TGW.
Network Manager (Global Network)
Centralized monitoring and management of TGW-based global networks including SD-WAN integrations.
Flow Logs
TGW flow logs capture IP traffic metadata. Delivered to CloudWatch Logs or S3. Different from VPC Flow Logs.
Appliance Mode
Ensures symmetric routing through a stateful appliance (firewall/IDS) in a centralized security VPC. Critical for inspection architectures.
IPv6
Supported on VPC attachments. Dual-stack routing is supported.
Direct Connect Gateway Integration
A single DX Gateway associated with a TGW provides on-premises access to all attached VPCs — the recommended DX architecture for multi-VPC environments.
AWS PrivateLink Integration
Transit Gateway does NOT replace PrivateLink. PrivateLink (VPC Interface Endpoints) is for private access to AWS services or partner services. These solve different problems.
Centralized NAT Gateway
A single NAT Gateway in a shared-services VPC can serve all spoke VPCs via TGW — but requires careful route table design to avoid hair-pinning issues.
Hub-and-Spoke VPC Architecture
high freqMultiple spoke VPCs attach to a central TGW. A shared-services VPC (with DNS, Active Directory, NAT, or security appliances) is also attached. All inter-VPC and VPC-to-internet traffic flows through the TGW. Replaces O(n²) VPC peering meshes with O(n) TGW attachments.
Cross-Account TGW Sharing
high freqA Network/Platform team owns the TGW in a central networking account. RAM shares the TGW with other AWS accounts (or the entire AWS Organization). Each account creates VPC attachments to the shared TGW. Centralized routing control stays with the network team.
Centralized VPN Termination
high freqTerminate all branch office VPN connections at a single TGW instead of per-VPC VGWs. All VPCs attached to the TGW gain access to on-premises networks. Supports ECMP across multiple VPN connections for aggregated bandwidth. Dramatically simplifies on-premises connectivity management.
TGW + Direct Connect Gateway for Multi-VPC DX Access
high freqAssociate a Direct Connect Gateway with a Transit Gateway. One DX connection (via a Transit VIF on the DX Gateway) provides on-premises connectivity to ALL VPCs attached to the TGW. This is the recommended architecture for enterprises with many VPCs needing DX access. Eliminates the need for per-VPC Private VIFs.
Centralized Security Inspection (East-West + North-South)
high freqDeploy AWS Network Firewall (or third-party appliances) in a dedicated inspection VPC. Route all inter-VPC (east-west) and internet-bound (north-south) traffic through the inspection VPC via TGW route tables. Enable Appliance Mode on the inspection VPC attachment to ensure symmetric routing for stateful inspection.
Complementary — Not Competing
high freqTGW handles VPC-to-VPC and VPC-to-on-premises routing. PrivateLink (Interface VPC Endpoints) handles private access to AWS managed services or ISV services without routing through TGW. Both are often deployed together — TGW for network backbone, PrivateLink for service access. They solve fundamentally different problems.
Organization-Wide Network Backbone
high freqCombined with RAM and AWS Organizations, a single TGW in a dedicated networking account becomes the backbone for an entire AWS Organization. Service Control Policies (SCPs) can enforce that workload accounts only route through the central TGW, enabling centralized security and compliance.
Inter-Region TGW Peering
high freqPeer TGWs in different AWS Regions to build a global network backbone. Traffic traverses the AWS global backbone (encrypted). Routes must be configured statically — BGP is NOT supported. Each peering attachment is billed in both regions.
Transit Gateway enables TRANSITIVE routing; VPC Peering does NOT. If a question asks about connecting VPC-A to VPC-C through VPC-B, VPC Peering alone cannot do it — you need TGW or a routing appliance in VPC-B.
TGW inter-region peering does NOT support BGP — routes must be added STATICALLY. If a question mentions dynamic route propagation across regions, TGW peering is NOT the answer without static route configuration.
Multicast support MUST be enabled at TGW creation time — it cannot be retrofitted to an existing TGW. If a scenario involves multicast and an existing TGW without it, the answer involves creating a new TGW.
Appliance Mode must be enabled on the TGW attachment for the inspection/security VPC when using stateful appliances (firewalls, IDS). Without it, return traffic may take a different path, breaking stateful inspection due to asymmetric routing.
For ECMP to aggregate VPN bandwidth beyond 1.25 Gbps per tunnel, ECMP must be enabled on the TGW AND the customer gateway must advertise the same prefixes over all tunnels. Each VPN connection still has a 1.25 Gbps per-tunnel limit.
TGW = TRANSITIVE routing; VPC Peering = NON-transitive. For VPC-A to reach VPC-C through VPC-B, you need TGW (not peering). For cost-optimized simple two-VPC connectivity, VPC Peering wins.
TGW inter-region PEERING uses STATIC routes ONLY — no BGP. TGW VPN/DX Gateway attachments use BGP (dynamic). Don't confuse attachment types.
Multicast CANNOT be enabled on an existing TGW — must be set at creation. Appliance Mode must be enabled for stateful inspection (symmetric routing). Both are immutable/critical design decisions.
When sharing a TGW via RAM across accounts, the VPC attachment is created in the ACCOUNT that owns the VPC, not the account that owns the TGW. The subnet used for the attachment must be in the account's VPC.
VPC Peering is cheaper than TGW for simple two-VPC connectivity — no attachment-hour cost, no data processing charge. TGW's value emerges at scale (many VPCs). Cost-optimization questions often have VPC Peering as the right answer for small topologies.
A single Direct Connect Gateway associated with a TGW provides on-premises connectivity to ALL VPCs attached to that TGW — this is the recommended multi-VPC DX architecture. Without TGW, you'd need a separate Private VIF per VPC.
TGW route tables control routing between attachments. You can have multiple route tables to create isolated routing domains (e.g., prod VPCs cannot route to dev VPCs, but both can reach shared services). Each attachment associates with one route table and can propagate routes into one or more route tables.
TGW does NOT replace VPC Endpoints (PrivateLink). If a question asks about private access to S3, DynamoDB, SSM, or other AWS services without internet exposure, the answer is VPC Endpoints — not TGW. These are complementary, not competing.
For centralized NAT via TGW (one NAT GW serving all spoke VPCs), you must configure TGW route tables carefully: spoke VPCs route 0.0.0.0/0 to TGW, TGW routes to the egress VPC, egress VPC has NAT GW. Avoid routing the spoke VPC's own CIDR back through TGW (hair-pinning).
TGW Flow Logs capture metadata about traffic flowing THROUGH the TGW (not inside VPCs). They are separate from VPC Flow Logs. For full visibility, you may need both.
Common Mistake
Transit Gateway is always the best solution for connecting VPCs — it's more advanced than VPC Peering so it must be better.
Correct
VPC Peering is often the CORRECT answer for connecting a small number of VPCs (especially 2-3). It has lower latency (no extra hop), no attachment-hour cost, and no data processing charge. TGW's value is at scale — when managing many VPCs where peering meshes become unmanageable. Cost-optimization exam questions frequently have VPC Peering as the right answer.
Exam questions on cost optimization or simple connectivity often expect VPC Peering. Defaulting to TGW as 'always better' will cause you to miss these questions. The decision framework: ≤10 VPCs with simple connectivity = VPC Peering; many VPCs, transitive routing needed, or centralized connectivity = TGW.
Common Mistake
You can use a Site-to-Site VPN attached to a Transit Gateway to connect two VPCs together privately.
Correct
Site-to-Site VPN is for connecting ON-PREMISES networks to AWS. To connect VPCs to each other, use VPC Peering (non-transitive, simple) or Transit Gateway VPC attachments (transitive, scalable). A VPN connection terminates at a VGW or TGW on the AWS side and at a Customer Gateway on the on-premises side.
This is a fundamental conceptual error. VPN = on-premises to AWS. VPC Peering or TGW = VPC to VPC. Mixing these up on exam questions leads to wrong answers on both networking and cost-optimization domains.
Common Mistake
Attaching an MSK (Managed Streaming for Kafka) cluster to a Transit Gateway keeps broker traffic private and secure from the internet.
Correct
If MSK public accessibility is enabled on the brokers, they are directly reachable from the internet regardless of whether a Transit Gateway is deployed. TGW controls routing between VPCs and on-premises — it cannot block public internet access to a resource that has public accessibility explicitly enabled. You must DISABLE public accessibility on MSK brokers AND use private connectivity (TGW, VPC Peering, or PrivateLink) to keep traffic off the internet.
This is a subtle but critical security trap. TGW provides network-level routing between private networks — it does not act as an internet firewall for resources that have been explicitly configured for public access. Always check the resource-level configuration (MSK public accessibility, EC2 public IPs, etc.) in addition to network-level controls.
Common Mistake
A NAT Gateway is sufficient for private subnet instances to reach AWS Systems Manager (SSM) without any internet exposure, even when the requirement is strict internet isolation.
Correct
NAT Gateway routes traffic TO the internet (through an Internet Gateway) — it does not eliminate internet exposure, it just hides the private IP. If the requirement is strict internet isolation (no traffic must traverse the public internet), you need VPC Interface Endpoints (PrivateLink) for SSM, SSM Messages, and EC2 Messages. Transit Gateway alone also does not solve this — you need PrivateLink endpoints regardless of TGW presence.
Many candidates confuse 'private subnet' with 'internet-isolated.' A private subnet with a NAT Gateway still sends traffic to the internet — the NAT GW connects to an IGW. True internet isolation requires PrivateLink endpoints. This distinction appears frequently in security-focused exam questions (SCS-C02, SAP-C02).
Common Mistake
Transit Gateway inter-region peering supports dynamic routing (BGP) just like VPN and Direct Connect attachments do.
Correct
TGW inter-region peering attachments ONLY support STATIC routes. BGP is NOT supported over TGW peering connections. You must manually add static routes in both regions' TGW route tables pointing to the peering attachment. Only VPN and DX Gateway attachments support BGP route propagation.
This catches candidates who correctly know that TGW supports BGP (via VPN/DX) and incorrectly assume it applies to all attachment types. The exam may present a scenario where dynamic route propagation is needed across regions — the correct answer would involve a different architecture (e.g., VPN over TGW peering with BGP, or Direct Connect with Transit VIFs).
Common Mistake
Enabling multicast on an existing Transit Gateway is possible through the console or API.
Correct
Multicast support must be enabled at TGW CREATION TIME. It is an immutable setting — you cannot enable multicast on an existing TGW. If a scenario requires multicast and the existing TGW doesn't have it, you must create a new TGW with multicast enabled and migrate attachments.
This is an operational trap that appears in both exam scenarios and real-world situations. Always check TGW configuration requirements BEFORE creation when multicast is in scope.
TGW = 'The Great Wheel' — all network spokes connect to the central hub, and traffic can flow spoke-to-spoke THROUGH the hub (transitive). VPC Peering = two spokes connected directly, no hub, no transitivity.
Remember 'STATIC Peering, DYNAMIC VPN' — TGW inter-region PEERING = STATIC routes only. TGW VPN/DX attachments = DYNAMIC (BGP) routes.
Multicast Memory: 'You must COMMIT at BIRTH' — multicast must be enabled when the TGW is CREATED, like a birth certificate — you can't add it later.
Appliance Mode = 'Same Door In, Same Door Out' — enables symmetric routing so stateful firewalls see both directions of a flow on the same interface.
TGW vs VPC Peering cost decision: 'Scale Justifies the Gateway' — if you're managing scale (many VPCs, transitive routing), TGW is justified. Small scale = Peering wins on cost.
CertAI Tutor · SAA-C03, SAP-C02, SCS-C02, DOP-C02 · 2026-02-21
In the Same Category
Comparisons
Guides & Patterns