DEV Community

Cover image for 🚀 Integrating API Gateway with Private ALB: The New, Simpler, and More Scalable Way
Afu Tse (Chainiz)
Afu Tse (Chainiz)

Posted on

🚀 Integrating API Gateway with Private ALB: The New, Simpler, and More Scalable Way

#aws #network #apigateway #news

🧩 The Problem

When you work with microservices in AWS (especially in ECS, EKS, or internal applications inside a VPC), sooner or later you need to expose a REST endpoint through Amazon API Gateway, but without making your backend public.

For many years, the only “official” way to integrate API Gateway (REST) with a private Application Load Balancer (ALB) was by placing a Network Load Balancer (NLB) in the middle.

This created three common issues in real-world projects:

  1. More infrastructure than necessary (ALB + NLB just to create a bridge).
  2. Higher latency because traffic needed to make an extra hop.
  3. More cost and operational overhead: two load balancers to monitor, scale, and secure.

For students or small teams, this architecture was confusing and far from intuitive:

“Why do I need an NLB if my backend is already behind an ALB?”

And yes… we were all asking ourselves the same thing.

🔧 The Old Solution:

Until recently, the flow looked like this:

API Gateway → VPC Link → NLB → ALB (Privado)

old-solution

The NLB acted as a “bridge” because API Gateway could only connect to an NLB using VPC Link. ALB wasn’t supported directly.

This worked, but:

  • It was more complex to explain in classes or onboarding sessions.
  • Costs were higher (NLB hourly charges + NLCUs).
  • It introduced extra points of failure.
  • It didn’t feel natural for modern ALB-based architectures.

⭐ The New Solution:

AWS finally heard our prayers 🙏.

Now API Gateway (REST) supports direct private integration with ALB using VPC Link v2.
The new flow looks like this:

API Gateway → VPC Link v2 → ALB (Privado)

new-solution

In summary:

  • No NLB.
  • No unnecessary bridge.
  • Lower cost.
  • Lower latency.
  • Easier to teach and understand.

This allows you to naturally expose your internal microservices behind a private ALB without adding any extra resources.

⚔️ Comparison: Before vs Now

Aspect Old (NLB Required) New (Direct to ALB)
Infrastructure More complex (extra NLB) Much simpler
Cost Hourly NLB + extra NLCUs Only ALB + API Gateway
Latency Higher (extra hop through NLB) Lower
Maintenance Two load balancers One load balancer
Security Good, but more SG rules Equally secure, fewer failure points
Clarity Hard to explain Much more intuitive
Scalability Depends on NLB Highly scalable VPC Link v2
Flexibility Limited to NLB Supports multiple ALBs/NLBs

🎓 Why is this change important?

If you’re learning cloud architecture — especially microservices — this change is a huge benefit:

  • The architecture is easier to understand.
  • You can focus on real concepts, not historical workarounds.
  • Lower cost for student projects or test environments.
  • The traffic path becomes cleaner and more direct.
  • You can use ALB (which is more flexible) without depending on an NLB.

It also unlocks modern patterns:

  • Expose EKS/ECS microservices via API Gateway without making them public.
  • Build more secure internal corporate APIs.
  • Use a single VPC Link v2 to route to multiple ALBs.

🎯 Conclusions

AWS simplified a pattern that had been unnecessarily complex for years. The direct integration between API Gateway and private ALB:

  • Lowers cost
  • Reduces complexity
  • Reduces latency
  • Improves architectural clarity
  • Is perfect for students, small teams, and enterprises

If you were building internal APIs and previously needed an NLB just to bridge API Gateway to ALB… you can forget about that now.

The architecture is cleaner, more modern, and aligned with real cloud-native best practices.

📚 References

Here are the official sources and recommended materials for deeper study:

🌐 Languages

Spanish

Top comments (0)