What is AWS VPC Peering?

Understanding AWS VPC Peering begins with comprehending the concept of a Virtual Private Cloud (VPC). A VPC in AWS is a segregated, private network within the cloud, tailored to fit specific security and networking requirements. It’s a virtual version of a traditional network, but in AWS’s scalable infrastructure. VPC Peering, then, is a crucial feature for interconnecting these isolated networks, enabling seamless and secure communication across different VPCs.

What is VPC Peering?

VPC Peering is a network connection between two VPCs that facilitates traffic routing between them using private IP addresses. This connection can occur within the same AWS account or across different accounts, and it can span VPCs located in the same or different AWS regions. It essentially creates a direct networking link between two VPCs.

What is a Virtual Private Cloud (VPC)?

A VPC is your portion of the AWS cloud, an isolated network within it. When setting up a VPC, you gain the flexibility to define your own IP ranges, security settings, and network configurations. AWS provides a default VPC, but for more tailored control over your resources, creating a custom VPC might be necessary.

Limitations of VPC Peering

• Non-Overlapping CIDR Blocks: VPCs involved in peering must not have matching or overlapping CIDR blocks.
• No Transitive Peering: Direct peering is possible, but transitive peering (indirectly connecting VPCs through a common peer) is not supported. Alternative solutions are required for such connectivity.
• Inter-Region Limitations: Certain specific limitations apply to inter-region VPC Peering, such as MTU size constraints and the non-availability of IPv6 in some scenarios.

How CIDR, Subnets, and VPCs work together

• CIDR in VPC Creation: A VPC is defined by a CIDR block, a range of IP addresses set during its creation. This range is immutable post-creation.
• Subnet Functionality: The CIDR block is divided into subnets, determining whether EC2 instances in those subnets can access the internet. Subnets can be categorized as public (internet access) or private (no direct internet access).

Use cases for AWS VPC Peering

VPC Peering becomes essential in scenarios where isolated VPCs need to interact. Common use cases include:

• Inter-Departmental Connectivity: For instance, two different departments within an organization needing full access to each other’s resources.
• Customer Segregation: When serving multiple customers, VPC Peering ensures that each customer’s resources remain isolated while still allowing access to shared resources.

Connectivity Options

• Custom Tunnels: Advanced users might opt for custom GRE or IPSec tunnels between VPCs, allowing for finely-tuned control over routing and security.
• VPC Peering: A more straightforward, plug-and-play option that requires basic setup knowledge.

Examples of VPC Peering scenarios

Let’s discuss some of the supported VPC Peering scenarios.

You can have this type of VPC Peering between two VPCs:

Or you can have this type of peering between three VPCs:

In the above example, each VPC will have access to the resources from every other VPC thanks to its direct VPC Peering connection.

Another way to connect VPCs is this one:

In this example, VPC_C will have access to both VPC_A and VPC_B, VPC_A will have access to VPC_C, but not to VPC_B and VPC_B will have access to VPC_C, but not to VPC_A.

There will be no connectivity between VPC_A and VPC_B because VPC Peering does not support transiting routing, meaning you cannot access the resources of a VPC that has a VPC peering with a VPC to which you have a VPC peering.

This can be used where you have multiple customers that you do not want to talk to each other via VPC Peering. They can establish some sort of logical connection between them if they need connectivity, but this will have to be separately than your VPC Peering connections.

When a VPC Peering is created, there are few stages through which a VPC Peering goes through before it becomes active:

• Initiating-request
• Pending-acceptance
• Provisioning
• Active

Once it reaches Active state, it then can be used to carry traffic between the VPCs.

So, let’s see a quick example of how this is set up.

This is the setup:

The goal of this architecture is to make possible the connectivity between the EC2 instances from the private subnets.

I have two VPCs in the same region(as I said, the VPC peering can be performed between VPCs in different regions).

As you can see, the VPCs do not have overlapping CIDRs and there will be two subnets per VPC. One will be private(no internet access) and the other one will be public.

These are the two private subnets(both of them have the third octet .2 in the subnet):

Also, each VPC has its own route table where the two subnets of each VPC are associated with:

There are two EC2 instances started in each VPC, one in each subnet.

As you can see, the EC2 instances from the private subnets do not have a public IP address(therefore no possibility to access it directly), only those from the public subnets. This is because we will connect to the instance from the public subnet first and from there will connect to the EC2 instance from the private subnet:

Now, let’s try to see if there is reachability between the two EC2 instances from the private subnets. A ping test between the EC2 instance from VPC_2 towards the EC2 instance from VPC_1 is not successful:

To get this working, we need to create a VPC peering and modify the route table of each VPC.

To set up the VPC peering, some basic information is requested like the VPC peering requester:

And the VPC accepter:

As you can see from the two above outputs, you can set up VPC peerings between different accounts and between different regions.

In this case, VPC_1 is the requester and VPC_2 is the accepter(you can tell this by the CIDR used):

At that moment, the peering connection will be on the pending state on VPC_1:

You need to accept the request to have the peering active:

Although the peering is active and can carry traffic between the two VPC, you need to populate the route table of each VPC with the CIDR of the peered VPC using as next hop the peering connection.

This is the route table of VPC_1:

As you can see, 10.2.0.0/16(the CIDR of VPC_2) can be reached using the peering connection.

The similar thing must be done on the route table of VPC_2.

Right after this, the two EC2 instances from the private subnets can reach each other:

Once the VPC peering connection is no longer needed, it can be deleted(at which moment, the routing entries that were added specifically for this peering connection can be deleted as well):

At this point, we reached the end of the article where we covered some VPC basics, discussed in more detail the VPC Peering feature and went over a hands-on example of how to configure and use a VPC Peering connection.