CloudFront podía exponer nuestra API REST en EKS. El problema era usarlo como API Gateway

AWS Community Builders · Arquitectura de referencia anonimizada · Septiembre de 2026

Durante el diseño de una plataforma de identidad basada en microservicios sobre Amazon EKS tomamos una decisión que parecía natural: ya teníamos Amazon CloudFront para el frontend, así que también lo usamos como entrada para las APIs REST.

La solución funcionaba. Los clientes podían ejecutar GET, POST, PUT, PATCH y DELETE; CloudFront enviaba las solicitudes al Application Load Balancer público y el Ingress de Kubernetes las dirigía al microservicio correcto.

Sin embargo, que una solución transporte tráfico HTTP no significa que sea la frontera adecuada para gobernar una API.

Ese fue el aprendizaje: CloudFront era una buena CDN, pero le estábamos pidiendo que se comportara como una plataforma de gestión de APIs.

CloudFront no era el problema

CloudFront admite los verbos utilizados por una API REST. AWS documenta que una distribución puede reenviar GET, HEAD, OPTIONS, PUT, PATCH, POST y DELETE. No obstante, únicamente almacena en caché respuestas de GET y HEAD y, de forma opcional, OPTIONS (AllowedMethods de CloudFront).

Esto hace que CloudFront tenga mucho sentido para contenido estático, descargas y respuestas GET realmente cacheables. En una plataforma de autenticación, en cambio, gran parte del tráfico está compuesto por operaciones dinámicas y sensibles: login, MFA, emisión y revocación de tokens, administración de usuarios y autenticación M2M. Para esas operaciones, la caché aporta poco o debe estar deshabilitada.

El error arquitectónico no fue técnico sino semántico: confundimos distribución en el borde con gobierno del ciclo de vida de una API.

Arquitectura inicial

El flujo público era sencillo:

1. Amazon Route 53 resolvía el dominio.
2. CloudFront recibía tanto el tráfico web como el tráfico de APIs.
3. Un ALB público exponía el Ingress del clúster EKS.
4. Kubernetes dirigía cada path al servicio correspondiente.

Este diseño reducía el número inicial de componentes, pero produjo varias señales de alerta:

• El origen de las APIs continuaba siendo públicamente direccionable y debía protegerse por separado.
• Las políticas de headers, CORS, límites y seguridad se distribuían entre CloudFront, WAF, Ingress y cada aplicación.
• No existía una capa nativa para expresar consumidores, rutas, etapas y políticas de API.
• La observabilidad del borde no estaba organizada alrededor de conceptos como route, stage, authorizer o consumidor.
• Aplicar cuotas diferenciadas a integraciones M2M requería lógica adicional fuera de CloudFront.
• Cada microservicio terminaba resolviendo preocupaciones transversales que deberían ser consistentes.

CloudFront seguía haciendo bien su trabajo. Simplemente ese trabajo no era suficiente para una API pública consumida por navegadores, aplicaciones aliadas y clientes M2M.

Arquitectura propuesta

La propuesta separa responsabilidades:

• CloudFront permanece frente al frontend, donde la distribución global y la caché sí son parte principal del problema.
• Amazon API Gateway se convierte en la entrada pública de las APIs.
• API Gateway usa una integración privada y VPC Link para conectarse a un ALB o NLB interno.
• El Ingress de EKS conserva el enrutamiento hacia los servicios públicos.
• Las llamadas entre microservicios continúan dentro del clúster mediante Kubernetes Services y gRPC; no regresan al borde público.
• El proveedor OIDC conserva una entrada dedicada, porque moverlo detrás del gateway requiere validar redirects, cookies, headers y todos los flujos del protocolo como una decisión independiente.

AWS permite que las integraciones privadas de HTTP API se conecten, mediante VPC Link V2, a un Application Load Balancer, Network Load Balancer o un servicio registrado en AWS Cloud Map (private integrations para HTTP APIs). Esto permite retirar la exposición pública del balanceador que sirve las APIs y mantenerlo como origen privado.

¿Qué ganamos con API Gateway?

1. Una frontera explícita para la API

Las APIs se modelan como rutas y stages, no como simples comportamientos de caché por path. Esto facilita separar versiones, ambientes, dominios y políticas de despliegue.

2. Autorización antes de llegar al clúster

HTTP API puede validar JWT emitidos por un proveedor OIDC y exigir scopes por ruta (JWT authorizers). Los esquemas personalizados —por ejemplo DPoP, JWE o decisiones contextuales— pueden requerir un Lambda authorizer o continuar parcialmente en el backend.

La autorización del gateway es una defensa adicional, no un reemplazo automático de todos los controles de dominio.

3. Throttling y consumo gobernado

API Gateway permite aplicar throttling. Si necesitamos API keys, usage plans, cuotas y límites por consumidor, REST API ofrece esas capacidades. AWS aclara que las cuotas y límites de usage plans son best effort y que una API key no debe utilizarse como mecanismo de autenticación (usage plans y API keys).

4. Observabilidad orientada a APIs

API Gateway puede emitir access logs estructurados por stage hacia CloudWatch Logs, incluyendo requestId, ruta, método, estado y tamaño de respuesta (logging de HTTP APIs). Si propagamos ese identificador al Ingress y a los microservicios, podemos correlacionar el tiempo del gateway con la traza interna.

5. Un origen privado

El VPC Link permite que el balanceador de las APIs deje de ser el punto público principal. La reducción de superficie depende de cerrar realmente el acceso directo al origen; agregar API Gateway sin hacerlo solo crea otro camino hacia el mismo backend.

HTTP API o REST API

“Usar API Gateway” todavía no completa la decisión. AWS ofrece dos opciones RESTful con capacidades y costos distintos (comparación oficial):

Necesidad	HTTP API	REST API
Proxy HTTP hacia ALB/NLB privado	Sí	Sí
JWT authorizer nativo	Sí	No; se puede usar Lambda authorizer
Lambda authorizer	Sí	Sí
API keys y usage plans	No	Sí
Throttling por cliente	No	Sí
Validación de requests	No	Sí
Despliegues canary	No	Sí
Menor conjunto de funciones y menor costo relativo	Sí	No

Para una primera migración de rutas con autorización JWT y controles simples, HTTP API puede ser suficiente. Si el producto necesita planes comerciales, cuotas por aliado, validación en el gateway o canary nativo, REST API encaja mejor.

La elección debe salir de los requisitos de los consumidores, no de una preferencia general por uno de los dos productos.

Lo que API Gateway no resuelve por sí solo

API Gateway tampoco es una solución mágica:

• Agrega un salto de red, costo por solicitud y límites que deben medirse.
• No elimina la necesidad de timeouts, retries controlados, circuit breakers e idempotencia en los servicios.
• No reemplaza la autorización de negocio dentro del backend.
• No convierte una API mal diseñada en un producto estable.
• No debe recibir tráfico interno entre microservicios que ya puede viajar por la red privada del clúster.
• No justifica mover automáticamente un proveedor OIDC detrás del mismo gateway.

Si solo existe un servicio regional, con pocos consumidores y sin necesidad de gestión de APIs, un ALB protegido con AWS WAF puede ser una arquitectura más simple. Si consumidores globales necesitan acelerar respuestas cacheables, CloudFront incluso puede permanecer delante de un API Gateway Regional. AWS presenta estos servicios como alternativas y componentes combinables, no como reemplazos universales (guía de selección para endpoints de microservicios).

Estrategia de migración

No propusimos un cambio big bang. El recorrido seguro es incremental:

1. Inventariar rutas y consumidores. Identificar paths públicos, métodos, payloads, headers, autenticación, cacheabilidad y límites actuales.
2. Medir la línea base. Registrar latencia p50/p95/p99, volumen, errores, costo y tiempos de cada dependencia.
3. Crear API Gateway Regional y VPC Link. Conectarlo a un balanceador interno en la misma cuenta y VPC.
4. Empezar con proxy routes compatibles. Preservar paths y contratos para evitar cambios simultáneos en clientes y backend. En integraciones privadas, revisar el stage que API Gateway agrega al path y eliminarlo mediante parameter mapping cuando sea necesario.
5. Configurar seguridad y observabilidad. TLS, authorizers, throttling, access logs, métricas, WAF según el tipo de API y propagación de correlation IDs.
6. Migrar consumidores de forma gradual. Usar dominio o routing controlado, comparar respuestas y mantener rollback.
7. Cerrar el acceso directo al origen. Solo después de validar el flujo completo debe retirarse la exposición pública anterior.

El aprendizaje

CloudFront puede publicar una API y puede ser parte de una arquitectura de APIs. Lo que no ofrece por sí solo es el modelo de gobierno que suele necesitar una API pública con múltiples consumidores.

La pregunta correcta no es:

“¿CloudFront puede reenviar este POST?”

La pregunta correcta es:

“¿Dónde vamos a aplicar de forma consistente autorización, rutas, cuotas, observabilidad y aislamiento del origen?”

En nuestro caso, la respuesta fue mantener CloudFront donde brillaba —la distribución del frontend— y adoptar API Gateway como frontera explícita para las APIs que llegan a EKS.

Ese cambio no fue agregar un servicio más. Fue devolverle a cada componente una responsabilidad clara.

Etiquetas sugeridas: #AWSCommunityBuilders #AmazonEKS #APIGateway #CloudFront #Kubernetes #Microservices #Architecture