AWS Lambda Web Functions: Express sin adaptadores

¿Qué son las AWS Lambda Web Functions?

128 peticiones concurrentes en un mismo entorno de ejecución y una URL HTTPS lista en menos de un minuto. Esa es la promesa de AWS Lambda Web Functions, el nuevo tipo de función con el que puedes desplegar un servidor HTTP estándar —el mismo que corres en tu computadora con node index.js— sin adaptadores ni wrappers específicos de Lambda.

Para un founder, la traducción es directa: si tu backend está en Express, Hono, Fastify o Next.js, ya no necesitas encapsular cada ruta en un handler de eventos. Tu aplicación sigue escuchando en un puerto y Lambda se encarga del escalado, la distribución multirregión y el aprovisionamiento.

La única diferencia respecto a tu entorno local es la variable AWS_LAMBDA_HTTP_ENDPOINT, que Lambda inyecta con el host y el puerto donde tu servidor debe escuchar. El resto del código no se toca, y eso incluye la promesa de no quedar atado a un framework.

Lambda ahora tiene tres modelos, no uno

Con este anuncio, AWS reorganiza Lambda en tres form factors distintos, todos construidos sobre la misma tecnología de aislamiento Firecracker:

• Event Functions: lo que hasta hoy conocías como Lambda a secas. Modelo basado en eventos, un manejo por invocación y facturación por tiempo de reloj. Sigue siendo la opción correcta para consumir colas, procesar eventos y reaccionar a otros servicios de AWS.
• Web Functions: modelo HTTP nativo con ejecución multiconcurrente —hasta 128 peticiones por entorno— y facturación por CPU activa. Diseñado para aplicaciones web, backends de API y cargas con mucho I/O.
• MicroVMs: entornos aislados y con estado, con ciclo de vida gestionado por el cliente, para ejecutar código no confiable o generado por usuarios.

Los tres conviven en la misma cuenta y comparten el mismo modelo operativo. Un producto típico puede usar Event Functions para el procesamiento asíncrono, Web Functions para la capa de API y el renderizado en servidor, y MicroVMs para las funciones donde el usuario ejecuta código propio.

El cambio que más pesa: cómo te cobran

El detalle con mayor impacto en la factura no es la concurrencia, sino la métrica. Las Web Functions facturan el tiempo de CPU que tu código realmente usa. El tiempo que tu aplicación pasa esperando la respuesta de una base de datos o de una API de terceros consume muy poca CPU. La memoria, en cambio, se factura mientras el entorno de ejecución exista.

Esa diferencia pesa en cargas como renderizado en servidor, backends de API y endpoints de inferencia de IA que transmiten respuestas en streaming: justo el tipo de aplicación donde el servidor pasa más tiempo esperando que calculando. Si tu arquitectura actual te obliga a pagar por tiempo de reloj mientras tu código duerme, ahí está el ahorro real.

De un comando a una URL en producción

El despliegue se resume a una línea: aws lambda-web deploy --name my-web-app --code ./my-app. La CLI empaqueta el código fuente, crea la Web Function, publica su primera revisión, conecta un endpoint y devuelve una URL HTTPS viva en menos de un minuto, sin crear recursos previos a mano.

Dos conceptos ordenan el resto del flujo:

• Una revisión es una fotografía inmutable del código desplegado.
• Un endpoint es la URL HTTPS que enruta el tráfico hacia una revisión o lo reparte entre varias.

Con esas piezas, el control de versiones deja de ser un problema de infraestructura. Puedes desplegar el mismo proyecto en varios países agregando regiones —--regions us-east-1,eu-west-1,ap-northeast-1— y Lambda replica el código, configura el enrutamiento por latencia y expone una URL global que manda cada solicitud a la región más cercana al usuario.

Para producción, el reparto de tráfico entre revisiones se hace con una sola llamada a la API: pesos de 90% para la revisión actual y 10% para la nueva. Es un despliegue canario sin herramientas adicionales.

CloudFront: el patrón de origen privado, sin ceremonia

Si tu producto mezcla contenido estático y dinámico, puedes elegir un endpoint de Web Function como origen de Amazon CloudFront. Los archivos estáticos se sirven desde la caché y las solicitudes dinámicas llegan a tu Web Function: rendimiento de CDN para lo estático y cómputo serverless para lo dinámico.

La mejora fina está en el control de acceso al origen (OAC). Ahora puedes adjuntarlo al endpoint de la Web Function: CloudFront firma las solicitudes y el endpoint solo acepta invocaciones de tu distribución. Es el mismo patrón de origen privado que CloudFront ya ofrecía para Amazon S3, sin exponer el endpoint ni escribir autorización propia en la aplicación.

Disponibilidad y el detalle que puede frenarte

Las Web Functions están disponibles en US East (N. Virginia), US East (Ohio), US West (Oregon), Asia Pacific (Tokyo) y Europe (Ireland). Al lanzamiento corren Node.js 24 (nodejs24.x) sobre Arm64 y admiten conectividad con Amazon VPC.

Ese último punto es el más relevante para equipos que ya tienen bases de datos y servicios internos dentro de una VPC: sin esa conectividad, el lanzamiento sería inútil para un backend corporativo. La contracara es el alcance del runtime: si tu stack está en Python, Java o Go, este modelo todavía no te cubre con lenguajes administrados. AWS ha ido ampliando Lamba por capas —InfoWorld documentó que las durable functions soportan Python 3.13 y 3.14, y Node.js 22 y 24, además de pausas de hasta un año sin cargos durante la espera—, pero conviene verificar la matriz de runtimes antes de planificar una migración.

El contexto: serverless dejó de ser solo eventos

AWS lanzó Lambda hace más de una década y la compañía ha contado que la idea nació escuchando a clientes como WeTransfer, que necesitaban ejecutar tareas disparadas por eventos sin aprovisionar infraestructura, según el repaso que SiliconANGLE publicó junto al CTO de Amazon Werner Vogels. Firecracker, la microVM que hoy sostiene Lambda, también es la base de AWS Fargate.

El debate pendiente no es técnico, es estratégico. InfoWorld advierte que abstracciones propietarias como las durable functions de Lambda aumentan la dependencia del proveedor y que migrar workflows complejos a otra nube es costoso y complejo, porque el código se apoya en APIs específicas de AWS. En el caso de las Web Functions el riesgo es menor, porque el artefacto que despliegas es un servidor HTTP estándar y no una API propietaria: eso abarata la salida si algún día quieres moverte a contenedores.

En el frente competitivo, el benchmark de AIMultiple sobre funciones serverless describe la diferencia de enfoque: Cloudflare Workers ejecuta código en isolates de V8 sin arrancar un sistema operativo, lo que elimina el arranque en frío como cuello de botella, mientras que AWS prioriza el aislamiento a nivel de kernel con microVMs Firecracker que arrancan en milisegundos. Las Web Functions atacan el problema por otro lado: menos costo por espera y más concurrencia por entorno.

¿Qué significa esto para tu startup?

La decisión no es "serverless sí o no", es qué modelo encaja con tu carga.

• Mide antes de migrar. Levanta un endpoint no crítico con aws lambda-web deploy --name mi-api --code ./mi-app y compara latencia p95 y costo contra tu contenedor actual durante una semana. Un experimento de un comando es más barato que una migración a ciegas.
• Audita tu perfil de CPU. Si tu backend espera más de lo que calcula —consultas a base de datos, llamadas a APIs de terceros, streaming de tokens— el cobro por CPU activa juega a tu favor. Si haces transcodificación de video o procesamiento pesado de imágenes, el cálculo cambia y probablemente este no sea el modelo adecuado.
• Adopta el canario desde el primer deploy. Usa revisiones con pesos 90/10 para validar código nuevo con tráfico real antes de mover el 100%, en lugar de confiar en un despliegue total.
• Aprovecha OAC si ya usas CloudFront. Mover el origen a un endpoint de Web Function te da el patrón de origen privado sin exponer la URL ni programar autenticación en la aplicación.
• Protege tu portabilidad. Como el código es un servidor HTTP estándar, mantenerlo dockerizable te deja una salida barata si los precios o los límites cambian. La advertencia de InfoWorld sobre el costo de desenredar abstracciones propietarias aplica para cualquier capa que agregues encima.

Conclusión

AWS Lambda Web Functions no es una función nueva más: es un cambio de programación. Lambda deja de exigirte que pienses en eventos y acepta el servidor HTTP que ya escribiste, con concurrencia real por entorno y una factura que premia las cargas con mucho I/O. Para startups con backends en Node.js y tráfico global, es la vía más corta entre el código local y una URL en producción. El límite a vigilar es el runtime: hoy solo Node.js 24 sobre Arm64, en cinco regiones.

Fuentes

• Announcing AWS Lambda Web Functions (fuente original)
• The 10-year journey of AWS Lambda — SiliconANGLE
• Weighing the benefits of AWS Lambda durable functions — InfoWorld
• Top Serverless Functions: Vercel vs Azure vs AWS — AIMultiple