Secure Serverless Architectures: The Definitive Guide to API Gateway VPC Link V1 and V2
Discover the key architectural differences between VPC Link V1 for REST APIs and VPC Link V2 for HTTP APIs. Learn how to securely connect your public serverless workloads to private resources like Application Load Balancers, Network Load Balancers, and containers.
The Challenge of Private Serverless Connectivity
When designing network and content delivery solutions in the cloud, we love the automatic scalability of serverless services like Amazon API Gateway. However, in enterprise environments, our databases and microservices usually live in private subnets, completely isolated from the public internet.
"The real architectural challenge is not just exposing an API, but connecting the public edge to our private network securely, efficiently, and with the lowest possible latency."
To solve this, AWS provides the VPC Link resource, but its behavior and capabilities change drastically depending on whether we use REST APIs or HTTP APIs.
The Classic: VPC Link V1 for REST APIs
If your use case requires native integrations with AWS WAF, payload transformations with Apache Velocity, or monetization through developer portals, REST APIs are the right choice. To connect these APIs to private resources, the original VPC Link model is required.
The Technology Behind V1
This model is powered by AWS PrivateLink, creating a managed Endpoint Service within your VPC.
The Strict Integration Rule
VPC Link V1 has a fundamental architectural limitation: it strictly requires a Network Load Balancer (NLB) as an intermediary.
Architectural Impact
It is not possible to route traffic directly to EC2 instances, containers in Amazon ECS/EKS, or an Application Load Balancer (ALB). If the application already requires an ALB for Layer 7 routing, the standard design forces you to place the NLB in front of the ALB, adding extra network hops.
The Evolution: VPC Link V2 for HTTP APIs
With the introduction of HTTP APIs, which focus on delivering higher performance and lower costs, AWS completely redesigned the private connectivity layer by launching VPC Links V2.
AWS Hyperplane-Based Architecture
Unlike V1's reliance on PrivateLink, the magic of VPC Link V2 is powered by AWS Hyperplane, the same massively scalable technology behind NAT Gateway.
Total Target Flexibility
By provisioning Elastic Network Interfaces (ENIs) directly into your selected subnets, VPC Link V2 removes the exclusive dependency on the NLB and enables much more efficient integrations.
Multi-Balancer Support
VPC Link V2 allows you to route traffic directly to Application Load Balancers (ALB) natively, but it also supports routing traffic to Network Load Balancers (NLB) if Layer 4 networking is required.
AWS Cloud Map for Microservices
For teams managing highly containerized infrastructures, VPC Link V2 offers direct integration with AWS Cloud Map. This allows you to discover and connect your API directly to ECS tasks or EKS pods without needing to provision any intermediate load balancer, drastically reducing infrastructure costs.
Practical Networking Considerations
When deploying these solutions in production environments, managing network traffic and security is vital:
- Security Groups: In V1, security is managed at the destination resources behind the NLB. In V2, the VPC Link ENIs require a dedicated Security Group that controls outbound traffic to the ALB or containers.
- Immutability: The network configurations (subnets and SGs) of a VPC Link V2 are immutable after creation. Modifications require deploying a new link entirely.
- Timeouts: Both architectures maintain a strict 29-second integration timeout, requiring asynchronous patterns (like Amazon SQS integrations) for heavy backend processes.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article