🧩 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:
- More infrastructure than necessary (ALB + NLB just to create a bridge).
- Higher latency because traffic needed to make an extra hop.
- More cost and operational overhead: two load balancers to monitor, scale, and secure.
For students or small teams, this architecture was confusin…
🧩 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:
- More infrastructure than necessary (ALB + NLB just to create a bridge).
- Higher latency because traffic needed to make an extra hop.
- 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)
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)
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:
- AWS Official Blog: Build scalable REST APIs using Amazon API Gateway private integration with Application Load Balancer https://aws.amazon.com/blogs/compute/build-scalable-rest-apis-using-amazon-api-gateway-private-integration-with-application-load-balancer/
- API Gateway – VPC Links Documentation: https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-vpc-links.html
- Application Load Balancer Documentation: https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html
- API Gateway REST APIs Documentation: https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-rest-api.html
- AWS Well-Architected Best Practices: https://aws.amazon.com/architecture/well-architected/