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

Transit VPC solution

Transit VPCs can solve some of the shortcomings of 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 simpler 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 enable 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 — Comparison between VPC peering, Transit VPC, and Transit Gateway

Criteria VPC peering Transit VPC Transit Gateway

Architecture

Full mesh VPN-based hub-and-spoke Attachments-based hub-and-spoke. Can be peered with other TGWs.

Complexity

Increases with VPC count Customer needs to maintain EC2 instance/HA AWS managed service; increases with Transit Gateway count

Scale

125 active Peers/VPC Depends on virtual router/EC2 5000 attachments per Region

Segmentation

Security groups Customer managed Transit Gateway route tables

Latency

Lowest Extra, due to VPN encryption overhead Additional Transit Gateway hop

Bandwidth limit

No limit Subject to EC2 instance bandwidth limits based on size/family Up to 50 Gbps (burst)/attachment

Visibility

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

Security group

cross-referencing

Supported Not supported Not supported
Cost Data transfer EC2 hourly cost, VPN tunnels cost and data transfer Hourly per attachment, data processing, and data transfer