AWS Transit Gateway (TGW) | Overview.

 AWS Transit Gateway (TGW) - Overview.

Scope:

• Intro,
• What a Transit Gateway Actually Is Actually About,
• TGW Attachments – Deep Mechanics,
• Route Tables As The Heart of TGW,
• Performance & Scaling Deep Dive,
• Inter-Region Connectivity,
• Security Architecture,
• Common Architectures,
• Advanced – TGW Connect (for SD-WAN),
• Comparison Matrix,
• When to Use Transit Gateway.

Intro:

•  AWS Transit Gateway is a regional, managed Layer-3 routing hub that enables twtech to scalable connectivity across:
• Thousands of VPCs, 
• VPNs, 
• Direct Connect gateways, 
• on-prem networks.
•  Think of AWS Transit Gateway as AWS’s cloud-grade replacement for:
• SDN routers/VRFs, 
• designed for multi-VPC 
•  multi-account network topologies.

1. What a Transit Gateway Actually Is Actually About

• TGW is a distributed virtual router inside an AWS Region:

 Internal Architecture

•  TGW has edge nodes in every Availability Zone (AZ).
•   Each attachment (VPC, VPN, DXGW, peering) is associated with a TGW ENI inside each AZ where a subnet is specified, making it horizontally distributed.
•  TGW doesn’t centralize packets in a single node:
• — each AZ has a dataplane endpoint for local attachments.

Control Plane vs Data Plane

• Control Plane: TGW stores routing tables, association/propagation rules, and attachment info.
• Data Plane: Packets are routed between attachments through TGW’s high-bandwidth distributed fabric.

TGW provides hyperscale routing capacity:

• Supports 50 Gbps per VPC attachment (burst).
• Supports 20,000 routes per table (hard limit).
• Supports 5,000 attachments per TGW.

2. TGW Attachments – Deep Mechanics

• There are multiple attachment types, each with different behaviors:

A. VPC Attachment

• TGW creates ENIs in VPC subnets you specify.
• Supports UDP, TCP, ICMP, all IP traffic (unlike VPC peering which has protocol limits).
• Routes from VPC → TGW are configured using the VPC route table.
• VPCs can forward traffic to TGW using static routes only.

B. VPN Attachment

• Uses an AWS VPN endpoint connected to TGW.
• Supports BGP route exchange.
• Supports equal-cost multi-path (ECMP).

C. Direct Connect Gateway (DXGW) Attachment

• TGW ↔ DXGW uses BGP.
• Allows on-prem to reach multiple region VPCs through one DX connection (with constraints).

D. TGW Peering Attachment

• Connects TGWs in different regions.
• Not transitive: A → B → C doesn’t work.
• Supports cross-region traffic but not multicast.

E. Multicast Attachment

• Uses IGMPv2.
• Requires dedicated subnets.
• Typically used for finance/messaging/market data workloads.

3. Route Tables As The Heart of TGW

• TGW routing is like VRF-lite on steroids.

TGW has:

• One or more routing tables
• Attachments:
•    Associate: Which table the attachment reads.
•    Propagate: Which table the attachment writes to.

Sample:

Attachment	Associate	Propagate
VPC-A	Core-RT	Core-RT
VPC-B	Core-RT	Core-RT
VPN	Core-RT	Core-RT
Shared Services	Shared-RT	Shared-RT

This enables VPC segmentation:

• Hub/spoke
• Multi-tier environments
• Network isolation

Routing Behavior

• TGW route evaluation is longest-prefix match (LPM).
•  Static routes for VPC/DX peering.
•  BGP-learned routes for VPN/DX.

Important: TGW Is NOT a NAT device

• It won’t rewrite IPs.
• Source/destination IPs must be directly routable across attachments.
• Overlapping CIDRs require additional constructs (Transit Gateway Connect + SD-WAN or NAT appliances).

4. Performance & Scaling Deep Dive

• This is where TGW outclasses legacy VPC Peering:

Bandwidth

•      VPC attachment → TGW supports up to 50 Gbps burst.
•      Traffic is optimally routed per AZ (no inter-AZ hairpin).

Horizontal scaling

• Because TGW uses ENIs in each AZ:
• If twtech places attachments in multiple AZs, throughput scales per-AZ.
• Failure of one AZ does not cause regional failure — TGW is fault-isolated per AZ.

Latency

• Adds ~1–2 ms depending on region.
• Less than many SD-WAN/centralized firewalls.

Multicast Performance

• High fanout, low-latency distribution of multicast frames.
• Avoids needing physical multicast infrastructure.

5. Inter-Region Connectivity

TGW supports:

• Inter-region peering (data-plane encrypted)
• DXGW (global-scale on-prem)

But:

TGW Peering Is Not Transitive

• If TGW-A peers to TGW-B, and TGW-B peers to TGW-C:
• A cannot reach C.

Why?

• AWS retains clear boundaries for routing policies.
• No automatic large-scale route reflection.

6. Security Architecture

• TGW provides several security primitives:

A. Segmentation via Route Tables

• Route associations/propagations define allowed communication.
• Similar to VRF but simpler.

B. Appliance Mode

Used for firewalls:

• TGW attachment → dedicated appliance subnet.
• Symmetric routing ensures return traffic always flows through firewall.

C. AWS Network Firewall via GWLB

TGW → GWLB → Inspection VPC → TGW

This provides:

• Centralized firewalling
• Automatic failover/load balancing
• No throughput bottleneck on single appliance

7. Common Architectures

 A. Hub-and-Spoke

Most common:

• Spokes = application VPCs
•  Hub = TGW
•  Shared-services VPC + on-prem attached

 B. Multi-Region Mesh with TGW Peering

Each region has:

• One TGW
• All VPCs attach locally
• TGWs peer for global traffic

 C. Security VPC with GWLB

Traffic sent through:

• TGW → GWLB → Security Appliances → TGW

 D. Multi-account with AWS Organizations

• Every account in the org can attach its VPCs using:
• RAM resource sharing
• IAM permissions

8. Advanced – TGW Connect (for SD-WAN)

TGW Connect uses:

• GRE tunnels
• BGP routing

This allows:

• SD-WAN integration (VeloCloud, Cisco SD-WAN, etc.)
• Overlapping CIDRs with NAT in SD-WAN
• High-scale route distribution
• Essential for large enterprise migration use cases.

9. Comparison Matrix

Feature	TGW	VPC Peering	VPC Lattice	Cloud WAN
Transitive Routing	✔	✖	✔ (L7)	✔
Multi-VPC	✔	Limited	✔	✔
On-prem	✔	VPN only	✖	✔
Segmentation	✔ (L3)	Minimal	✔(L7)	✔
SD-WAN	✔ (TGW Connect)	✖	✖	Partial
Multicast	✔	✖	✖	✖

NB:

•     TGW = L3 router
•      Lattice = Application-level router
•      Cloud WAN = Global network manager for many TGWs

10. When to Use Transit Gateway

Use TGW when you need:

• Large-scale multi-VPC routing
• Hybrid connectivity with on-prem
• Centralized firewalling
• Segmentation and routing policies
• SD-WAN integration
• High bandwidth / low latency inter-VPC traffic

NB:

Transit Gateway (TGW) is Not ideal when:

• twtech needs Layer-7 (L7)-based service routing.
• twtech recommends instead VPC Lattice.
•  twtech requires cross-region transitivity across many regions.
•  twtech recommends instead Cloud WAN.