AWS Lambda Web Functions permite a los desarrolladores desplegar aplicaciones HTTP estándar de Node.js sin reescribirlas como controladores de eventos (event handlers). Su modelo de solicitudes concurrentes, la facturación por CPU activa y el escalado gestionado ofrecen nuevas opciones de alojamiento, pero las limitaciones de red, seguridad y operación determinan en qué casos encaja.
Un desarrollador crea una API con Express o Fastify. La aplicación inicia un servidor HTTP, escucha en un puerto y atiende las solicitudes entrantes. Ejecutar esa aplicación en AWS Lambda tradicional suele exigir adaptarla a una interfaz de controlador de eventos.
El 12 de octubre de 2026, AWS presentó Lambda Web Functions, que permite a los desarrolladores desplegar un servidor HTTP convencional de Node.js directamente en Lambda. En el lanzamiento, AWS ofreció el servicio en cinco regiones: US East (N. Virginia), US East (Ohio), US West (Oregon), Asia Pacific (Tokyo) y Europe (Ireland). AWS puede añadir regiones, así que consulta su lista actual antes de planificar en torno al servicio.
Web Functions también introduce un modelo de ejecución diferente. Varias solicitudes HTTP pueden compartir un entorno de ejecución, y la facturación distingue el consumo de CPU activa de la memoria asignada durante la vida útil del entorno. Estas capacidades convierten a Lambda en una opción para más aplicaciones web, pero no eliminan la necesidad de elegir la arquitectura de alojamiento adecuada.
¿Qué cambia respecto a Lambda tradicional?
AWS llama ahora Event Functions a su modelo de controladores de Lambda existente. Ese cambio de nombre no exige reescribir las funciones existentes.
Una Event Function recibe un evento, ejecuta su controlador (handler) y devuelve un resultado. Un entorno de ejecución estándar de una Event Function procesa una invocación cada vez. Una Web Function, en cambio, ejecuta un servidor HTTP normal de Node.js. Lambda enruta el tráfico HTTP hacia el servidor, que puede atender solicitudes concurrentes.
| Característica | Event Functions | Web Functions |
|---|---|---|
| Modelo de programación | Controlador de eventos | Servidor HTTP de Node.js que escucha en un puerto |
| Cargas de trabajo típicas | Eventos, colas, tareas programadas y controladores de API | API HTTP, aplicaciones web, renderizado en el servidor y streaming |
| Concurrencia por entorno | Una invocación cada vez | Varias solicitudes HTTP |
| Base de facturación del cómputo | Duración de la invocación | Consumo de CPU activa |
| Base de facturación de la memoria | Duración de la invocación | Vida útil del entorno de ejecución |
| Escalado | Escalado gestionado de invocaciones | Escalado HTTP gestionado, incluido el escalado a cero |
Ambos modelos siguen teniendo propósitos distintos. Una aplicación podría usar Web Functions para una API y mantener Event Functions para el procesamiento de colas o las tareas programadas. Las reglas de tiempo de espera (timeout) de las Event Functions son otro tema, tratado en nuestro artículo sobre el tiempo de espera de 90 minutos de Lambda (en inglés).
Fuente: AWS, Announcing AWS Lambda Web Functions, 12 de octubre de 2026.
Cómo cambian la ejecución las solicitudes concurrentes
El cambio principal es que un único entorno de ejecución puede trabajar en muchas solicitudes a la vez, como hace un servidor web normal. En el lanzamiento, Web Functions admite Node.js 24 sobre Arm64, y cada entorno de ejecución dispone de 2 vCPU y 2 GB de memoria. A diferencia de un entorno tradicional de Event Function, un entorno de Web Function puede atender varias solicitudes simultáneamente.
AWS ajusta dinámicamente cuántas solicitudes atiende un entorno según el uso de recursos observado. La opción maxConcurrencyPerEnvironment define un límite superior de entre 1 y 128, y su valor predeterminado es 64. Ese valor no es una concurrencia garantizada. Lambda puede elegir un límite efectivo más bajo cuando el uso de CPU o de memoria hace que no convenga aceptar más solicitudes.
Esto puede beneficiar a las aplicaciones dominadas por la E/S asíncrona. Por ejemplo, una API de Node.js podría pasar gran parte del tiempo de cada solicitud esperando consultas a bases de datos o servicios externos. Mientras una solicitud espera, el bucle de eventos (event loop) puede procesar otras solicitudes.
El trabajo síncrono intensivo en CPU se comporta de otra manera. Si una solicitud bloquea el bucle de eventos, las demás solicitudes que comparten ese proceso también pueden retrasarse.
Compartir un proceso entre solicitudes también crea un problema de estado. La información propia de cada solicitud no debe guardarse en variables globales mutables compartidas. Las cachés, los contadores y otros objetos compartidos requieren un manejo adecuado cuando las operaciones asíncronas se intercalan.
Una aplicación escrita para un servidor Node.js convencional quizá ya tenga en cuenta estas condiciones. Aun así, los desarrolladores deberían verificar su comportamiento real en el entorno gestionado de Lambda.
Fuentes: AWS, Execution environment lifecycle, Scaling behavior y Runtime support.
¿Qué significa la facturación por CPU activa?
La facturación por CPU activa significa que pagas por el tiempo de CPU que tu código usa realmente, no por el tiempo que una solicitud pasa esperando a otros sistemas. Los clientes pagan por las solicitudes, el consumo de CPU activa, el uso de memoria durante la vida útil del entorno de ejecución y la transferencia de datos que corresponda. Esto difiere del modelo de duración de Lambda tradicional, que incluye el tiempo que una invocación pasa esperando operaciones posteriores (downstream).
Piensa en una solicitud de API que realiza un cálculo breve y luego espera la respuesta de una base de datos. Con Web Functions, el periodo de espera puede consumir poca CPU activa. Sin embargo, los cargos de memoria continúan mientras exista el entorno de ejecución, incluido el tiempo inactivo entre solicitudes. Un endpoint (punto de conexión) puede escalar a cero cuando se detiene el tráfico, pero un entorno no desaparece necesariamente justo después de cada solicitud.
Esta distinción hace que Web Functions pueda resultar atractivo para algunas aplicaciones con mucha E/S. No demuestra que el servicio sea más barato para todas las aplicaciones. Una comparación de costos debe considerar los patrones de tráfico, la duración media de las solicitudes, el uso de CPU, el consumo de memoria, la transferencia de datos y el comportamiento de la plataforma de alojamiento actual. Las aplicaciones con cargas de trabajo sostenidas e intensivas en CPU pueden tener una economía distinta de la de las aplicaciones dominadas por esperas de red.
Fuente: AWS, Lambda Web Functions overview.
Cómo funcionan el despliegue y el escalado
Una Web Function contiene revisiones y endpoints. Una revisión es una instantánea inmutable del código y la configuración de la aplicación. Un endpoint proporciona el punto de entrada HTTP y enruta las solicitudes a una o dos revisiones según su configuración de tráfico.
Esta separación permite despliegues controlados. Los equipos pueden crear una nueva revisión, probarla y dirigir una parte del tráfico hacia ella.
Cliente llama al endpoint
Todo endpoint de Web Function tiene un nombre de dominio accesible públicamente.
Con IamAuth, Lambda exige solicitudes firmadas y debidamente autorizadas.
Con ApplicationManaged, Lambda deja pasar las solicitudes sin autenticar a quien llama.
Endpoint elige revisión
Un endpoint proporciona el punto de entrada HTTP y enruta las solicitudes a una o dos revisiones según su configuración de tráfico.
Los equipos pueden crear una nueva revisión, probarla y dirigir una parte del tráfico hacia ella.
Un entorno, muchas solicitudes
A diferencia de un entorno tradicional de Event Function, un entorno de Web Function puede atender varias solicitudes simultáneamente.
La opción maxConcurrencyPerEnvironment define un límite superior de entre 1 y 128, y su valor predeterminado es 64.
Lambda puede elegir un límite efectivo más bajo cuando el uso de CPU o de memoria hace que no convenga aceptar más solicitudes.
Respuesta y timeout
Lambda reenvía el cuerpo completo de la solicitud entrante antes de entregar la respuesta de la aplicación.
Las solicitudes a Web Functions tienen un tiempo de espera predeterminado de 30 segundos y un máximo configurable de 900 segundos, es decir, 15 minutos.
Si vence después de que se hayan enviado los encabezados de respuesta, el cliente puede recibir una respuesta truncada en lugar de un error limpio de la aplicación.
AWS ofrece tres controles principales de escalado.
| Opción | Finalidad |
|---|---|
maxConcurrencyPerEnvironment | Límite superior de solicitudes concurrentes dentro de un entorno |
maxEnvironments | Número máximo opcional de entornos por endpoint en cada región |
rateLimit | Límite opcional de llegada de solicitudes por endpoint en cada región |
El servicio también aplica límites a nivel de cuenta, como la capacidad regional de vCPU y las cuotas de tasa de solicitudes. Aumentar una opción de un endpoint no anula esas cuotas de la cuenta.
Cuando un endpoint supera un límite de tasa de solicitudes o se queda sin capacidad de servicio disponible, Lambda puede devolver respuestas HTTP 429. Hay otros casos que considerar. Establecer rateLimit en cero desactiva el tráfico y produce un HTTP 503 con un indicador de error específico de la plataforma. AWS también puede devolver HTTP 503 mientras descarta carga para proteger el servicio.
Los clientes deberían reintentar solo cuando corresponda, esperando más tiempo tras cada fallo y añadiendo un retraso aleatorio (backoff y jitter). Las operaciones de escritura pueden requerir claves de idempotencia o deduplicación para que los reintentos no repitan efectos de negocio.
Una revisión desplegada no es necesariamente una aplicación que funciona
AWS distingue los estados de los recursos de revisión y de endpoint de la disponibilidad real de la aplicación. Una revisión puede quedar activa aunque su servidor HTTP no arranque correctamente.
Después del despliegue, los equipos deberían enviar una solicitud HTTP real, revisar los registros (logs) de la aplicación y confirmar que el endpoint sirve la respuesta prevista. Para los despliegues en producción, un despliegue ponderado de revisiones y una ruta de reversión (rollback) verificada son más fiables que suponer que la creación de recursos equivale a un despliegue correcto de la aplicación.
Fuentes: AWS, Scaling behavior y Core concepts.
El streaming funciona, con limitaciones de protocolo
Web Functions admite el streaming de respuestas HTTP. Esto puede ayudar a las aplicaciones a entregar contenido renderizado en el servidor, resultados incrementales de API o salidas generadas por IA a medida que están disponibles.
Sin embargo, la ruta de solicitud y respuesta tiene una limitación importante. AWS documenta un comportamiento semidúplex (half-duplex) de HTTP/1.1. Lambda reenvía el cuerpo completo de la solicitud entrante antes de entregar la respuesta de la aplicación.
Por lo tanto, las aplicaciones deberían terminar de leer el cuerpo de una solicitud antes de escribir su respuesta. Esto importa en los diseños que esperan un streaming bidireccional mientras un cliente todavía está subiendo datos.
No se admiten las actualizaciones (upgrades) a WebSocket. Los eventos enviados por el servidor (server-sent events) pueden servir para el streaming unidireccional del servidor al cliente, pero las aplicaciones que requieren una comunicación WebSocket bidireccional y persistente necesitan otra arquitectura compatible.
Las solicitudes a Web Functions tienen un tiempo de espera predeterminado de 30 segundos y un máximo configurable de 900 segundos, es decir, 15 minutos. El tiempo de espera debe cubrir la recepción del cuerpo de la solicitud y la entrega de la respuesta. Si vence después de que se hayan enviado los encabezados de respuesta, el cliente puede recibir una respuesta truncada en lugar de un error limpio de la aplicación.
Fuente: AWS, Configuring networking for Web Functions.
El despliegue multirregión y la conectividad con VPC no son intercambiables
AWS admite endpoints multirregión que replican las revisiones de la aplicación en las regiones compatibles seleccionadas y enrutan las solicitudes según la latencia de red. Esto puede ayudar a las aplicaciones a atender a usuarios distribuidos geográficamente.
Sin embargo, desplegar la aplicación en varias regiones no replica automáticamente sus bases de datos, sesiones, secretos ni dependencias posteriores. Los equipos deben asegurarse de que cada región participante pueda acceder a los recursos necesarios para atender las solicitudes.
Un despliegue multirregión también puede fallar a medias. La actualización de un endpoint puede completarse en una región y fallar en otra. AWS recomienda comprobar el estado de la actualización en cada región en lugar de tratar el estado general del endpoint como prueba de que todas las regiones han recibido la misma revisión.
Una limitación importante para los recursos privados
Web Functions también admite conectividad saliente hacia recursos dentro de una Amazon VPC mediante un conector de red de salida (egress). Los endpoints son de tres tipos. Un endpoint HomeRegion atiende tráfico solo desde la región principal (home Region), mientras que los endpoints MultiRegion y PerRegion atienden tráfico desde varias regiones.
A fecha de 6 de noviembre de 2026, esos conectores solo se admiten con endpoints HomeRegion.
AWS no admite asociar un conector de salida de VPC a revisiones servidas mediante endpoints MultiRegion o PerRegion. Por lo tanto, una aplicación que requiere acceso directo a una base de datos privada a través de un conector de este tipo no puede dar por hecho que también podrá usar la distribución multirregión integrada de los endpoints de Web Functions. Esta restricción debe resolverse durante la selección de la arquitectura, no después del despliegue.
La conectividad de salida con la VPC tampoco hace privado el endpoint HTTPS entrante de la Web Function. El acceso entrante y la conectividad de red saliente son cuestiones independientes.
Entrada pública
Todo endpoint de Web Function tiene un nombre de dominio accesible públicamente.
La autenticación de IAM no convierte el endpoint en un recurso de red privado.
Salida privada posible
Web Functions también admite conectividad saliente hacia recursos dentro de una Amazon VPC mediante un conector de red de salida (egress).
La conectividad de salida con la VPC tampoco hace privado el endpoint HTTPS entrante de la Web Function.
El acceso entrante y la conectividad de red saliente son cuestiones independientes.
Solo HomeRegion
AWS no admite asociar un conector de salida de VPC a revisiones servidas mediante endpoints MultiRegion o PerRegion.
Por lo tanto, una aplicación que requiere acceso directo a una base de datos privada a través de un conector de este tipo no puede dar por hecho que también podrá usar la distribución multirregión integrada de los endpoints de Web Functions.
Decide antes
Esta restricción debe resolverse durante la selección de la arquitectura, no después del despliegue.
Sin embargo, desplegar la aplicación en varias regiones no replica automáticamente sus bases de datos, sesiones, secretos ni dependencias posteriores.
Fuentes: AWS, Configuring networking for Web Functions, Core concepts y Best practices for Lambda Web Functions.
La seguridad empieza en el endpoint público
Todo endpoint de Web Function tiene un nombre de dominio accesible públicamente. AWS ofrece dos enfoques de autenticación.
Con IamAuth, Lambda exige solicitudes firmadas y debidamente autorizadas. Con ApplicationManaged, Lambda deja pasar las solicitudes sin autenticar a quien llama. La aplicación o un servicio previo (upstream) debe implementar la autenticación y la autorización necesarias.
La autenticación de IAM no convierte el endpoint en un recurso de red privado. En las aplicaciones públicas, los desarrolladores también deben ocuparse de la validación de entradas, el abuso de la tasa de solicitudes, la autorización de solicitudes y la protección de la información sensible.
Los endpoints de Web Functions no admiten nombres de dominio personalizados ni la asociación directa con AWS WAF. Amazon CloudFront puede situarse delante de una Web Function para proporcionar un dominio personalizado, caché y protección de AWS WAF.
Para un endpoint IamAuth, AWS recomienda el control de acceso al origen (origin access control, OAC) de CloudFront, para que CloudFront firme sus solicitudes al origen. Con otras capas de entrada (front doors), el endpoint sigue siendo accesible directamente, por lo que la aplicación debería verificar un secreto compartido o un token. Sin restricciones de origen adecuadas, las solicitudes directas pueden saltarse la capa de entrada prevista.
Las aplicaciones de navegador también requieren una configuración adecuada del intercambio de recursos de origen cruzado (Cross-Origin Resource Sharing, CORS). Lambda no añade encabezados CORS para Web Functions, así que la aplicación o su capa de entrada deben gestionarlos. CORS no es un mecanismo de autenticación.
Fuentes: AWS, Best practices for Lambda Web Functions y Configuring networking for Web Functions.
¿Cuándo deberían los desarrolladores considerar Web Functions?
La elección debería basarse en el comportamiento real de la carga de trabajo.
| Carga de trabajo | Enfoque que conviene evaluar |
|---|---|
| API de Node.js con llamadas asíncronas a bases de datos o a la red | Web Functions |
| Renderizado en el servidor con Node.js | Web Functions |
| Streaming de respuestas HTTP o eventos enviados por el servidor | Web Functions, dentro de los límites de tiempo de espera y de protocolo |
| Procesamiento de colas y trabajo programado en segundo plano | Event Functions |
| Comunicación WebSocket persistente | Otra arquitectura de alojamiento compatible con WebSocket |
| Servicio web que necesita acceso privado directo a una VPC y distribución multirregión integrada | Otro diseño u otro enfoque de alojamiento |
| Aplicaciones que requieren runtimes no admitidos o recursos de runtime personalizados | Alojamiento en contenedores u otro servicio de cómputo adecuado |
En el lanzamiento, Web Functions solo admite Node.js. Las aplicaciones que usan otro runtime, que requieren recursos de cómputo diferentes o que dependen de un comportamiento de red no admitido no deberían forzarse a usar el servicio solo porque el servicio es sin servidor. Las aplicaciones existentes en ECS o Fargate quizá ya cubran sus necesidades de forma eficaz. La migración debería basarse en beneficios operativos o económicos demostrados.
Una prueba de preparación para producción bien acotada
Antes de adoptar Web Functions, selecciona un servicio HTTP representativo que no esté en producción. Confirma que el servidor arranca correctamente y escucha en el endpoint requerido. Prueba las solicitudes concurrentes, el estado compartido, las conexiones a bases de datos y el bloqueo del bucle de eventos. Mide el comportamiento real de la facturación de CPU y memoria con un tráfico realista.
Verifica la limitación de solicitudes (throttling), los arranques en frío (cold starts), la gestión de los tiempos de espera, las respuestas en streaming y los reintentos seguros de los clientes. Después, valida la autenticación del endpoint, la protección del origen con CloudFront, los requisitos de VPC y el comportamiento del despliegue regional. Por último, despliega una segunda revisión y demuestra que el tráfico puede volver a la versión anterior que funcionaba.
Estas comprobaciones ayudan a distinguir una demostración exitosa de una aplicación que se puede operar de forma fiable.
Lo que Web Functions cambia realmente
AWS Lambda Web Functions lleva a Lambda las aplicaciones web habituales de Node.js sin exigir el modelo de controladores tradicional. El procesamiento HTTP concurrente, el escalado gestionado y la facturación por CPU activa lo convierten en una nueva opción de alojamiento relevante.
Los límites importan tanto como las funcionalidades. Las aplicaciones deben ser seguras ante solicitudes concurrentes. La facturación de memoria continúa mientras existan entornos.
Las actualizaciones a WebSocket no están disponibles. Actualmente, los conectores de salida de VPC no se pueden combinar con los tipos de endpoint multirregión integrados.
La decisión práctica no es si Lambda puede ejecutar un servidor web normal.
Es si el modelo de ejecución, de red y de operación de Web Functions encaja con la aplicación mejor que sus alternativas de alojamiento actuales.
Referencias y lecturas adicionales
- AWS, Announcing AWS Lambda Web Functions. 12 de octubre de 2026. Regiones de lanzamiento, runtime y los tres formatos (form factors) de Lambda.
- AWS, Lambda Web Functions overview. Modelo de programación, facturación y cargas de trabajo admitidas.
- AWS, Core concepts. Revisiones, endpoints y procesamiento de solicitudes.
- AWS, Scaling behavior. Concurrencia dinámica, cuotas y limitación de solicitudes (throttling).
- AWS, Execution environment lifecycle. Seguridad ante la concurrencia, apagado y reutilización de entornos.
- AWS, Configuring networking. Streaming HTTP, restricciones de VPC, conectividad de los endpoints y CORS.
- AWS, Best practices. Seguridad, comportamiento de los reintentos, verificación de despliegues y operaciones multirregión.
- AWS, Runtime support. Requisitos del runtime de Node.js y memoria.
Fuentes verificadas el 5 de noviembre de 2026 y comprobadas de nuevo el 6 de noviembre de 2026. Las capacidades y limitaciones técnicas reflejan la documentación de AWS en esas fechas, y un servicio nuevo cambia rápidamente, así que consulta las fuentes anteriores antes de actuar. Las implicaciones de costo y rendimiento son un análisis de arquitectura, no resultados de pruebas comparativas (benchmarks) independientes de TechiesJournal.