AWS Virtual Private Cloud (VPC) is one of the most popular features of AWS. It provides a logically isolated network layer for compute instances. Users can easily and effectively create VPCs in their AWS account(s). And when users have multiple VPCs, the next question is how to connect them together, so that the compute instances from different VPCs can communicate with each other. We’ll go through the VPC connection options in this article.
VPC Peering
When we connect two VPCs together, the first option come to mind is probably VPC peering. VPC peering establishes a networking connection between two VPCs. Compute instances within either VPC can communicate with each other through this connection. And VPC peering supports connections between VPCs in either same account or different accounts, within the same region or across regions.
Throughout this peering connection, there is no involvement of gateways or network appliances. AWS leverages their existing VPC infrastructure to create this peering connection, meaning there is no additional hops between VPCs. So it effectively removes the bandwidth bottleneck and reduces the latency. The network traffic also stays within AWS backbone networking without going out to the public internet, which reduces the security risks.
However, this direct peering connection doesn’t support transitive peering relationships. As shown in the diagram below, without direct peering connection, instances in VPC A can’t communicate with the ones in VPC C, even both A and C are connected with VPC B.
So the problem comes to multi-vpc and multi-account environments. For all VPCs to communicate with each other, we need to build a mesh topology network structure. We can use the formula Number of Connections = [(V-1)*V]/2 to calculate how many peering connections are required based on the quantity of VPCs, e.g. 6 VPCs will require [(6-1)*6]/2 = 15 peering connections, as shown below:
Setting up and manage all these connections is no doubt a huge overhead. So AWS provides another option, the Transit Gateway.
Transit Gateway
Comparing with VPC peering’s mesh structure, Transit Gateway connects VPCs together via the hub-and-spoke structure, as shown below:
This hub-and-spoke structure significantly reduced the network complexity and number of connections. Using the earlier example, we can reduce the number of connections from 15 to 6. And the higher number of VPCs, the more connection reduction it produces. So we can see that this service is definitely welcomed by companies that manage a large number of VPCs.
And as it’s named, Transit Gateway is a gateway services. It’s a network transit hub as a service that provides high availabilities and scalabilities. This means you can attach as many VPCs as you can without worrying about the availabilities and performance issues. Having said that, there are certain limits set by AWS, i.e. it supports up to 5000 connections and 50 Gbps bandwidth. But these numbers to most companies are enough. For more quota information, see Quotas for Transit Gateway.
Transit Gateway was introduced back in 2018. Have we seen it fully replaced the VPC peering? No, and it won’t be. Instead, many companies have chosen to mix these two connection methods in their network architectural design and implementation. The reason being is that there are a few “short slabs” of this Transit Gateway “barrel”. The cost is one of them.
Using our earlier example again, to connect 6 VPCs together via a Transit Gateway, there is a baseline cost as $0.07 USD/hour cost (based on the Sydney region rate) for each attachment. We’ll be looking at 730 hours in a month x 0.07 USD x 6 attachments = 306.60 USD. This is in addition to the traffic cost. Whereas for VPC peering, AWS only charges for the traffic cost, no baseline cost. Yes, even if you create a fully connected mesh with 15 peering connections in this example case, there is no baseline cost from the VPC peering.
In addition, there is a limit of 50 Gbps for Transit Gateway, whereas VPC peering has no bandwidth limits. So based on the pros and cons of both connection options, people choose to use one or another, or a combo of them.
PrivateLink
Another option for establishing connections between VPCs is the PrivateLink. To understand this service and compare it with the other ones we mentioned earlier, let’s take a step back first. Let’s think why we need to establish connections between VPCs.
There are many traffic types that can happen through the connections between VPCs. One common pattern is that one VPC hosts the service provider (e.g. an API service provisioned via a cluster of EC2 instances) and the other VPC hosts the service consumer (e.g. an EC2 instance). The consumer needs to connect to the provider to consume the service. And to make the use case more specific, the traffic shouldn’t go through the public Internet for security reason.
We can achieve this access requirement via VPC peering but requires many configurations across CIDR, route tables and security groups. With the PrivateLink the configuration is simplified. We just need to create a VPC Endpoint and Endpoint Service at the consumer’s VPC and provider’s VPC respectively. That’s it (as shown below). There is no need to worry about path definitions or route tables. We can even establish connection between VPCs that have CIDR overlaps, which is not possible for VPC peering.
So we can see that the PrivateLink provides an alternative and simplified connection option between VPCs. But are there any limitations and drawbacks? Yes, there are. Firstly, unlike VPC peering that supports bi-direction communications, PrivateLink only supports one direction, i.e. the requests can only be initiated from the consumer side.
And from the provider’s VPC side, the VPC Endpoint Service only supports services that can be fronted by the Network Load Balancer (NLB) or Gateway Load Balancer (GLB). We certainly can use the PrivateLink to connect to services that are not relevant to a specific VPC, e.g. AWS PaaS services and Marketplace services. But within a VPC, NLB and GLB are the only options at this stage.
Overall, when we use a VPC endpoint to connect to another VPC’s endpoint service, which is what we were talking about above, the technology that powers this connection is the PrivateLink. Or if we use a VPC endpoint to connect to an AWS service instead of a VPC endpoint service, the technology behind the scenes is also the PrivateLink. It’s more than just VPC-to-VPC connection. For more information about the PrivateLink, see AWS PrivateLink and VPC Endpoints.
Summary
If we just talk about the VPC-to-VPC connections, the three options we mentioned above are the most common ones. However, if there is no restriction of traffic going out to public internet, VPN connection can be another option to connect VPCs together. For more information of the VPN options, see Software Site to Site VPN, Software VPN to AWS VPN, and AWS Managed VPN.
Overall, all options have their own pros and cons. Based on the environment and requirements, we can choose the most suitable option or combine some of them together to serve the purpose.
