Hace dos semanas escribí sobre cómo Netlify había cambiado los isolates de V8 por microVMs Firecracker en sus Edge Functions, y terminaba diciendo que las microVMs se estaban convirtiendo en la opción por defecto para ejecutar código de terceros, con Lambda como ejemplo. Hoy AWS ha publicado Announcing AWS Lambda Web Functions, y es un cambio en el modelo de programación más que en la infraestructura: Lambda ya puede ejecutar un servidor HTTP normal, de los que escuchan en un puerto, sin reescribirlo como un handler de eventos.
Puede parecer poca cosa, pero quien haya metido una aplicación Express o Next.js en Lambda sabe que nunca ha sido tan directo como debería.
El problema de siempre
Una función Lambda clásica recibe un evento, lo procesa y devuelve una respuesta. Con una API HTTP, eso significa que API Gateway (o una Function URL) traduce cada petición a un objeto JSON, se lo pasa a tu función, y tu función tiene que devolver otro JSON con el código de estado, las cabeceras y el cuerpo.
Si ya tenías una aplicación web escrita con un framework, tocaba ponerle un adaptador en medio: serverless-http, Lambda Web Adapter o el que trajera tu framework. Funcionaba, pero la aplicación ya no era la misma que ejecutabas en local, y cada framework tenía sus particularidades.
Y había un segundo problema, el del coste: cada entorno de ejecución atendía una petición a la vez y se cobraba el tiempo total, incluido el que la función pasaba esperando a la base de datos o a otra API. Para una aplicación web, que se pasa la mayor parte del tiempo esperando I/O, eso es pagar por no hacer nada.
Tres formas de usar Lambda
Con este anuncio, AWS reorganiza Lambda en tres formatos, todos sobre el mismo aislamiento de Firecracker:
| Formato | Modelo | Facturación | Pensado para |
|---|---|---|---|
| Event Functions | Un evento por entorno | Tiempo total | Colas, eventos de otros servicios, procesos asíncronos |
| Web Functions | Servidor HTTP con peticiones concurrentes | CPU activa + memoria | Aplicaciones web, APIs, SSR |
| MicroVMs | Entorno con estado y ciclo de vida propio | — | Ejecutar código no confiable o generado por usuarios |
Las Event Functions son las Lambda de toda la vida, que estrenan nombre para distinguirlas. Las MicroVMs merecerían un artículo propio: son justo lo que buscan los sandboxes para agentes de IA, la misma idea de Vercel Sandbox.
Cómo funcionan las Web Functions
Lo más importante es que el código es el de siempre. El ejemplo del anuncio es un servidor Express sin nada específico de Lambda:
import express from 'express';
const app = express();
const [host, port] = process.env.AWS_LAMBDA_HTTP_ENDPOINT.split(':');
app.get('/', (req, res) => {
res.json({ message: 'Hello from Lambda Web Functions!' });
});
app.listen(port, host, () => {
console.log(`Server running on port ${port}`);
});
La única diferencia es la variable AWS_LAMBDA_HTTP_ENDPOINT, que Lambda rellena con la dirección y el puerto donde tiene que escuchar el servidor. En local basta con definirla a mano: AWS_LAMBDA_HTTP_ENDPOINT=127.0.0.1:3000 node index.js.
El despliegue es un único comando, sin crear nada antes:
aws lambda-web deploy --name my-web-app --code ./my-app
La CLI empaqueta el código, crea la función, publica una primera revisión (una instantánea inmutable del código) y le asocia un endpoint con una URL HTTPS. Según el artículo, todo en menos de un minuto.
Lo que más me ha gustado:
- Hasta 128 peticiones concurrentes por entorno. Un pico de tráfico se reparte entre entornos que ya están calientes, en lugar de arrancar uno nuevo por petición. Menos arranques en frío y un uso mucho más razonable de la memoria.
- Se cobra la CPU que se usa de verdad. El tiempo esperando una consulta o una llamada a otra API apenas consume CPU, así que apenas cuesta. La memoria sí se cobra mientras exista el entorno. Para SSR, APIs o endpoints que van enviando los tokens de un modelo de IA en streaming, la diferencia puede ser grande.
- Multirregión con un parámetro. Con
--regions us-east-1,eu-west-1,ap-northeast-1replica el código en las tres regiones y configura el enrutamiento por latencia, con una única URL global. - Despliegues canary sin herramientas extra. El endpoint puede repartir el tráfico entre revisiones, por ejemplo un 90% a la actual y un 10% a la nueva, con una sola llamada a la API.
- Integración con CloudFront. Se puede usar un endpoint como origen de CloudFront y protegerlo con origin access control, igual que se hace con un bucket de S3, para que sólo tu distribución pueda llamarlo. Lo estático sale de la caché y lo dinámico va a la función.
Las limitaciones
Por ahora sólo hay Node.js 24 sobre Arm64, en cinco regiones: Virginia, Ohio, Oregón, Tokio e Irlanda. Se puede conectar a una VPC, así que la función llega a bases de datos privadas. El anuncio no da precios: remite a la página de precios de Lambda.
Que sólo haya Node.js al principio tiene sentido, porque es donde están Next.js, Hono, Fastify y compañía, pero el modelo de “escucha en un puerto” no tiene nada de específico de JavaScript. Supongo que Python, Go o PHP llegarán pronto.
Lo que me llevo
Leyendo el anuncio, la comparación que me viene a la cabeza es Cloud Run, que lleva años con este modelo: un contenedor que escucha en un puerto, varias peticiones por instancia y se cobra sólo mientras atiende. AWS llega tarde a esta idea, pero llega con sus ventajas: el arranque de Firecracker, el despliegue en varias regiones con un parámetro y la integración con CloudFront.
Y me parece una buena noticia que Lambda se adapte al código y no al revés. Durante años, “serverless” ha significado en la práctica “reescribe tu aplicación para que encaje en nuestro modelo”. Con las Web Functions, la aplicación que ejecutas en local con node index.js es la misma que despliegas, y eso hace mucho más fácil probar Lambda y, si no convence, llevarse la aplicación a otro sitio.
Fuente: Announcing AWS Lambda Web Functions, AWS News Blog.
