AWS arguably has the most advanced Networking connectivity among all the major public provider, with several overlapping services and techniques to connect workloads that are running independent from each other in their own VPC, across different accounts and regions.
In this blog post, we would like to share with you the available options for two or more workloads that are running in a separate VPC or account to privately communicate with each other without going over the internet.
The product catalogue in the network connectivity domain in AWS has widened resulting in customers not knowing which service to use in which scenario; In fact below diagram is a slide taken from Re-invent talk that combined all the connectivity services AWS offers in one single diagram and it looks overwhelmingly complex.
The services we are covering in this post are:
- VPC peering
- AWS Transit Gateway
- AWS Private Link
- AWS VPC Lattice
There are few other offerings by AWS that operate within the same domain such as AWS Cloud WAN, and AWS Verified Access which we won’t be covering here.
VPC Peering
“VPC peering” has been the most well-known technique to use for establishing connectivity between workloads due to its relatively easy setup and being around for nearly over a decade. (it was introduced in 2013)
This one is by far the most well known cross VPC connectivity construct. It’s relatively easy to establish connectivity across two VPC. Another benefit of VPC Peering is its performance. if you are operating a latency sensitive workload that needs to communicate with another one across systems in another VPC. Peering would be the most performant way in terms of latency.
VPC peering is ideal when:
- You only have a few VPCs that need to be connected to each other.
- You need the highest bandwidth/lowest latency for your workload.
Transit Gateway
We won’t go into the details of introducing TG as there are tons of official documents and videos that explain this service far better than this post. The most simplistic definition we have for Transit gateway is:
“A highly scalable Router that you can leverage to forward traffic from your VPC to other VPCs, and on-prem networks according to the destination CIDR block of the packet.”
compared to VPC peering, Transit Gateway is a better choice when you require:
- Scalability: You have a large number of VPCs that need to communicate with each other without having to go over the internet to reach the other side.
- Transitive Routing: Transit Gateway supports transitive routing, meaning it allows traffic to flow between any two VPCs that are attached to the same gateway without the need for direct peering between each VPC. In contrast to VPC peering where you need specific peering between any two VPCs in order for them to be able to communicate with each other.
- Centralize management: Transit Gateway offers centralized place to manage routing and security policies between different VPC as opposed to VPC peering where it’s scattered across different VPCs and Accounts.
AWS VPC Lattice
VPC Lattice is the one service that has gotten our attention the most recently even though we don’t have any customers using this service in production. We have spent hours learning about it and building some proof-of-concept with it. It seems like a very capable service with potential to sunset AWS Private Link in many scenarios. There are overlapping features between these two but VPC Lattice clearly offers more advanced features and capabilities than Private Link.
Despite their similarities on the surface there are subtle differences in how they operate such as:
- Private Link operates at layer 4 of the OSI model over TCP and UDP, however VPC Lattice operate at Layer 7 AKA application layer enabling VPC lattice to have more advanced routing capabilities according to the HTTP request header.
- VPC lattice is integrated with AWS IAM that allows you to define fine-grained Authentication and Authorization policies depending on the request payload and its destination allowing consumers to build the integration based on Zero-Trust principals while Private Link allows/denies request at network level using construct such as Security Group.
When deciding between VPC Lattice and PrivateLink, there isn’t a one-size-fits-all answer. However, VPC Lattice can address almost any scenario that AWS PrivateLink supports, and more, though it comes with added complexity.
AWS Private Link
Private Link allows workloads that are deployed inside VPC to connect to AWS services that aren’t deployed into VPC such as API Gateway, Kinesis etc as well as resources that are in another VPC or account over TCP, and UDP without exposing traffic to the public internet.
Private Link is practical choose in situations such as but not limited to:
- Overlapping CIDR block in VPC: If you have VPCs with overlapping CIDR blocks that needs to communicate with each other, PrivateLink allows connectivity in such scenarios since it doesn’t rely on traditional routing.
- Simplicity for TCP workload: Private link is secure, and can be up and running with minimal configuration. It’s ideal for SaaS integrations, legacy architectures, or service exposure between a few VPCs and account. it is in particular simpler than VPC lattice.
Below table is a summary to compare the four services from a few different angels.
In summary there is no one size fits all service to overcome the connectivity requirements in AWS, so our recommendation would be don’t limit your organization or team to only a single option, but also don’t take each option blindly without understanding its caveats.
