AWS Transit Gateway

A service that interconnects multiple VPCs and on-premises networks in a hub-and-spoke topology, dramatically simplifying network architecture

Overview

AWS Transit Gateway is a networking service that aggregates multiple VPCs, VPN connections, and Direct Connect gateways into a single hub for interconnection. While VPC peering requires full-mesh connections that become increasingly complex as VPC count grows, Transit Gateway uses a hub-and-spoke topology to drastically reduce the number of connections. It provides enterprise networking features including route table-based traffic control, multicast support, and inter-region peering.

Network Isolation via Route Tables and Propagation

One of Transit Gateway's most powerful features is traffic control through route tables. By default, all attachments (VPCs, VPNs) share a single route table and can communicate with each other. However, in practice, fine-grained routing control is needed - such as isolating production from development environments or providing one-way access to shared service VPCs. By creating multiple route tables and associating them per attachment, you can achieve network segmentation where production VPCs can communicate with each other but development VPCs cannot access production, while shared service VPCs (DNS, monitoring) are accessible from all VPCs. The route propagation feature automatically adds attachment routes to route tables, minimizing manual route management. Azure Virtual WAN supports intent-based configuration through routing intent, such as routing all internet traffic through a firewall, whereas Transit Gateway relies on manual route table management, offering finer control at the cost of greater configuration complexity.

Egress VPC Pattern and NAT Gateway Cost Consolidation

A common Transit Gateway deployment pattern is consolidating internet egress through an Egress VPC. When each VPC has its own NAT Gateway, the fixed cost (approximately $32 per month per AZ) scales linearly with VPC count. In the Egress VPC pattern, NAT Gateways are consolidated in a single Egress VPC, and Transit Gateway routing directs all internet-bound traffic from every VPC through it, significantly reducing NAT Gateway costs. In multi-account environments, you create VPCs in each Organizations account and share the Transit Gateway via RAM (Resource Access Manager) to connect all VPCs. This pattern is often combined with a centralized security architecture where Network Firewall is placed in an inspection VPC and all traffic is routed through Transit Gateway for inspection. For further reading, AWS networking books (Amazon) are a helpful resource.

Choosing Between VPC Peering and Transit Gateway - Cost Considerations

Transit Gateway's data processing charge of $0.02 per GB can be significant in environments with heavy data transfer. VPC Peering incurs no data processing charge, making it more cost-efficient when there is substantial intra-AZ communication between VPCs. As a rule of thumb, VPC Peering is suitable when connecting three or fewer VPCs where full-mesh management is straightforward, while Transit Gateway is the better choice for four or more VPCs or when VPN/Direct Connect integration is required. A hybrid approach also works well - connecting high-traffic VPC pairs directly via peering while routing the rest through Transit Gateway. For inter-region connectivity, Transit Gateway Peering is available, but additional inter-region data transfer charges apply, so estimating cross-region traffic volume in advance is important.

共有するXB!