Transit Gateway

AWS Transit Gateway acts as a cloud router, connecting thousands of VPCs and on-premises networks through a single gateway. It simplifies network topology by replacing complex VPC peering meshes.

Security Features

• Route Tables: segment traffic between VPCs (e.g., isolate production from development)
• Route Table Associations: control which VPCs can communicate with each other
• Blackhole Routes: drop traffic to specific CIDRs
• Multicast Support: for specialized network patterns
• Flow Logs: Transit Gateway flow logs for network visibility

Network Segmentation Pattern

• Shared Services VPC: DNS, logging, security tools accessible by all
• Inspection VPC: route all traffic through Network Firewall or IDS/IPS appliances
• Isolated VPCs: prevent direct communication between workload VPCs

Scale and Quotas Worth Knowing

Transit Gateway is built for scale, but the defaults shape your design:

• 5 transit gateways per account per region by default (adjustable)
• 5,000 attachments per transit gateway by default (adjustable), and a transit gateway cannot have more than one VPC attachment to the same VPC
• 20 route tables per transit gateway by default (adjustable), which is your segmentation budget: each isolated routing domain consumes one
• 10,000 total combined static and dynamic routes across all route tables of a single transit gateway
• 50 peering attachments per transit gateway by default (adjustable), used to connect transit gateways to each other across regions or accounts
• MTU of 8,500 bytes for traffic between VPC, Direct Connect, Connect, and peering attachments; VPN traffic is limited to 1,500 bytes

The route table quota deserves emphasis because it is the one that encodes security intent: twenty routing domains is plenty for most organizations, but only if you plan them, and requesting an increase mid-migration is a sign the segmentation model was never designed.

How It Goes Wrong in Practice

The classic misconfiguration is the accidental full mesh. Transit Gateway segmentation is entirely a routing construct: if every attachment is associated with the same route table and every attachment propagates its routes into that same table, then every VPC can reach every other VPC. Teams migrate off VPC peering, attach production, development, and a partner-facing VPC to one transit gateway with a single shared route table, and believe they have "segmentation" because the VPCs are separate. They do not. A compromised development instance now has a routed path to production databases, subject only to security groups, which are often loose inside "internal" networks.

The fix is deliberate route table design: separate route tables per trust zone, associations that reflect who may initiate traffic, propagations limited to what each zone must reach, and blackhole routes for CIDRs that must never be reachable. Then verify the data plane matches the intent, because a diagram is not a control.

Practical Check: Audit What a Route Table Can Actually Reach

Use the route search API to inspect effective routes in a given transit gateway route table:

aws ec2 search-transit-gateway-routes --transit-gateway-route-table-id tgw-rtb-0123456789abcdef0 --filters "Name=state,Values=active"

The output lists each destination CIDR with the attachment it forwards to, including the resource type (vpc, vpn, direct-connect-gateway, peering, connect). Run it against the route table associated with your least-trusted zone and confirm no route points at a production VPC attachment. Swap the filter to Name=state,Values=blackhole to confirm your deny routes are present, or use Name=type,Values=static to review manually created routes that tend to outlive their purpose.

Frequently Asked Questions

When should I use Transit Gateway instead of VPC peering?

Peering is fine for a handful of VPCs with simple, stable relationships. Once you pass roughly a dozen VPCs, need centralized inspection, or want hub-and-spoke reachability to on-premises networks, the peering mesh becomes unmanageable (peering is also non-transitive, so every pair needs its own connection). Transit Gateway gives you transitive routing with central control, at a per-attachment and data processing cost.

Does Transit Gateway inspect traffic?

No. It routes. If you need inspection, build the inspection VPC pattern: route inter-VPC traffic through a dedicated VPC containing AWS Network Firewall or third-party appliances, using route tables to force the traffic through it. Transit Gateway flow logs give you visibility, not filtering.

How many route tables should I create?

One per trust zone, not one per VPC. A common working set is: production, non-production, shared services, on-premises, and inspection. That is five of your default twenty, leaves room to grow, and keeps the association and propagation matrix small enough that humans can review it.