So you've got a Virtual Private Cloud (VPC) on AWS. But how do you connect it to other VPCs - or even back to your on-premises infrastructure? In this article, I'll look at two technologies - VPC Peering and PrivateLink - and discuss when to use which.

VPCs in the cloud

On AWS, VPCs are a mechanism for creating a private IP address space for AWS services, such as virtual machines, Docker containers, and Lambda functions.

A VPC consists of a series of subnets, each representing a slice of the VPC's total virtual IP address space. VPCs can be public, private, or isolated.

Prior to VPCs, when you created an instance of an AWS service, it existed by default in AWS's public IP address space. This isn't ideal for a number of reasons. The biggest is that you shouldn't expose private application resources to the public.

By creating your own address space, you can keep internal resources private. That enhances your application stack's security. You can put customer-facing resources in a public subnet, while internal resources that require outbound Internet connectivity can run in a private subnet connected to the Internet via a NAT Gateway.

Networking VPCs together

But what happens when you need to connect your VPC to other networks?

There are multiple scenarios in which you might want to network VPCs, not only to one another, but to non-cloud resources entirely. A few such scenarios include:

Connecting core services to a customer's VPC. You may be a systems integration vendor or a customer success team with software that you deploy via flexible deployments into your customer's own VPCs. However, you may also run a set of core services - REST APIs, storage, etc. - in your own VPC to which your customer's deployments require access.

Connecting multiple departments in a company. Different departments in your company (legal, HR, finance, engineering, etc.) may, for security reasons, run their cloud infrastructure in separate VPCs. Connecting them enables secure communication between departments without exposing traffic to the Internet.

Connecting a VPC to on-premises services. You may be moving to the cloud but continue to run legacy software on your on-premises software. Or, you may need to keep certain components on-prem for security or data residency reasons. A hybrid architecture enables you to satisfy these requirements while also taking advantage of the on-demand scalability of the cloud.

VPC connectivity services on AWS

How do you pull this off on AWS? Let's look at two technologies that enable hybrid architecture: VPC Peering and AWS PrivateLink.

AWS VPC Peering

AWS VPC Peering is Amazon's built-in solution for connecting two or more VPCs in an extended virtual network.

VPC Peering enables connecting multiple VPCs to one another using the same technology inherent to VPCs on AWS's backend. It enables connecting VPCs in a number of different scenarios:

• VPCs in the same region
• VPCs in separate regions (inter-region VPCs)
• VPCs in separate AWS accounts

In all cases, traffic doesn't flow through the public Internet. All traffic is encrypted and stays on AWS's own private backbone network. This reduces the risk of interception.

Using VPC Peering, you can create different types of extended wide-area networks. For example, you could create a hub-and-spoke model where a single VPC provides services to multiple VPCs that connect to it. Or you can create a mesh network where multiple VPCs are connected to one another in a chain.

How VPC Peering connections work

To create a VPC Peering connection, a requestor VPC makes a request to an acceptor VPC. The acceptor VPC then has 72 hours to accept it.

If accepted, the owners of both VPCs will need to modify their routing tables so that traffic addressed to the other VPC's address ranges is forwarded. Once this is done, traffic addressed to the other VPC's private IP addresses will resolve to the subnets in the connected network.

You can optionally configure private DNS resolution for your peering connection. (By default, if a DNS name in a VPC has a public IP address associated with it, it resolves to the public IP instead of the private one.)

VPC Peering limitations

VPC Peering isn't without limitations. The hardest limitation is that the peered networks must not have any IP address space overlap. In other words, two VPCs using an address range of 10.0.0.0/24 couldn't connect to one another as it would generate conflicts.

Additionally, VPC Peering isn't transitive. In other words, if VPC A is connected to VPC B, and VPC B is connected to VPC C, VPC A cannot connect directly to VPC C. To enable this, you'll need to connect VPC A and VPC C directly (or use some sort of bridge service in VPC B that both understand).

Finally, while there's no fee to enable VPC Peering, there's a hidden cost if you're transferring data across regions. As I discussed in my post on NAT Gateways and NAT instances, inter-region data costs can quickly add up to the point where a seemingly "cheap" option becomes unaffordable.

AWS PrivateLink

Another choice for interlinking VPCs is AWS PrivateLink. PrivateLink is a more generalized technology for linking VPCs to other services. This can include multiple potential endpoints:

• AWS services, such as Lambda or EC2
• Services hosted in other VPCs
• Application endpoints hosted on-premises

The goal of PrivateLink is to keep communications more secure. As with VPC Peering, traffic funneled through PrivateLink travels exclusively over the Amazon backbone without hitting the public Internet.

Using AWS PrivateLink

How you use PrivateLink depends on what type of service you wish to connect. For this article, I'll focus on exposing one of your own services to a VPC using PrivateLink.

To expose a service via PrivateLink, you expose an endpoint service in your VPC. You use Identity and Access Management (IAM) roles to control which AWS accounts and users can access your service.

You then create a Network Load Balancer as the front end for your service. Finally, you create an instance of your service in your VPC's subnets and register them with a load balancer target group.

if you want to link your on-premises resources with PrivateLink, you'll need to use AWS DirectConnect. DirectConnect establishes a direct physical connection between the AWS backbone and your own network.

Like VPC Peering, PrivateLink pricing is pretty straightforward - though you have to watch out for data transfer costs as usual.

AWS PrivateLink Limitations

A major limitation of PrivateLink is that it's a regional service. A service endpoint exposed via PrivateLink can only be accessed in the region where the endpoint is hosted. To make it available in other regions, you'll need to use VPC Peering (or create a multi-regional deployment).

PrivateLink also only supports the TCP protocol. If your service uses UDP, you'll need to use VPC Peering.

Finally, if you use DirectConnect to expose on-premises resources via a VPC, you're going to pay a hefty sum. By AWS's own calculations, a basic installation will run you up to USD $1,000/month. More resilient configurations can cost up to $15,000 monthly.

When to use VPC Peering vs. AWS PrivateLink

So when would you use VPC Peering versus PrivateLink?

VPC Peering is a good choice if you want to interconnect two or more VPCs within your company. You may also use it for integrating closely with trusted partners.

For sharing specific services with customers and partners, PrivateLink may be a better choice. It limits your exposure by providing access to a specific service rather than your entire network.

You'll also need to use PrivateLink in a few specific scenarios:

• Connecting securely to AWS services from within a VPC
• Connecting services in VPCs with overlapping IP ranges
• Connecting securely to on-premise services from your VPCs

TinyStacks makes VPC deployments painless

No matter how you connect your and your customer's VPCs, you still need a way to deploy your applications into them. TinyStacks creates deployable, versioned application stacks that you can easily deploy into your customer's cloud accounts. Check us out today to see how we can simplify your deployment processes!