What is AWS VPC Peering?
Learning Center | Cloud Networking | AWS VPC Peering
Learning Objectives
After reading this article you will be able to:
- Understand how VPC peering works
- Know the limitations related to VPC peering
- Understand supported peering scenarios
CLOUD NETWORKING ARTICLES
What is Cloud Networking?
What is a Hybrid Cloud Network?
What is Terraform and Infrastructure as Code?
What is AWS VPC Peering?
What is Transitive Routing?
Azure Networking Fundamentals
Microsoft Azure VNet Features
Azure Virtual Private Network (VPN)
How do I configure Azure VNet to VNet
Handling overlapping IPs
What is AWS VPC Peering?
In this post, we will discuss AWS VPC peering and how it can be used to connect resources between same Availability Zones in the same region or resources from different regions.
Because the peering applies to VPC, let’s cover first what a VPC is on a high level.
A Virtual Private Cloud (VPC) is a private network that is isolated from other private networks in AWS. It allows the user to customize the IP ranges used, the security and networking settings.
Each region has a default VPC in which the user can deploy EC2 instances. This allows a plug-and-play operation. On the backend, few things happen transparently to the user when the resources are launched in the default VPC.
However, if the user wants to have as much control as possible on the resources used in AWS, more likely a custom VPC will be required.
At the time of creation, the user must 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(there are few ways how to provide internet access to the EC2 instances from the private subnet)
The detailed default settings of the default VPC and the benefits of using a VPC are outside the scope of this post and can be found in the reference section at the end of the post.
Sometimes 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.
This is a diagram showing the first option:
And this is a diagram showing the AWS Peering option:
A VPC Peering is a network connection between two VPCs that allows traffic routing between the VPCs using private IPv4 or IPv6 addresses.
A 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.
There are few limitations related 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). The details are in the links from the reference section.
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.