Building a Hub-and-Spoke Network with AWS Transit Gateway - Designing Multi-VPC Connectivity
Consolidates multiple VPCs and on-premises networks in a hub-and-spoke topology and establishes security boundaries through route table isolation. It also introduces multi-region connectivity through peering.
Transit Gateway Overview
Transit Gateway is a service that connects multiple VPCs and on-premises networks in a hub-and-spoke topology. VPC peering is a one-to-one connection, and as the number of VPCs grows, managing a full mesh becomes difficult. Transit Gateway functions as a single hub and consolidates all VPCs and VPN connections.
Route Table Isolation and Multi-Account
By isolating Transit Gateway route tables, you achieve segmentation such as production VPCs being able to communicate with each other but not with development VPCs, and a shared services VPC being accessible from all VPCs. You share the Transit Gateway with other accounts using RAM and attach the VPCs of each account. With Direct Connect Gateway integration, you can access all VPCs from on-premises through Transit Gateway, and there is no need to build a VPN for each VPC.
Peering and Multi-Region Connectivity
With Transit Gateway peering, you can connect Transit Gateways in different regions and build a multi-region hub-and-spoke network. Peering connections go through the AWS global backbone and provide low-latency communication that does not pass through the internet. Peering routes are configured as static routes, and the CIDR blocks of each region are advertised to each other. Using Transit Gateway Connect attachments, you can establish GRE tunnels and BGP peering with SD-WAN appliances and integrate with on-premises networks through dynamic routing. It is also possible to create a multicast domain on Transit Gateway and deliver multicast traffic between VPCs.
Transit Gateway Pricing Structure
Transit Gateway pricing consists of the number of attachments (hourly charges for each VPC, VPN, and Direct Connect Gateway) and the amount of data processed. Each attachment costs about $0.05/hour (about $36/month), and in environments with many VPCs, attachment charges become a major cost factor (as of August 2026). The data processing charge is about $0.02 per GB. Peering attachments incur additional inter-region data transfer charges. By analyzing traffic patterns between VPCs and also using VPC peering (no data processing charges) between VPCs with heavy traffic, you can reduce Transit Gateway data processing costs. Flow Logs visualize the traffic passing through Transit Gateway and serve as input for cost optimization decisions.
Centralized Inspection Architecture
If you want to centralize security, an architecture that provides a dedicated Inspection VPC for inspection and consolidates all traffic between VPCs and with external networks there is effective. You design the Transit Gateway route tables so that traffic from spoke VPCs is first directed to the firewall in the Inspection VPC and forwarded to its destination after inspection. If you deploy AWS Network Firewall or third-party appliances, you can monitor and control traffic across the entire organization with unified policies. Because there is no need to distribute firewalls across each VPC, rule management becomes simpler and gaps can be prevented.
Appliance Mode and Path Symmetry
In architectures that route traffic through stateful firewalls, asymmetric routing, in which outbound and return traffic take different paths, becomes a problem. Because inspection devices track the state of connections, sessions cannot be established if the outbound and return traffic take separate paths. When you enable Transit Gateway appliance mode, the outbound and return traffic of the same flow always go through a path in the same Availability Zone, and stateful inspection works correctly. When designing centralized inspection, you keep in mind that enabling this mode is a prerequisite.
Design Considerations and Quotas
Transit Gateway has a bandwidth limit for each attachment, so for paths where a large amount of traffic is concentrated, you consider a design that distributes it across multiple attachments. Because there are also quotas on the number of route table entries and the number of attachments, you plan the CIDR design on the assumption that VPCs will keep increasing and keep route aggregation (summarization) in mind. Because overlapping CIDRs prevent correct routing, allocating address space in a planned way across the entire organization is the key to making later expansion smooth.
Monitoring and Troubleshooting
Traffic passing through Transit Gateway can be recorded with Flow Logs, which lets you understand how much traffic flows over which paths. This serves not only for isolating failures but also as input for deciding on data processing charge optimization. You monitor the transfer volume and packet count of each attachment with CloudWatch metrics and detect unexpected surges. Whether traffic is following the expected paths is checked by comparing the route table contents with Flow Logs. Many connectivity problems are caused by missing route table association or propagation settings.
Summary
Transit Gateway is a service that consolidates multi-VPC networks in a hub-and-spoke topology. It establishes security boundaries between production, development, and shared services through route table isolation, and builds multi-region networks through peering. Connect attachments make GRE/BGP integration with SD-WAN possible, and Flow Logs visualize traffic patterns as input for cost optimization decisions.
References (Official AWS Resources)
The primary sources for this page are the official AWS website and documentation. Check the official pages below for the latest specifications and pricing.
- AWS Transit Gateway official page
- Amazon VPC official page
- AWS Direct Connect official page
- AWS Documentation (official)
If this page and the official documentation disagree, treat the official documentation as authoritative.