What is AWS VPC Peering?

In this article, we’ll explore the potential of AWS VPC peering for connecting cloud resources. It can bridge assets within the same or different regions, providing seamless accessibility. Let’s begin by defining VPC on a high level since the peering applies to it.

What is VPC Peering?

VPC Peering is a network connection between two VPCs that allows traffic routing between the VPCs using private IPv4 or IPv6 addresses. VPC Peering can be created between VPCs belonging to the same AWS account, between VPCs belonging to different AWS accounts, between VPCs in the same region or between VPCs between different regions.

What is a Virtual Private Cloud (VPC)?

Before discussing VPC peering, it is important to understand what a VPC is on a high level. A VPC is a private network that is isolated from other private networks in AWS. It allows users to customize the IP ranges used, the security and networking settings. There is a default VPC in each region, but a custom VPC may be required for users who need as much control as possible over their AWS resources.

Limitations to VPC peering

• The VPC between which the peering is set cannot have matching of overlapping CIDR
• Transitive peering is not possible, but there are ways how to achieve this

There are few other limitations for VPC Peering, some specific to inter-region VPC Peering (like MTU size or the impossibility to use IPv6).

How CIDR, Subnets, and VPCs work together

When creating a VPC, it is necessary to specify a set of IP addresses that will be used with that VPC. This set of IP addresses is called CIDR, which cannot be changed after VPC creation. The CIDR can be split into subnets into which the EC2 instances are launched. A public subnet means that the EC2 instances from that subnet have internet access, whereas the EC2 instances from the private subnet do not have internet access.

Use cases for AWS VPC peering

Sometimes VPC peering is required to provide connectivity between VPCs because:

• Two departments that require full access to each other’s resources
• Multiple customers that must not be able to talk to each other, but still be able to provide access to your resources to each customer

To solve this problem, some sort of logical connection is required between the VPCs and there are multiple options to achieve this. You can create a tunnel between two VPC (GRE or IPSec, based on how much security you want and need) or you can use the VPC Peering service from AWS. With the first option, you have the complete control of the routing between the two VPCs, but it also requires advanced knowledge with regards to security and routing. The second option is giving you a plug-and-play option with which you need to know basic information.

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.