AWS ha presentado Lambda Web Functions, una tercera forma de ejecutar código en Lambda pensada para aplicaciones HTTP normales: levantas un servidor que escucha en un puerto, sin reescribirlo como manejador de eventos. Según el anuncio, funciona con Express, Hono, Fastify, Next.js o cualquier framework de Node.js, y no hace falta ningún adaptador.
Qué cambia
Hasta ahora Lambda tenía funciones de evento: una petición por entorno de ejecución y facturación por tiempo de reloj. Las Web Functions cambian ese modelo en varios puntos:
- Multiconcurrencia: hasta 128 peticiones concurrentes por entorno de ejecución.
- Facturación: se mide el tiempo de CPU, así que la espera de E/S consume poca CPU facturable. La memoria se mide mientras exista el entorno.
- Runtime de lanzamiento: Node.js 24 (
nodejs24.x) sobre Arm64. Es el único por ahora. - Contrato: Lambda define
AWS_LAMBDA_HTTP_ENDPOINTcon el host:puerto en el que debe escuchar tu servidor. En local lo defines tú. - Despliegue: un comando de la CLI crea la función, publica una revisión y devuelve una URL HTTPS.
aws lambda-web deploy --name mi-api --code ./dist
# varias regiones, con una única URL global (enrutado por latencia, best-effort)
aws lambda-web deploy --name mi-api --code ./dist --regions us-east-1,eu-west-1,ap-northeast-1Para canarios existe aws lambda-web update-web-function-endpoint con --revision-weights (el ejemplo del anuncio reparte 90/10) y --auto-deployment-mode Disabled. El endpoint puede ser origen de CloudFront con origin access control, de modo que solo acepte peticiones de tu distribución. Hay soporte de VPC.
Disponibilidad inicial: N. Virginia, Ohio, Oregón, Tokio e Irlanda. Con las tres formas de Lambda (eventos, Web Functions y MicroVMs) el aislamiento sigue siendo Firecracker.
Por qué importa en producción
El modelo de una petición por entorno obliga a pagar por el tiempo que tu código espera a una base de datos o a una API externa. Con 128 peticiones por entorno y facturación por CPU, los servicios dominados por E/S pueden salir más baratos y con menos arranques en frío, aunque el anuncio no da cifras de precio: remite a la página de precios de Lambda.
La multiconcurrencia también trae los problemas de cualquier servidor tradicional: estado compartido entre peticiones, pools de conexiones dimensionados para 128 clientes simultáneos, fugas de memoria que ahora afectan a muchas peticiones a la vez y un límite de CPU compartido. Si venías de funciones de evento, cualquier variable global que asumías "mía" deja de serlo.
Tampoco hay que pasar por alto las lagunas: solo Node.js 24 en Arm64, cinco regiones y enrutado multirregión "best-effort". El anuncio no detalla otras cuotas.
Qué haría yo
- Probar con un servicio de bajo riesgo y mucha E/S, no con el camino crítico.
- Revisar el código en busca de estado mutable a nivel de módulo y dimensionar los pools de conexiones para la concurrencia real.
- Poner CloudFront delante con OAC desde el principio, para que el endpoint no quede abierto.
- Usar el reparto de revisiones (90/10) para desplegar y vigilar latencia p99, errores y CPU antes de subir el peso.
- Comparar el coste con el de tu despliegue actual usando tráfico real y la página de precios, no solo el anuncio.