🚀 Integrando API Gateway con ALB Privado: La Nueva Forma Más Simple y Escalable

#aws #apigateway #spanish #networking

🧩 El Problema

Cuando trabajas con microservicios en AWS (especialmente en ECS, EKS o aplicaciones internas dentro de una VPC) tarde o temprano necesitas exponer un endpoint REST a través de Amazon API Gateway, pero sin que tu backend sea público.

Durante muchos años, la única manera “oficial” de integrar API Gateway (REST) con un Application Load Balancer (ALB) privado era con un Network Load Balancer (NLB) como intermediario.

Esto generaba tres problemas frecuentes en proyectos reales:

Más infraestructura de la necesaria (ALB + NLB solo para hacer puente).
Más latencia, porque el tráfico tenía que hacer un salto extra.
Más costo y gestión: dos load balancers que monitorear, escalar y asegurar.

Para estudiantes o equipos pequeños, esta arquitectura era confusa y poco intuitiva:

“¿Por qué necesito un NLB si mi backend ya está detrás de un ALB?”

Y sí… esa pregunta nos la hacíamos todos.

🔧 La Antigua Solución:

Hasta hace poco, el flujo se veía así:

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

El NLB actuaba como un “puente” porque API Gateway solo podía conectarse a un NLB mediante VPC Link. El ALB no era soportado directamente.

Esto funcionaba, pero:

Era más complejo explicarlo en clases o onboardings.
Aumentaba costos (el NLB factura por hora + NLCU).
Sumaba puntos de fallo.
No se sentía natural para arquitecturas modernas con ALB.

⭐ La Nueva Solución:

AWS finalmente escuchó nuestras plegarias 🙏.

Ahora API Gateway (REST) soporta integración privada directa con ALB, usando VPC Link v2. Por lo tanto, el nuevo flujo se ve así:

API Gateway → VPC Link v2 → ALB (Privado)

En resumen:

Sin NLB.
Sin puentes innecesarios.
Menos costos.
Menos latencia.
Más claro para enseñar.

Esto hace que puedas exponer natural y directamente tus microservicios internos detrás de un ALB privado sin ningún recurso adicional.

⚔️ Comparativa: Antes vs Ahora

Aspecto	Antigua (NLB requerido)	Nueva (Directo al ALB)
Infraestructura	Más compleja (NLB adicional)	Mucho más simple
Costos	NLB por hora + NLCUs adicionales	Solo ALB + API Gateway
Latencia	Mayor (salto extra via NLB)	Menor
Mantenimiento	2 load balancers	1 load balancer
Seguridad	Buena, pero más SGs/Rules	Igual de segura, menos puntos de fallo
Claridad	Difícil de explicar	Mucho más intuitivo
Escalabilidad	Depende de NLB	VPC Link v2 altamente escalable
Flexibilidad	Limitada a NLB	Permite múltiples ALBs/NLBs

🎓 ¿Por qué este cambio es importante?

Si estás aprendiendo arquitectura cloud, especialmente microservicios, este cambio te beneficia muchísimo:

La arquitectura es más fácil de entender.
Puedes enfocarte en conceptos reales, no en “workarounds” históricos.
Reduces costos en tus proyectos estudiantiles o pruebas.
La ruta del tráfico es más limpia y directa.
Puedes usar ALB (que es más flexible) sin depender de un NLB.

Además, abre la puerta a prácticas modernas:

Exponer microservicios EKS/ECS vía API Gateway sin exponer nada públicamente.
Diseñar APIs internas corporativas más seguras.
Crear gateways centralizados pero con backends distribuidos en múltiples ALBs usando un solo VPC Link v2.

🎯 Conclusiones

AWS simplificó un patrón que llevaba años siendo más complejo de lo que debía. La integración directa entre API Gateway y ALB privado:

Reduce costos.
Reduce complejidad.
Reduce latencia.
Aumenta claridad en la arquitectura.
Es ideal para estudiantes, equipos pequeños y empresas.

Si estabas construyendo APIs internas con microservicios y antes necesitabas un NLB solo para conectar API Gateway con ALB. Ahora, ya puedes olvidarte de eso.

Ahora la arquitectura es más limpia, moderna y alineada con las prácticas reales de desarrollo cloud-native.