Transit VPC solution - Building a Scalable and Secure Multi-VPC AWS Network Infrastructure

Transit VPC solution

Transit VPCs can create connectivity between VPCs by a different means than VPC peering by introducing a hub and spoke design for inter-VPC connectivity. In a transit VPC network, one central VPC (the hub VPC) connects with every other VPC (spoke VPC) through a VPN connection typically leveraging BGP over IPsec. The central VPC contains Amazon Elastic Compute Cloud (Amazon EC2) instances running software appliances that route incoming traffic to their destinations using the VPN overlay. Transit VPC peering has the following advantages:

  • Transitive routing is enabled using the overlay VPN network — allowing for a hub and spoke design.

  • When using third-party vendor software on the EC2 instance in the hub transit VPC, vendor functionality around advanced security (layer 7 firewall/Intrusion Prevention System (IPS)/Intrusion Detection System (IDS) ) can be used. If customers are using the same software on-premises, they benefit from a unified operational/monitoring experience.

  • The Transit VPC architecture enables connectivity that may be desired in some use-cases. For example, you can connect an AWS GovCloud instance and Commercial Region VPC or a Transit Gateway instance to a Transit VPC and enable inter-VPC connectivity between the two Regions. Evaluate your security and compliance requirements when considering this option. For additional security, you may deploy a centralized inspection model using design patterns described later in this whitepaper.

A diagram depicting a transit VPC with virtual appliances

Transit VPC with virtual appliances

Transit VPC comes with its own challenges, such as higher costs for running third-party vendor virtual appliances on EC2 based on the instance size/family, limited throughput per VPN connection (up to 1.25 Gbps per VPN tunnel), and additional configuration, management and resiliency overhead (customers are responsible for managing the HA and redundancy of EC2 instances running the third-party vendor virtual appliances).

VPC peering vs. Transit VPC vs. Transit Gateway

Table 1 — Connectivity comparison

Criteria VPC peering Transit VPC Transit Gateway PrivateLink Cloud WAN VPC Lattice


Regional/Global Regional Regional Regional Global Regional
Architecture Full mesh VPN-based hub-and-spoke Attachments-based hub-and-spoke Provider or Consumer Model Attachments based, multi-region App to App connectivity


125 active Peers/VPC Depends on virtual router/EC2 5000 attachments per Region No limits 5000 attachments per core network 500 VPC associations per service


Security groups Customer managed Transit Gateway route tables No segmentation Segments Servie and service network policies


Lowest Extra, due to VPN encryption overhead Additional Transit Gateway hop Traffic stays on AWS backbone, customers should test Uses the same dataplane as Transit Gateway Traffic stays on AWS backbone, customers should test

Bandwidth limit

Per instance limits, no aggregate limit Subject to EC2 instance bandwidth limits based on size/family Up to 100 Gbps (burst)/attachment 10 Gbps per Availability Zone, automatically scales up to 100 Gbps Up to 100 Gbps (burst)/attachment 10 Gbps per Availability Zone


VPC Flow Logs VPC Flow Logs and CloudWatch Metrics Transit Gateway Network Manager, VPC Flow Logs, CloudWatch Metrics CloudWatch Metrics Network Manager, VPC Flow Logs, CloudWatch Metrics CloudWatch Access Logs

Security group


Supported Not supported Not supported Not supported Not supported Not applicable
IPv6 support Supported Depends on virtual appliance Supported Supported Supported Supported