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
-
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.
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 |
