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
-
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.
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 |
|---|---|---|---|---|---|---|
|
Scope |
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 |
|
Scale |
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 |
|
Segmentation |
Security groups | Customer managed | Transit Gateway route tables | No segmentation | Segments | Servie and service network policies |
|
Latency |
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 isntance 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 |
|
Visibility |
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 cross-referencing |
Supported | Not supported | Not supported | Not supported | Not supported | Not applicable |
| IPv6 support | Supported | Depends on virtual appliance | Supported | Supported | Supported | Supported |
