AWS Lambda Web Functions: ¿tiene sentido mover tu backend HTTP a este nuevo modelo?

AWS ha lanzado Lambda Web Functions, y es fácil caer en el “hype”: ¿lo migramos todo ya o esperamos? Mejor mirarlo con calma desde donde de verdad duele o ayuda: arquitectura, costes y operativa de tu backend HTTP.

¿Qué son realmente las Lambda Web Functions?

En esencia, son funciones Lambda que exponen directamente un endpoint HTTP(S) gestionado por AWS, sin que tengas que:

Crear y configurar API Gateway.
Mantener mappings de rutas, stages, integraciones, etc.
Poner un ALB o un Nginx/Traefik delante solo para hablar HTTP.

AWS mete la capa HTTP “commodity” dentro del propio servicio de Lambda y la hace más directa de consumir. Pero por debajo sigue siendo lo mismo:

Ejecución efímera.
Facturación por uso.
Modelo event‑driven.

La pregunta interesante no es si “es mejor que API Gateway”, sino esta: ¿encaja mejor con tu dominio, tu tráfico y tu equipo que lo que ya tienes en producción?

Comparativa rápida: Lambda Web vs API Gateway vs Fargate

Patrón de routing

API Gateway + Lambda

Routing declarativo definido como infraestructura (OpenAPI, CloudFormation, CDK).
Buen soporte para APIs complejas: versionado por stage, APIs privadas, websockets, etc.
Mucha flexibilidad… y muchas piezas que entender y mantener.

Lambda Web Functions

Endpoint HTTP directo a Lambda.
Menos capas entre la petición y tu código: útil para APIs simples, microservicios acotados o backends de una funcionalidad muy concreta.
Menos superficie de configuración y menos “features” clásicas de API management.

Fargate (ECS) + ALB / NLB

Routing de toda la vida: proceso residente detrás de un balanceador.
Pensado para servicios de larga duración: workers HTTP, websockets duraderos, streaming…
Encaja mejor con frameworks que esperan un proceso fijo (Spring Boot, Django, Rails, etc.).

Latencia y modelo de ejecución

Lambda Web Functions

Se comportan como Lambda estándar: muy buena latencia en caliente y cold starts a vigilar.
Al quitar API Gateway en escenarios simples, reduces hops y algo de latencia total.
Encaja bien cuando tus peticiones son:
- Relativamente cortas (orden de 100 ms – 2 s).
- Independientes entre sí (sin afinidad de sesión de servidor).
- Sin necesidad de conexiones de larga duración.

API Gateway + Lambda

Añade una capa extra en la ruta de datos.
Ganas en features de gestión de API, pero con algo más de latencia y complejidad mental.

Fargate

Servicio residente, sin problema de cold starts.
Para tráfico muy constante o picos predecibles, la latencia suele ser más plana.
Websockets o streaming prolongado siguen siendo escenarios más naturales aquí.

Costes: dónde suele cambiar la película

No hay fórmula mágica, pero sí patrones que se repiten:

Tráfico bajo o irregular → Lambda (incluyendo Web Functions) suele salir mejor porque pagas sobre todo por uso real.
Tráfico alto y estable → Fargate/EC2 empieza a ser competitivo o más barato a partir de cierto volumen y consumo de CPU/memoria.

Cosas a mirar con lupa:

Duración media de las peticiones: en Lambda pagas por tiempo de ejecución; en Fargate pagas por capacidad provisionada, la uses o no.
Picos impredecibles: Lambda absorbe mejor subidas bruscas sin que tengas que tocar la capacidad.
Infra compartida: si ya tienes un ECS muy poblado y amortizado, añadir otro servicio HTTP puede costar poco.

Resumen práctico: Lambda Web Functions suele tener más sentido económico cuando la carga es bursty o moderada, y no quieres mantener infraestructura permanente sobredimensionada.

Observabilidad y depuración

En herramientas no hay gran novedad, pero el modelo cambia cómo las usas:

En Lambda (Web o no) tiras de CloudWatch Logs, X‑Ray o tu stack habitual vía SDK.
El riesgo está en el patrón: demasiadas funciones pequeñas y muy orquestadas generan grafos de trazas difíciles de leer.
En Fargate, el proceso residente facilita:
- Métricas continuas de proceso (CPU, memoria, colas internas).
- Profiling continuo.
- Uso de APM clásico (New Relic, Datadog, etc.) sobre procesos de larga vida.

¿Cuándo sí tiene sentido migrar a Lambda Web Functions?

1. APIs pequeñas o de alcance claro

Encaja muy bien en:

Backends de features aisladas (servicio de notificaciones, manejadores de webhooks, generación puntual de informes…).
APIs internas de complejidad baja/media sin necesidad de un gateway avanzado.
MVPs o pruebas de concepto donde quieres pasar de 0 a endpoint HTTPS rápido y sin demasiada infraestructura.

2. Proyectos serverless ya basados en Lambda

Si tu stack ya gira en torno a Lambda y usas API Gateway como pegamento mínimo, Lambda Web Functions puede:

Simplificar la infraestructura (menos recursos que versionar y monitorizar).
Reducir latencia y puntos intermedios.
Hacer tu IaC más legible (menos plantillas de API complicadas).

3. Workloads con tráfico impredecible

Algunos patrones típicos:

SaaS B2B donde clientes lanzan operaciones muy pesadas de forma esporádica.
Productos self‑service con uso concentrado en horarios raros (noches, fines de semana).
Integraciones de terceros por webhooks con picos breves pero intensos.

La elasticidad de Lambda es la que salva la situación; el modelo Web Function solo hace el acceso HTTP más directo.

¿Cuándo no merece la pena (o no tanto)?

1. Servicios con alto throughput sostenido

Ejemplos obvios:

APIs públicas de muchísimo tráfico con latencia muy ajustada.
Servicios internos de baja latencia y alto RPS que ya tienes tuning en contenedores.

En estos casos, Fargate o incluso EC2 pura pueden dar:

Más control sobre rendimiento fino.
Posiblemente mejor coste a mucha escala.

2. Necesidades serias de API management

Si dependes fuerte de cosas como:

Versionado avanzado, planes de uso, suscripciones, throttling por cliente.
Autenticación/autorización delegada al gateway (OAuth2, API keys, etc.).
Políticas detalladas por ruta, método, tenant…

Seguirás necesitando API Gateway u otro API manager delante, aunque detrás corras Lambda Web Functions.

3. Workloads “stateful” o de conexión larga

Mal encaje para Lambda en general:

Websockets y streaming persistente.
Long‑polling intensivo.
Protocolos que exigen mantener la conexión abierta mucho tiempo.

Aquí contenedores o servicios diseñados para conexiones long‑lived tienen más sentido.

Cómo diseñar endpoints para Lambda Web Functions

Diseño de recursos y tamaño de las funciones

Algunas ideas prácticas:

Agrupa rutas que compartan dominio y dependencias en la misma función cuando eso simplifique:
- Deploys (no tener que versionar 20 funciones que siempre cambian juntas).
- Reutilización de conexiones a base de datos, cachés, clientes HTTP, etc.
Evita tanto el “mega‑monolito” (toda la API en una sola función) como la explosión de micro‑funciones (una ruta = una función) sin motivo sólido.

Piensa en bounded contexts o módulos de dominio y úsalo como unidad de Lambda.

Mitigar cold starts

Para que no se noten tanto en producción:

Usa runtimes ligeros (Node.js, Python…) cuando tenga sentido.
Carga de forma lazy dependencias pesadas que no se necesitan en todos los paths.
Inicializa conexiones externas (BBDD, Redis, etc.) fuera del handler y reutilízalas entre invocaciones.
Valora provisioned concurrency para endpoints hipersensibles a latencia.

Contratos y versionado de API

Que la capa HTTP sea más simple no significa que el contrato de tu API pueda ser difuso. Mantén:

Esquemas de entrada/salida claros (OpenAPI, JSON Schema).
Políticas de deprecación explícitas.
Validaciones en el borde (inputs, autenticación, autorización) bien definidas.

Anti‑patrones serverless a evitar

1. Mezclar dominio con detalles de AWS por todas partes

Si tu lógica habla directamente en términos de eventos de Lambda y tipos de AWS, el acoplamiento es fuerte y luego duele migrar.

Evita algo de este estilo:

export const handler = async (event: any) => {
  // Lógica de negocio directamente sobre el event de AWS
};

Es mejor separar el dominio del adaptador:

// Capa de dominio
function procesarPedido(pedido: Pedido): Resultado {
  // ...lógica de negocio...
}

// Adaptador HTTP (Lambda Web Function)
export const handler = async (event: AwsHttpEvent) => {
  const pedido = mapEventToPedido(event);
  const resultado = procesarPedido(pedido);
  return mapResultadoToHttpResponse(resultado);
};

La idea es clara: que cambie el borde (Lambda Web, API Gateway, Fargate), pero el núcleo de dominio se mantenga estable.

2. Explosión de funciones ultra‑granulares

Pasar de un monolito mal diseñado a 80 Lambdas igual de mal diseñadas no es un avance.

Síntomas típicos:

Mismas dependencias pesadas clonadas en decenas de funciones.
Cambios pequeños que obligan a tocar y desplegar muchas funciones.
Trazas imposibles de seguir porque una petición rebota por demasiadas piezas.

Agrupa por dominio y cohesión, no por “evento trivial”.

3. Usar Lambda como si fuera un proceso residente

Forzar patrones que chocan con la ejecución efímera suele acabar mal:

Jobs muy largos rozando el límite máximo de ejecución.
Dependencia fuerte de estado en memoria entre peticiones.
Pools complicados de conexiones que esperas que vivan “para siempre”.

Si para sostener un servicio te ves montando medio scheduler encima de Lambda, es señal de que quizá un worker en Fargate encaja mejor.

Criterios concretos para decidir

Puedes evaluar en estos ejes:

Patrón de tráfico
- Bajo/irregular → +1 a Lambda Web.
- Alto/estable → +1 a Fargate.
Complejidad de API management
- Requisitos simples (auth básica, sin planes de uso complicados) → +1 a Lambda Web.
- Requisitos avanzados (rate limiting por cliente, monetización, gateways híbridos) → +1 a API Gateway + backend que ya uses.
Naturaleza del servicio
- Peticiones discretas y cortas, sin conexión larga → +1 a Lambda Web.
- Conexiones largas, streaming, protocolos especiales → +1 a contenedores/servicios residentes.
Equipo y cultura
- Comodidad con IaC, eventos, funciones pequeñas, despliegues frecuentes → encaja bien con Lambda.
- Preferencia por procesos largos, frameworks clásicos y APM tradicional → Fargate suele dar menos fricción.

Conclusión: ¿muevo mi backend HTTP a Lambda Web Functions?

Lambda Web Functions no cambia las reglas del juego, pero sí pule bastante la experiencia de montar backends HTTP serverless en AWS. Tiene sentido plantearlo si:

Tu backend actual sobre API Gateway + Lambda es sencillo y quieres quitar capas.
Estás arrancando servicios nuevos con lógica discreta y carga impredecible.
Buscas reducir fricción operativa más que exprimir cada milisegundo o cada dólar a millones de peticiones.

Si por el contrario tienes:

Cargas estables y voluminosas.
Dependencia fuerte de features de API management.
Servicios con conexiones largas o requisitos de red muy específicos.

Lo más probable es que Fargate, API Gateway o una mezcla sigan siendo mejores opciones.

Al final, se trata de elegir con intención: qué modelo encaja mejor con tu dominio, tu tráfico y tu equipo hoy, sin dejarte sin opciones mañana.