VPC Peering, Transit Gateway, and Endpoints

VPCs are designed to be isolated. Imagine the development team has one VPC and the data science team has another, but the developers need to connect to an RDS database in the data science VPC. How should this be handled?

There are two options:

1. VPC peering: A lightweight, direct connection between two VPCs.

2. Transit Gateway: A scalable hub-and-spoke model connecting many VPCs and on-premises networks.

The answer depends on a few questions:

• How many VPCs need to be connected?

• Whether they span Regions or accounts?

• The direction and frequency of the traffic?

VPC peering: Point-to-point simplicity

VPC peering is a feature that allows us to connect different VPCs securely, such that their resources communicate with each other as if they reside in the same VPC. It uses the AWS global network to route traffic between VPCs. Because all communication happens through private IP addresses, VPC peering connections never go outside the private IP space and use the internet.

It is important to note that VPC peering requires no additional physical hardware because it uses AWS’s existing infrastructure for connection. Therefore, no single point of failure or bandwidth bottleneck occurs in the communication.

But here’s the catch: it’s non-transitive.

Note: If VPC A is peered with VPC B, and B is peered with C, A cannot talk to C.

This makes it simple, but not scalable for environments with more than a few VPCs. To set up peering: