AWS lanza Lambda Web Functions para ejecutar aplicaciones HTTP nativas en serverless

El 12 de octubre de 2026 AWS anunció Lambda Web Functions, una nueva forma de ejecutar aplicaciones web HTTP estándar sobre Lambda sin reescribir el código a un manejador de eventos. Permite desplegar un servidor que escucha en un puerto, construido con Express, Hono, Fastify, Next.js o cualquier framework Node.js, con un solo comando. Lambda se encarga del escalado, la distribución multi-región y la facturación por CPU activa. No hacen falta adaptadores ni gestión de infraestructura, y no hay dependencia de un framework concreto.

Con este lanzamiento Lambda ofrece tres formatos distintos, todos sobre la tecnología de aislamiento Firecracker. Las Event Functions son las clásicas: modelo event-driven, una sola concurrencia por ejecución y facturación por tiempo de reloj. Las Web Functions usan un modelo HTTP nativo, con hasta 128 peticiones concurrentes por entorno de ejecución y facturación por tiempo de CPU activo. Las MicroVMs aportan entornos sandbox aislados y con estado, de ciclo de vida gestionado por el cliente, pensados para código no confiable o generado por usuarios.

La diferencia operativa es relevante. En Web Functions un entorno caliente puede absorber una ráfaga de tráfico sin crear una instancia nueva por cada petición. El tiempo de espera en una consulta a base de datos o en una llamada a una API apenas consume CPU, por lo que las cargas I/O intensivas (renderizado en servidor, backends de API o endpoints de inferencia que hacen streaming de tokens) pueden salir más baratas. La memoria se factura mientras el entorno existe.

El despliegue es deliberadamente simple. El CLI agrupa el código, crea la función, publica una revisión y devuelve una URL HTTPS en menos de un minuto. Se puede redesplegar a varias regiones (por ejemplo us-east-1, eu-west-1 y ap-northeast-1) y Lambda configura el enrutamiento por latencia de forma automática bajo una URL global. Las revisiones son inmutables; se puede hacer canary repartiendo peso de tráfico entre ellas sin herramientas adicionales. También se integra con CloudFront: la Web Function puede ser origen de una distribución, y con Origin Access Control se consigue el mismo patrón de origen privado que ya existe para S3.

Está disponible de lanzamiento en US East (N. Virginia y Ohio), US West (Oregon), Asia Pacific (Tokyo) y Europe (Ireland). Corre Node.js 24 sobre Arm64 y admite conectividad VPC.

Para un responsable TIC de un centro educativo, una red concertada o una organización de tamaño medio que ya usa AWS o valora mover cargas web fuera de servidores tradicionales, el anuncio reduce fricción. Hasta ahora adaptar una aplicación Express o Next.js a Lambda implicaba wrappers, cold starts por petición y facturación que penalizaba la espera en I/O. Ahora el mismo código que corre en local puede desplegarse con un comando y beneficiarse de escalado automático y multi-región sin montar un balanceador, un cluster o un pipeline de despliegue complejo.

En la práctica conviene evaluar casos concretos. Un portal de padres o un backend de matrícula con picos de tráfico, una API interna que consulta bases de datos educativas, o un endpoint que sirve contenidos dinámicos pueden beneficiarse de la concurrencia múltiple y de la facturación por CPU. Hay que comprobar la disponibilidad regional (Ireland está incluida) y el coste real con cargas representativas, porque el modelo de facturación cambia. También hay que revisar si las dependencias nativas o las librerías que se usan son compatibles con el runtime Node.js 24 Arm64.

El mensaje para quien gestiona tecnología es que el serverless deja de exigir que la aplicación se adapte al modelo de función y pasa a aceptar el servidor HTTP que ya se tiene. Eso acorta el tiempo de puesta en producción y puede mejorar el coste de cargas que pasan mucho tiempo esperando datos. Conviene probarlo en un entorno de desarrollo antes de trasladar nada crítico, y documentar el modelo de revisiones y canary si se piensa usar en producción.