Simplifying AWS Private Integrations with Direct VPC Link to ALB

Introduction

Many teams previously built private APIs on AWS using an internal NLB in front of an internal ALB so Amazon API Gateway or other Amazon VPCs could connect through Private Link or Amazon VPC Link. This was necessary when these services supported only NLBs, but it added extra hops, configuration overhead, and cost. With the latest VPC Link enhancements, you can now connect directly to ALBs, eliminating the NLB layer and simplifying your architecture.

This blog walks through what changed, why this matters, and how to think about the migration from “NLB attached to ALB” to “VPC Link endpoint directly to ALB.”

What is the old NLB + ALB pattern?

In the traditional setup, Amazon API Gateway REST APIs or other producer VPCs connect privately to your services via an interface endpoint or Amazon VPC Link that targets an internal NLB.

This pattern existed mainly because:

• Private integrations for REST APIs and Private Link endpoint services historically required NLBs as the integration target, not ALBs.
• ALB provides rich Layer 7 routing, so combining both allows for Private Link connectivity plus Advanced HTTP routing behind it.

The trade-off was a more complex and layered data path: Amazon API Gateway → Amazon VPC Link/Private Link → NLB → ALB → targets.

What is an Amazon VPC Link endpoint to ALB?

Amazon VPC Link is a managed networking construct that lets Amazon API Gateway send traffic directly into your Amazon VPC over private connectivity. Recent enhancements allow a single Amazon VPC Link (especially VPC Link v2 for REST and the standard VPC Link for HTTP APIs) to integrate directly with multiple ALBs or NLBs in your Amazon VPC instead of being tied to a single NLB.

In this new model:

– Amazon API Gateway connects to an Amazon VPC Link that terminates inside your Amazon VPC.

– That Amazon VPC Link can target one or more internal ALBs, without requiring an NLB layer in front.

This effectively turns the ALB into the first load balancer seen after the API Gateway, reducing hops and taking full advantage of ALB’s Layer‑7 feature.

Why do we need this change?

Replacing an NLB attached to an ALB with a VPC Link endpoint that directly addresses the ALB eliminates several pain points.

Key reasons:

• Simplified architecture: Removing the NLB hop reduces configuration complexity (listeners, target groups, health checks) and lowers the number of components required for operation.
• Cost and latency: Fewer load balancers result in lower costs and a slightly shorter code path, which can reduce latency for each request.
• Better use of ALB capabilities: Direct integration with ALB makes it easier to utilize host/path-based routing, HTTP headers, and features such as authentication at the ALB layer.
• Improved scalability: A single VPC Link v2 can now integrate with multiple ALBs or NLBs, supporting more microservices without complex NLB listener workarounds.

For teams running many microservices behind multiple ALBs, this change can significantly simplify private API integration patterns with Amazon API Gateway.

How the new architecture looks?

Conceptually, the diagram changes from:

– Old: Amazon API Gateway → Amazon VPC Link (or Private Link) → NLB → ALB → targets.

– New: Amazon API Gateway → Amazon VPC Link → ALB → targets.

In the new pattern:

• Amazon API Gateway (HTTP APIs or REST APIs with VPC Link v2) utilizes a single Amazon VPC Link that resides in your VPC subnets and is associated with security groups, providing fine-grained access control.
• The Amazon VPC Link is configured with one or more ALBs as integration endpoints, and the ALBs themselves handle routing to services based on host, path, or other HTTP

You still get the ALB’s mature routing and observability features, but you avoid having two separate load balancers in the call path for each request.

Migration approach (high level)

Every environment is different, but at a high level, a typical migration from NLB + ALB to Amazon VPC Link → ALB looks like this:

1) Plan and map traffic 

• Identify which APIs or consumers currently depend on the NLB in front of the ALB and which are coming specifically via Amazon API Gateway.
• Decide which integrations can be migrated to a direct VPC Link → ALB and which still require NLB + Private Link (for example, cross-account VPC endpoint service consumers).

2) Introduce the VPC Link and new integrations 

• Create a new VPC Link in appropriate subnets and attach security groups that permit traffic to your internal ALB.
• Configure Amazon API Gateway routes or methods to use the VPC Link integration that points directly to the ALB, including correct hostnames and paths.

3) Gradual traffic shifting 

• Use staged deployments in API Gateway or routing changes to shift a portion of traffic to the new VPC Link → ALB path while monitoring metrics and logs.
• Once stable, increase the traffic percentage until all API Gateway calls are using the new integration.

4) Decommission the old NLB path 

• After confirming there are no remaining dependencies on the NLB (for API Gateway traffic), remove the NLB from that specific path.
• Keep NLBs where they still serve specific needs, such as AWS Private Link endpoint services for partner VPCs or TCP-only workloads.

This phased approach reduces risk and provides roll-back options throughout the migrations.

Conclusion

Adopting VPC Link endpoints streamlines private integrations, reducing complexity and simplifying operations without compromising security or performance.

Drop a query if you have any questions regarding ALB and we will get back to you quickly.

About CloudThat