Cristhian Becerra

Posted on Oct 12 • Edited on Oct 28

Amazon VPC private connectivity options: VPC Peering vs Transit Gateway vs PrivateLink

#english #aws #networking #connectivity

TL;DR: In the world of cloud computing, ensuring secure and efficient communication between various resources is paramount. Amazon Web Services (AWS) offers several options for private connectivity within and between Virtual Private Clouds (VPCs). This article explores three primary methods: VPC Peering, AWS Transit Gateway, and AWS PrivateLink. Each method has its unique features, benefits, and use cases, making it essential to understand their differences to choose the right solution for your needs. 🙌🏻

Estimated reading time: 15 minutes
Level: 200
Spanish version: Opciones de conectividad privada de Amazon VPC: VPC Peering vs Transit Gateway vs PrivateLink

Introduction

If you have two EC2 instances in different Amazon VPCs, they probably shouldn’t be communicating through public IP addresses. In that case, you should use VPC Peering to establish private communication between the VPCs.

Eventually, as your infrastructure grows and you have many VPCs that need to connect with each other, the number of peering connections will increase significantly, along with the effort required to manage them. That’s when you might consider using AWS Transit Gateway to implement a Hub & Spoke design that’s easier to manage at scale.

That might seem to solve the private interconnectivity problem, but both VPC Peering and Transit Gateway establish a full bidirectional communication tunnel, allowing any ENI in VPC A to communicate with any ENI in VPC B. For some, that might not seem very secure.

At that point, PrivateLink comes into play. It allows you to expose only specific endpoints from VPC B, so that VPC A can consume them in a unidirectional way, without allowing unrestricted traffic between VPCs. This is particularly important when the VPCs belong to different owners.

So what now? Is that really all there is to choosing between these three AWS services? Let’s say that’s the basic idea, but it’s a bit more complex than that. In this article, we’ll explore the key features of each service and provide detailed comparisons that you’ll likely find useful. 🚀

Why It Matters to Understand Amazon VPC Private Connectivity Options

Most of our traffic in the cloud probably shouldn’t be going through the Internet. However, this is often the default behavior when we first start with AWS: we expose everything through a public IP address and consume public endpoints via an Internet Gateway.

But routing all your traffic through the Internet not only exposes you from a security standpoint, it can also lead to higher costs compared to a private and secure option. What? More security at a lower cost? That’s right. 🤯

AWS offers several options that make this possible. For example, Gateway Endpoints allow your VPC resources to communicate with services like Amazon S3 or Amazon DynamoDB without data transfer costs. I’ve seen cases where customers had EC2 instances making millions of requests to S3 per month, and believe me, data transfer costs to the Internet aren’t cheap. With an incredibly simple implementation like Gateway Endpoints, they could have saved thousands of dollars on their AWS bill.

Now, the focus of this article isn’t on Gateway Endpoints, but rather on other, more advanced connectivity options that bring benefits mainly in the areas of security and private connections. Some of them are more secure and private than others, it always depends on your use case.

But my point is this: if you don’t know these AWS services, along with their benefits and limitations, you might fail to properly analyze the trade-offs and end up making the wrong decision when choosing the most suitable service for your case. That’s why it’s important to understand the private connectivity options available in Amazon VPC.

VPC Peering

VPC Peering allows you to connect two VPCs privately using AWS’s network, making them behave as if they were in the same network. This connection can be established between VPCs in the same AWS region or across different regions. Additionally, VPC Peering supports connections between VPCs owned by different AWS accounts.

Key Features of VPC Peering

Private Connectivity: Enables private communication between VPCs.
Cross-Region and Cross-Account: Supports VPCs in different regions and accounts.
Non-Overlapping CIDRs: VPCs must have non-overlapping CIDR blocks.
Route Table Updates: Requires updating route tables in each VPC’s subnets to ensure instances can communicate.

VPC Peering Limitations

CIDR Overlap: VPCs must not have overlapping CIDR blocks.
Non-Transitive: VPC Peering connections are not transitive; each VPC that needs to communicate must have a direct peering connection.
Single Connection per VPC Pair: Only one VPC peering connection can be established between two VPCs.
Connection Limit: Maximum of 125 VPC peering connections per VPC.

Invalid Scenarios for VPC Peering

VPN or Direct Connect connection to on-premises network.
Internet access through a peered VPC’s internet gateway.
Internet access through a peered VPC’s NAT Gateway.
Access to S3/DynamoDB through a VPC Gateway endpoint.

VPC Peering Connection with Multiple VPCs

When multiple VPCs need to communicate with each other using peering, you must create a full mesh of peering connections. This quickly becomes complex as the number of VPCs grows.

This architecture is already starting to have too many peering connections to manage, right? I think I’m beginning to notice the Full Mess — sorry, Full Mesh — in the network. It’s better to move on to the next service: AWS Transit Gateway. 😂

AWS Transit Gateway

Transit Gateway allows customers to interconnect thousands of VPCs and on-premises networks in a hub-and-spoke model. It simplifies network management by centralizing connectivity.

Key Features of Transit Gateway

Attachments: Supports attachments for VPCs, peering connections with other Transit Gateways, VPNs, Direct Connect Gateways, and third-party network appliances.
Features: Includes multicast support, MTU, appliance mode, AZ consideration, and TGW Sharing.
Architectures: Supports architectures like centralized traffic inspection, centralized egress and shared services.

Why Use Transit Gateway

Scalability: Supports up to 5000 attachments.
Hybrid Connectivity: Enables hybrid connectivity via VPN and Direct Connect.
Simplified Management: Reduces complexity in managing multiple VPC connections.

Transit Gateway with Multiple VPCs

A Transit Gateway acts as a central router for all connected VPCs, drastically simplifying connectivity management. Each VPC only needs a single attachment to the TGW.

Transit Gateway with On-Premises Connection

Transit Gateway integrates with AWS Site-to-Site VPN and *AWS Direct Connect * to extend your private network into AWS securely.

Transit Gateway Peering Across AWS Regions

Transit Gateway supports inter-region peering, allowing you to build a global private network between AWS regions without exposing traffic to the internet.

Important Considerations for Transit Gateway

DNS Resolution: Supports DNS resolution for all VPCs attached to the TGW.
RAM Sharing: Can be shared using Resource Access Manager (RAM) across AWS accounts.
Billing: Billed per hour, per attachment, with data processing charges.
Bandwidth: Supports up to 50 Gbps total VPN bandwidth with ECMP.
MTU: Supports an MTU of 8500 bytes for traffic between VPCs and 1500 bytes for VPN connections.

VPC Peering vs Transit Gateway

Feature	VPC Peering	Transit Gateway
Architecture	One-to-One connection – Full Mesh	Hub and Spoke with multiple attachments
Hybrid Connectivity	Not supported	Supported via VPN and Direct Connect
Complexity	Simple for fewer VPCs, Complex as number increases	Simple for any number of VPCs and hybrid network connectivity
Scale	125 peering connections per VPC	5000 attachments per TGW
Latency	Lowest	Additional Hop
Bandwidth	No limit	50 Gbps per attachment
Security Group Reference	Supported	Supported (Inbound rules only)
Subnet Connectivity	For all subnets across AZs	Only subnets within the same AZ in which TGW attachment is created
Transitive Routing	Not supported	Supported
TCO	Lowest – Only Data transfer cost	Per attachment cost + Data transfer cost

All very nice, but remember that neither of these two services solves the problem of VPCs with overlapping CIDRs. In addition, both establish a very broad bidirectional tunnel between VPCs, and once you get to know the next service, AWS PrivateLink, you’ll think twice before immediately choosing one of these services for your private connectivity. 🧐

AWS PrivateLink

AWS PrivateLink, in conjunction with VPC endpoints, enables secure and private connections between your VPC and supported AWS services, including those hosted by other AWS customers or partners.

Why Use VPC Endpoints

Private Communication: Enables secure communication between your VPC and AWS services without using the internet.
Reduced Attack Surface: Removes the need for Internet Gateways, NAT devices, or VPNs, minimizing exposure.
Broad Service Support: Works with AWS native services, partner services, and those hosted by other AWS customers.
Controlled exposure: Allows you to expose only specific applications or endpoints instead of the entire network.
Overlapping CIDR compatibility: Solves the dilemma of private connectivity between VPCs that use overlapping IP address ranges.

Without VPC Endpoints and PrivateLink

Without PrivateLink, your traffic to AWS services travels over the public internet, even though both resources reside in AWS. This introduces additional latency, security exposure, and reliance on internet routing.

With VPC Endpoints and PrivateLink

With PrivateLink, your VPC connects privately to AWS or third-party services via local ENIs (Elastic Network Interfaces), ensuring traffic stays within the AWS network backbone.

VPC Endpoints and PrivateLink Overview

Provide private network connectivity between VPCs and AWS services.
Eliminate the need for Internet Gateways or NAT Gateways.
Endpoints are redundant, horizontally scaled, and highly available.
Gateway Endpoint: Access Amazon S3 and DynamoDB only.
Interface Endpoint: Access services across accounts or other VPCs.
Other endpoint types: Gateway Load Balancer, Resource, and Service-Network.

VPC Endpoints Powered by PrivateLink

Interface Endpoint: For accessing services deployed in other VPCs and AWS accounts.
Resource Endpoint: For specific resources.
Service-Network Endpoint: For VPC Lattice service networks.
Support for IPv4 and IPv6: NAT and UDP traffic support.

Important Considerations for VPC PrivateLink

Local IP Addresses: VPC endpoints create local IP addresses using ENI.
Overlapping CIDR Support: Can connect services inside VPCs with overlapping CIDR blocks.
High Availability: Create VPC endpoints across multiple Availability Zones.
Security Groups: Uses Security Groups – inbound rules.
Traffic Support: Supports IPv4 and IPv6 traffic over TCP and UDP.
Access from Other Networks: Can be accessed from other networks like Peered VPCs, Transit Gateway, VPN, or Direct Connect.

VPC communication with overlapping CIDRs

PrivateLink enables communication between VPCs that use overlapping CIDR blocks without requiring routing changes.

VPC endpoint with security group

PrivateLink endpoints are associated with ENIs and protected by security group inbound rules for controlled access.

Access from Other Networks

PrivateLink endpoints can be accessed from external networks such as Peered VPCs, Transit Gateway, VPN, and Direct Connect.

AWS PrivateLink vs VPC Peering

VPC Peering: Useful for many resources communicating between peered VPCs.
PrivateLink: Ideal for allowing access to a single application hosted in your VPC without peering the VPCs.
CIDR Overlap: VPC peering cannot be created with overlapping CIDRs, but PrivateLink supports it.
Connection Limits: Maximum of 125 peering connections; no limit on PrivateLink connections.
Traffic Origin: VPC peering enables bidirectional traffic origin; PrivateLink allows only the consumer to originate traffic.

Lessons Learned

In this line of work, you’ll constantly be performing trade-off analyses. Sometimes, a single service won’t be the perfect solution to your problem; you’ll need to combine them or even get a bit creative. 🤔

For me, the most important takeaway from these lessons is the importance of cost in your trade-off analysis — and that, to avoid surprises at the end of the month, you should always keep service pricing in mind.

Because yes, Transit Gateway can be an excellent option for managing multiple large-scale connections, but it also comes with a considerable cost for each attachment and every gigabyte of processed traffic, while VPC Peering is practically free.

Likewise, you might lean toward using PrivateLink so your EC2 instances can consume all AWS services through private endpoints, but remember that each endpoint has a fixed cost plus a data processing charge. It might make sense to use it only for services like AWS Secrets Manager or AWS KMS, but not necessarily for Amazon S3 or Amazon CloudWatch, especially if you’re not handling sensitive data.

One additional comment: as mentioned earlier, Transit Gateway is useful for multiple centralized architecture patterns, one of which is the shared services pattern. This refers to situations where multiple VPCs need access to a PrivateLink endpoint. In such cases, it might not be the best idea to create the same endpoint in each VPC. Instead, you can implement it in a shared services VPC, allowing all consumers to access the endpoint from there in a centralized way.

Conclusion

Choosing the right private connectivity option in AWS depends on your specific requirements, including the number of VPCs, the need for hybrid connectivity, and the complexity of your network architecture. VPC Peering is ideal for simple, direct connections between a limited number of VPCs. Transit Gateway offers scalability and simplified management for larger, more complex networks. AWS PrivateLink provides secure, private connections to AWS services and other VPCs, especially useful for specific application access without full VPC peering. Understanding these options helps you design a robust, secure, and efficient network architecture on AWS.

What’s Next

In the next section, I’ll include the official resources and documentation for the services mentioned, along with some interesting points about the topics I’ve covered — in case you’re interested in continuing to learn about them or diving deeper to determine whether they truly apply to your use case.

I also invite you to deploy and test these three services in your own AWS account and let me know in the comments what you thought of them. And if you’re already familiar with them, share in the comments which specific trade-off led you to choose one service over another, or which feature you discovered that completely changed your perception of a particular service. ✍🏻

You may have heard of Amazon VPC Lattice, a relatively new service compared to the others mentioned in this article, but one that’s quickly gaining adoption as one of the most modern options for private connectivity in Amazon VPC. I encourage you to check it out — I’ll be testing it soon and writing an article about it.

DEV Community