Introduction to VPC Peering in AWS
How to privately connect VPCs using VPC Peering over the AWS backbone network
A VPC inside AWS is a customer’s own private network inside the AWS cloud, where we can attach AWS resources like EC2 instances, RDS databases. A Lambda function can also be attached to a VPC. These resources inside a VPC can freely communicate with each other using their private IP addresses. A VPC in AWS can be created inside a single region and cannot span multiple regions.
Each VPC can be sub-divide into multiple subnets, each spanning a particular availability zone inside that region. Subnets can be either public or private, based on if there is a default route table entry to the internet gateway, inside the subnet route tables.
When we create a VPC inside an AWS region we have to specify a CIDR block range for that VPC, which is further sub-divided into CIDR block ranges for the subnets inside that VPC. Each of the resources that we attach to a VPC subnet will be assigned a private IP address from that CIDR block range of that VPC Subnet.
We can create multiple VPCs inside an AWS account, where each VPC could for example, house resources for a particular company department. In another scenario, each VPC could also house resources for different environments, like one VPC for the development environment, another one for test and yet another one for production. We can use any strategy to subdivide our AWS resources into multiple VPCs.
By default, these VPCs are completely segregated from each other and they have no knowledge of each others existence. Resources like EC2 instances and RDS databases inside a particular VPC cannot talk to the resources inside other VPCs, using their private IP addresses. A lot of times these resources inside separate VPCs do not need to actually talk to each other, but there are times when they do have to communicate with each other, across the VPC boundaries.
An example of such a scenario could be, if we have separate VPCs for each company departments and a system inside one particular departments VPC say the ‘procurement’ department needs to talk to a system inside another departments VPC say the ‘accounts’ department, then what how can we facilitate such communication ? One option is to have these systems talk to each other over the public internet with the traffic going out from one VPC to the public internet, via the internet gateway in that VPC and then coming back in via the internet gateway inside the other VPC. The communication happens over the public internet and we may run into issues with the communication happening over an insecure channel and also may experience network latency due to multiple hops over the internet. Also, what if the systems reside inside private VPC subnets that do not have internet connectivity ?
Inside AWS, there are multiple ways to facilitate separate VPCs to talk to each other privately. Following are the options available inside AWS (There could be more network architectures possible that I may have missed) :
- VPC Peering: Direct network connection between a pair of VPCs enabling resources inside those VPCs to talk to each other using private IP addresses. More about this option later on in this article.
- Connect VPCs using VPN: Create a Virtual Private Gateway resource inside one VPC and then use a VPN software installed on an AWS instance inside the other VPC to establish private VPN connectivity between the two VPCs. With this option, we have to ourself ensure high availability of the AWS instance running the VPN software by running multiple EC2 VPN instances for high availability and manage the route table updates if the primary EC2 VPN instance happens to go down for some reason, which could be a lot of work.
- Transit Gateways: If we faced with a scenario where we want to connect multiple VPCs to each other in a full mesh kind of an architecture, along with connectivity from those VPCs to on-premises networks, then a Transit Gateway could be an easier option with less management overhead compared to multiple VPC Peering connections. If we just want to connect two VPCs to each other, then provisioning a Transit Gateway could be an overkill.
- VPC Private Link: This an architecture pattern which could be a good option when the traffic flow between two VPCs is uni-directional and not bi-directional. For example, if we have an application running inside one VPC and we want to enable private access to only that application and not other VPC resources from multiple other VPCs, both from inside our own AWS account as well as other AWS accounts, without having to go out over the public internet, then we can establish connectivity between VPCs using AWS Private Link.
In the remaining sections of this article we will talk in more detail about AWS VPC peering and see how we can create VPC peering connections between VPCs.
VPC Peering
Using VPC peering we can connect two VPCs over the AWS backbone network. Resources inside the two connected VPCs behave as if they are inside a single large network containing all the resources inside both the connected VPCs. The peered connection is highly available by nature and is fully managed by AWS. Instances inside the connected VPCs can communicate with each other using private IP addresses.
Some of the features of AWS VPC Peering are as follows:
- VPCs inside the same region or across different regions can be connected to each other using VPC peering. Back in the day, only VPCs inside the same region could be peered with each other, but that restriction has now been removed by AWS. VPC peering connection requests between VPCs in different regions need to be approved by the account owner.
- We can also peer VPCs across separate AWS accounts. This could be helpful in scenarios where a company has multiple AWS accounts inside a single AWS Organization. We can also peer VPCs in separate AWS accounts that do not belong to the same AWS Organization. VPC peering connection requests between VPCs in different AWS accounts need to be approved by the account owner of the account to which the peering request is sent to.
- AWS uses existing infrastructure inside VPCs for creating the peering connections which are highly available and have no network bandwidth restrictions. No new infrastructure is provisioned inside VPCs for creating new VPC peering connections.
- The two VPCs that are being peered together need to have non-overlapping CIDR blocks. This is important otherwise there is no way for the router to correctly route traffic between the two VPCs. For example, if one VPC has a CIDR range of 10.0.0.0/16 then the other VPC cannot have a fully or partially overlapping CIDR range like 10.0.1.0/24.
- After we are done establishing the peering connection between two VPCs we need to manually update the subnet route tables inside each of the connected VPCs, from where we want to route traffic to the other VPC, with route table entries pointing to the VPC peering connection for the CIDR ranges of the other VPC. This is important to ensure that the resources inside the peered VPCs can route traffic to each other.
- VPC peering connections are non-transitive by nature. For example, if we have a VPC peering connection between VPC A and VPC B and another VPC peering connection between VPC A and VPC C, then VPC B cannot send traffic to VPC C via VPC A, as transitive routing via peering connections is not possible. If VPC C and VPC B need to talk to each other privately then we need to establish a separate VPC peering connection between those two VPCs.
- We can only a single VPC peering connection between any two VPCs. We might think about establishing multiple peering connections between VPCs for high availability or higher bandwidth, but it is not required and also not supported.
- The default number of VPC peering connections possible per VPC is 50. This quota can be increased to a maximum of 125 peering connections per VPC by raising a support ticket.
- Traffic entering a VPC over a VPN connection or AWS Direct Connect connection cannot be directly routed to another VPC over a peered connection due to transitive routing not being supported. It is still possible to do this indirectly using a few work arounds, but a Transit Gateway would be a better fit for such a scenario.
- Traffic travelling over the peered connection to another VPC cannot be sent out to the internet via the internet gateway inside the other VPC. Also, the same applies to VPC endpoints connecting to S3 or DynamoDB from inside the destination VPC.
- Establishing and maintaining peering connections between VPCs by itself is not charged by AWS. Also, all data transferred over a VPC Peering connection that stays within an Availability Zone (AZ) is completely free. All data transferred over a VPC Peering connection that crosses Availability Zones is charged at the standard in-region data transfer rates. For data transfers across regions over a peered connection, standard data transfer rates for outgoing data from the source region are applicable, the incoming data inside the destination region is free.
VPC Peering Demo
Now let’s see how we can setup a VPC peering connection between two VPCs in a demo. We will connect two VPCs, one inside the us-east-1 (N. Virginia) region and the other VPC inside the us-east-2 (Ohio) region, using a peered connection. We will bring up EC2 instances inside both the VPCs and check if they can ping each other successfully over the peered connection, using the other EC2 instances private IP addresses.
- First, lets create a VPC (VPC-A) inside us-east-1 region. The VPC is assigned a IPv4 CIDR block range of 10.0.0.0/16. Also, attach an internet gateway to the VPC so that later on we can successfully SSH into this EC2 instance.
2. After that we need to create a subnet inside the newly created VPC. We can use any availability zone inside us-east-1 region and a CIDR block range of 10.0.0.0/24.
3. Now, lets create another VPC (VPC-B) inside us-east-2 region. The VPC is assigned a IP4 CIDR block range of 10.1.0.0/16 (non-overlapping CIDR range). Also, attach an internet gateway to the VPC so that later on we can successfully SSH into the EC2 instance.
4. Let’s create a subnet inside the newly created VPC. We can use any availability zone inside us-east-2 region and a CIDR block range of 10.1.0.0/24. Attach an internet gateway to the VPC so that later on we can SSH into this EC2 instance.
5. Inside the VPC dashboard scroll down the left menu and click ‘Peering Connections’ inside the left menu and then click the ‘Create peering connection’ button on the top right.
6. Optionally, give a name to the new peering connection that we creating. Select the VPC from where we are initiating the peering connection, in our case that is VPC-A inside us-east-1 region. In the ‘Account’ option inside ‘Select another VPC to peer with’ select ‘My account’. In the region option select ‘Another Region’ and select ‘US East (Ohio) (us-east-2)’ in the regions dropdown. Copy over the VPC ID of VPC-B and paste it inside the ‘VPC ID (Accepter)’ text box. This will initiate the peering connection request but it still has to be accepted from inside VPC-2 for the connection to get successfully established. We will do that subsequently.
7. Below screenshot shows the details of the peering connection request that we just created.
8. Switch to us-east-2 (Ohio) region, navigate to the VPC dashboard and then click ‘Peering connections’ inside the left menu. We should see all the peering connections listed along with a peering connection request with Status of ‘Pending acceptance’. Select the peering connection request with status ‘Pending acceptance’, click the ‘Actions’ button on the top right and then click ‘Accept request’ in the dropdown menu to accept the peering connection request from VPC-A. The peering connection between VPC-A and VPC-B should now be successfully established.
9. Update the route table to VPC-A subnet to include a route table entry for the CIDR block range of VPC-B(10.1.0.0/24) with the VPC peering connection (Name starting with pcx-xxx) as the target for that CIDR block range.
10. We need to do the same inside the route table of VPC-B subnet for the CIDR range of VPC-A (10.0.0.0/24).
11. Bring up an EC2 instance inside VPC-A with a public IP address so that we can SSH into the EC2 instance. Make note of the private IP address of the instance which we will use later on to ping this instance from the EC2 inside VPC-B.
12. We need to also bring up an EC2 instance inside VPC-B.
13. As we can see in the below screenshot, from the EC2 instance inside VPC-A we should be able to successfully ping the other EC2 instance inside VPC-B using the private IP address of the EC2 instance inside VPC-B.
14. Also, we should be able to ping the EC2 instance inside VPC-A from the EC2 instance in VPC-B using the private IP address of the VPC-A EC2 instance.
So, we have seen how we can establish a peered connection between two VPCs across regions and have resources inside those VPCs communicate with resources inside the other VPC using private IP addresses over the AWS backbone network without having to go over the public internet.
For more information about AWS VPC Peering connections please refer below AWS documentation.
Conclusion
As we could see in the above demo, we can very easily establish cost-effective, fully-managed and highly available peering connections between two VPCs, with no network bandwidth bottlenecks. Resources inside the peered VPCs can talk to each other over the private AWS backbone network without having to go over the public internet.
VPC peering could be a good option for establishing connectivity between VPCs, when we do not have too many VPCs to connect. If we have to establish full mesh connectivity between multiple VPCs and also have connectivity to on-premises data centres , then maintaining separate VPC peering connections between VPCs could mean a lot of management overhead and a Transit Gateway could be a better option for such a scenario.
Join FAUN: Website 💻|Podcast 🎙️|Twitter 🐦|Facebook 👥|Instagram 📷|Facebook Group 🗣️|Linkedin Group 💬| Slack 📱|Cloud Native News 📰|More.
If this post was helpful, please click the clap 👏 button below a few times to show your support for the author 👇
