Welcome back to the AWS Networking series. So far, we have covered a wide range of foundational topics. We started with the basics of building a VPC, creating subnets, configuring route tables, and providing Internet access with an Internet Gateway and a NAT Gateway. We then looked at the difference between stateful Security Groups attached to an instance's ENI and stateless Network ACLs applied at the subnet level. Most recently, we covered how to build a hybrid network using a Site-to-Site VPN.
In this post, we will continue to expand on VPC connectivity by looking at what AWS VPC Peering is and how to configure one.
If you are completely new to AWS networking, I highly recommend checking out our introductory posts linked below. However, if you are already familiar with the basics, you can carry on with this post.
Suresh Vina
What Is AWS VPC Peering?
A VPC is a virtual network dedicated to your AWS account and is logically isolated from other virtual networks in the AWS Cloud. It's important to remember that even if you create multiple VPCs in the same AWS account, they cannot talk to each other by default. For example, you could have a 'lab-vpc', a 'dev-vpc', and a 'prod-vpc' all in the same account and Region, but they would be completely isolated from one another.
So, how do you make connectivity between different VPCs? This is where VPC Peering comes in. A VPC peering connection is a networking connection between two VPCs that enables you to route traffic between them using their private IP addresses. Once a peering connection is established, instances in either VPC can communicate with each other as if they are within the same network. You can create a VPC peering connection between your own VPCs, with a VPC in another AWS account, or even with a VPC in a different region.
All traffic is encrypted with no single point of failure or bandwidth bottleneck. Traffic always stays on the global AWS backbone and never traverses the public Internet.
There is no charge for creating a VPC peering connection itself. You are only billed for the data that is transferred over that connection. This means if you create a peering connection and simply leave it there without sending any traffic across it, you will not incur any charges.
VPC Peering Concepts
Let's look at a simple example where we create a VPC peering connection between two VPCs in the same AWS account and Region.
In this scenario, we have two VPCs - lab-vpc with the CIDR 10.200.0.0/16 and dev-vpc with the CIDR 10.201.0.0/16. As shown in the diagram, each VPC has one subnet and one EC2 instance. Our goal is to enable the two EC2 instances to communicate with each other using their private IP addresses.
You can create the VPC peering connection from the 'Peering connections' section under the VPC service in the AWS console.
When you create a peering connection, one VPC acts as the 'Requester' and the other as the 'Accepter'.
Once the request is in place, you will need to go and accept it for the connection to become active.
However, creating the peering connection is only the first step. For traffic to flow, you must also update the route table in each VPC. Each route table needs a new route that points to the peering connection as the next hop for any traffic destined for the other VPC's CIDR range.
You can also go to the 'Route tables' tab for the peering connection itself to see in which route tables this specific peering connection is referenced. In our case, as shown in the image, this connection is correctly referenced in two places - the route table for the lab-vpc and the route table for the dev-vpc.
To test the setup, I connected to the instance in the lab-vpc (with the IP address 10.200.10.187) and from there, I tried to ping the private IP of the instance in the dev-vpc (10.201.10.160).
The ping was successful, which confirms that the VPC peering connection is active and the route tables in both VPCs are correctly configured to allow traffic to flow between them using their private IP addresses.
AWS VPC Peering Between AWS Accounts
Next, let's look at creating a VPC peering connection between two different AWS accounts located in different Regions. For this example, my primary account with the lab-vpc (10.200.0.0/16) is in the London Region. I am going to peer this with a new VPC (10.210.0.0/16) that I have created in a second AWS account located in the Frankfurt Region.
The process starts similarly; you create a VPC peering request from the primary account. However, in the creation wizard, you must specify that the accepter VPC is in 'another account' and select the correct destination Region (Frankfurt). You will then need to provide the AWS Account ID of the second account and the VPC ID of the VPC you want to peer with.
The owner of the second account must then log in to their account in the Frankfurt region to find and accept the pending peering request.
Once the peering connection is accepted and active, the rest of the setup is the same as before. You must update the route tables in both VPCs to direct traffic destined for the other VPC's CIDR range to the peering connection.
After launching an instance in the new Frankfurt VPC and updating the routes, I was able to successfully ping between the instances in London and Frankfurt as expected.
When to Use VPC Peering
VPC Peering is a great solution if you are just starting out or have a small number of VPCs that you need to connect quickly. However, you need to keep in mind that you must create a peering connection between every VPC that needs to communicate. If you have over 10 VPCs that all need to talk to each other, you would need to manage a lot of individual peering connections, which can become a mess very quickly.
It is also important to understand that VPC peering is not transitive. This means that the routes do not extend beyond the two directly peered VPCs.
Looking at the diagram, even though VPC A is peered with VPC C, and VPC B is also peered with VPC C, this does not mean that VPC A can communicate with VPC B. The traffic cannot pass through VPC C to get from A to B. For that to work, you would need to create a third, direct peering connection between VPC A and VPC B.
Closing Up
As we have seen, VPC Peering has its limitations. It is non-transitive, which means you need to create a full mesh of connections for complete connectivity. For example, if you have five VPCs that all need to talk to each other, you would need to peer each VPC to every other VPC individually.
This limitation of VPC Peering provides a good segue to our next topic - AWS Transit Gateway (TGW). Transit Gateway simplifies VPC-to-VPC connectivity (and more) by acting as a cloud router in a 'hub and spoke' model, which eliminates the need for complex, full-mesh peering connections. In the next post, we will look at what a Transit Gateway is and how it works.
