Lambda Web Functions: tu servidor HTTP en Lambda, con concurrencia real y cobro por CPU activa

El 12 de octubre de 2026 AWS presentó Lambda Web Functions, una forma nueva de correr código en Lambda pensada para aplicaciones web. La idea es simple de explicar y bastante profunda en sus consecuencias: en lugar de escribir un handler que recibe un evento JSON, subís un servidor HTTP común y corriente (Express, Hono, Fastify, React Router) que escucha en un puerto. Lambda le pone un endpoint HTTPS adelante, lo escala según el tráfico (incluso a cero) y te cobra por el tiempo de CPU que realmente usás, no por el tiempo que la request estuvo esperando a la base de datos.

Con el lanzamiento, AWS también reordenó la familia: las funciones de siempre pasan a llamarse Lambda Event Functions (es solo un cambio de nombre, no hay que tocar código ni redesplegar nada), y Lambda queda con tres formas: Event Functions, Web Functions y MicroVMs. En este artículo vemos qué es exactamente, cómo funciona por dentro, cómo se despliega con la AWS CLI, cuánto cuesta en serio y qué conviene mirar antes de llevarlo a producción, sobre todo si trabajás desde Latinoamérica.

TL;DR

• Tu código escucha en el host:puerto que Lambda te pasa en AWS_LAMBDA_HTTP_ENDPOINT. No hay adaptador ni wrapper: es tu app de Express tal cual.
• Cada entorno de ejecución atiende varias requests a la vez: hasta 128, con 64 por defecto. Es el cambio más importante respecto del modelo clásico de una request por entorno.
• Se cobra CPU activa + memoria consumida mientras vive el entorno + requests. En us-east-1 (Arm): USD 0,0000276944 por vCPU-segundo, USD 0,0000036667 por GB-segundo y USD 0,30 por millón de requests.
• Despliegue en un comando: aws lambda-web deploy --name mi-app --code ./mi-app. Con --regions lo replicás en varias regiones detrás de un dominio global con ruteo por latencia.
• Revisiones inmutables y endpoints con pesos: canary, blue/green y rollback salen de fábrica.
• Solo Node.js 24 sobre Arm64, 2 GB de memoria por entorno, timeout por request de 3 a 900 segundos.
• Disponible en us-east-1, us-east-2, us-west-2, ap-northeast-1 y eu-west-1. No está en São Paulo (sa-east-1).

Por qué ahora

Correr una aplicación web en Lambda siempre fue posible, pero con fricción. Había que adaptar el framework al modelo de eventos (con serverless-http, con la Lambda Web Adapter o con lo que trajera tu framework), y aun así cada entorno atendía una sola request por vez. Si tu API tardaba 200 ms porque esperaba a Postgres, pagabas 200 ms de cómputo aunque la CPU hubiese estado ociosa el 75% de ese tiempo. Y si llegaba una ráfaga de 50 requests simultáneas, Lambda levantaba hasta 50 entornos, con sus respectivos arranques en frío.

El otro camino era ir a contenedores: ECS con Fargate, EKS o App Runner. Ahí tenés concurrencia real dentro del proceso, pero también tenés un piso de costo (el contenedor está prendido aunque nadie lo use), balanceadores, autoescalado que configurar y, en EKS, un clúster que operar.

Lo que cambió en los últimos dos años es el tipo de carga. Las APIs que hoy más crecen son las que hablan con modelos de lenguaje: una request que dura 3 segundos mientras van llegando tokens, con la CPU casi siempre esperando. Para ese patrón, cobrar por duración total y aislar una request por entorno es la peor combinación posible. Web Functions es la respuesta de AWS a eso, y no es casual que el propio anuncio ponga los endpoints de inferencia que hacen streaming de tokens entre los primeros casos de uso.

Qué es y qué no es

Web Functions es un modelo de cómputo nuevo dentro de Lambda, con su propia API (lambda-web en la CLI), sus propios recursos y su propio modelo de precios. No es una opción que se activa en una función existente: es otro tipo de recurso.

Lo que sí es:

• Un servidor HTTP tuyo, empaquetado como .zip (en S3), que Lambda arranca y mantiene vivo mientras haya tráfico.
• Un endpoint HTTPS administrado, con TLS incluido, que puede ser regional o global.
• Concurrencia dentro del entorno: un entorno tibio absorbe picos chicos sin crear entornos nuevos.
• Streaming de respuestas sin configuración extra.
• Gestionable desde la API, la consola, la CLI, CloudFormation, SAM, CDK y los SDKs.

Lo que no es:

• No reemplaza a las Event Functions. Para procesar mensajes de SQS, archivos que llegan a S3 o eventos de EventBridge, la propia documentación te manda a las Event Functions.
• No es un contenedor: no subís una imagen, no hay Dockerfile. El código viene de un .zip en S3.
• No es multilenguaje (todavía). Hoy solo Node.js. Si tu API está en Python, Go o Java, esto no te sirve por ahora.
• No es un servidor permanente. Lambda puede reciclar un entorno en cualquier momento; el estado durable tiene que vivir afuera (DynamoDB, ElastiCache, S3, RDS).

Cómo funciona: función, revisiones y endpoints

El modelo de recursos tiene tres niveles y vale la pena entenderlo bien, porque de él sale todo lo demás:

• Web Function: el recurso de arriba, con nombre y ARN. Contiene revisiones y endpoints.
• Revisión (revision): una foto inmutable de tu código y tu configuración (timeout, concurrencia por entorno, variables de entorno, rol de ejecución). Cambiar cualquiera de esas cosas implica crear una revisión nueva.
• Endpoint: la puerta de entrada HTTPS. Tiene su dominio, su tipo de autenticación, sus límites de escalado y rutea el tráfico a una o dos revisiones según pesos.

Esta separación resuelve de un saque cosas que en Lambda clásico armabas con versiones, alias y CodeDeploy. Con un endpoint de producción y otro de staging apuntando a revisiones distintas ya tenés dos entornos; con pesos tenés canary; y volver atrás es cambiar los pesos.

Tipos de endpoint

El tipo se elige al crear el endpoint y no se puede cambiar después:

El ciclo de vida de un entorno

Cada entorno pasa por tres fases. En la inicialización, Lambda baja el .zip, prepara el runtime, carga las variables de entorno y arranca tu proceso. Tu servidor tiene 10 segundos para empezar a escuchar en AWS_LAMBDA_HTTP_ENDPOINT; Lambda detecta que el puerto está escuchando y recién ahí lo marca como listo. No hay un health check separado: escuchar en el puerto es la señal de listo. En la fase lista (Ready), el entorno recibe requests hasta su límite de concurrencia. En el apagado, Lambda deja de mandarle tráfico, espera (sin garantías) que terminen las requests en vuelo, manda SIGTERM y te da 1 segundo para limpiar.

Concurrencia y escalado

Acá está el cambio de fondo. Una Web Function escala en dos dimensiones: la cantidad de entornos y la cantidad de requests simultáneas que atiende cada uno.

Dos detalles importantes. Primero, maxConcurrencyPerEnvironment es un techo: Lambda calcula un límite dinámico según el uso de recursos de cada entorno, que puede ser menor pero nunca mayor. Segundo, hay cuotas de cuenta por región aunque no configures nada: 10.000 RPS por endpoint, 100.000 RPS en total y 2.000 vCPU. Como cada entorno usa 2 vCPU, eso te da como máximo 1.000 entornos por región en toda la cuenta.

Lambda escala por adelantado para mantener margen libre (headroom), de modo que un aumento gradual se absorbe sin arranques en frío. Cuando llega una ráfaga más grande que ese margen, algunas requests esperan a que se inicialicen entornos nuevos.

Cuando algo se satura, la respuesta depende de qué se saturó:

La documentación trae un ejemplo que conviene tener en la cabeza: con 10 entornos y 64 requests por entorno tenés 640 requests en vuelo. Si cada request tarda 200 ms, eso da unas 3.200 RPS; si tarda 10 ms, el límite que vas a tocar primero es el rateLimit, no la concurrencia.

Seguridad: quién puede llamar al endpoint

Cada endpoint tiene uno de dos modos de autenticación:

• IamAuth: Lambda valida firmas SigV4 (o SigV4a en endpoints MultiRegion) y evalúa la política de identidad del que llama y la política basada en recursos de la Web Function. La acción es lambda:InvokeWebFunctionEndpoint.
• ApplicationManaged: Lambda no autentica nada. Todas las requests llegan a tu código y la autenticación es problema tuyo (JWT, cookies, lo que uses).

Ojo con esto: aws lambda-web deploy crea el endpoint como ApplicationManaged por defecto, es decir, público. Para el hola mundo está perfecto; para una organización con cuentas de producción, no tanto. La documentación propone una SCP que bloquea la creación de endpoints sin IAM usando la clave de condición lambda:Request/WebFunctionAuthType; la vemos en la sección práctica.

CloudFront adelante, con OAC

Para dominio propio y AWS WAF, el camino es poner CloudFront adelante. El mismo día salió el soporte de Web Functions como origen de CloudFront, sin costo adicional, con Origin Access Control (OAC): CloudFront firma las requests al origen y el endpoint, configurado como IamAuth, solo acepta las de esa distribución. Es el mismo patrón que ya usás con buckets de S3 privados.

Un detalle fino: en endpoints IamAuth, Lambda saca el header Authorization después de validar la firma. Si tu app necesita ese header (porque ahí viaja el JWT del usuario), la documentación indica configurar CloudFront para que lo reenvíe; Lambda solo descarta los valores que empiezan con AWS4-.

Red: salida hacia tu VPC

La entrada siempre es por el endpoint público administrado por Lambda. Lo que se configura es la salida: por defecto la revisión sale a internet por IPv4 con una IP que no es estable (no sirve para listas blancas) y no ve nada privado de tu VPC. Para llegar a RDS, ElastiCache o un servicio interno, creás un network connector con subnets y security groups, y lo referenciás desde la revisión. Ahí aplican tus tablas de ruteo, security groups y NACLs, y si necesitás internet desde esas subnets, necesitás NAT Gateway (o un egress-only internet gateway para IPv6).

Manos a la obra

Vamos a desplegar una API de Express, ponerle IAM, hacer un canary y conectarla a la VPC. Necesitás AWS CLI v2 actualizada (verificá que exista aws lambda-web help; si no, aws update si instalaste con el instalador oficial) y Node.js 24 para probar localmente.

1. La app: Express sin adaptadores

El único cambio respecto de tu app local es leer el host y el puerto de la variable de entorno:

// index.js
const express = require('express');
const app = express();

app.get('/', (req, res) => {
  res.json({ message: 'Hola desde Lambda Web Functions', path: req.path });
});

app.get('/health', (req, res) => res.send('ok'));

// Lambda define AWS_LAMBDA_HTTP_ENDPOINT como host:puerto. Localmente usamos un default.
const [host, port] = (process.env.AWS_LAMBDA_HTTP_ENDPOINT || 'localhost:3000').split(':');
app.listen(port, host);

// Tenés 1 segundo para limpiar antes de que Lambda termine el proceso.
process.on('SIGTERM', () => {
  process.exit(0);
});

Para probar local: AWS_LAMBDA_HTTP_ENDPOINT=127.0.0.1:3000 node index.js. Por defecto el runtime carga index.js en la raíz del paquete; si tu punto de entrada es otro, definí AWS_LAMBDA_NODEJS_ENTRYPOINT.

2. Desplegar en un comando

# Primera vez: crea rol, bucket versionado, la función, la revisión 1 y el endpoint
aws lambda-web deploy --name mi-api --code ./mi-api

# Lo mismo pero con el endpoint protegido por IAM (recomendado fuera de pruebas)
aws lambda-web deploy --name mi-api --code ./mi-api --auth-type IamAuth

# Reusando un bucket y un rol propios
aws lambda-web deploy \
  --name mi-api \
  --code ./mi-api \
  --bucket-name mi-bucket-de-deploys \
  --execution-role-arn arn:aws:iam::111122223333:role/mi-api-execution-role

El comando devuelve una URL del estilo https://bcdfghjklmnpqrst.b7t.lambda-web.us-east-1.on.aws. Si lo volvés a correr, detecta la función existente, sube una revisión nueva y mueve el endpoint. Para un despliegue multirregión con un dominio global, agregás --regions us-east-1,eu-west-1,ap-northeast-1.

3. Lo mismo con la API, para tu pipeline

En CI/CD vas a preferir los comandos de bajo nivel, porque te dan control sobre cada paso:

cd mi-api && zip -r ../mi-api.zip . && cd ..
aws s3 cp mi-api.zip s3://mi-bucket-de-deploys/mi-api.zip

aws lambda-web create-web-function \
  --function-name mi-api \
  --revision-config '{
    "buildConfig": {
      "codeConfig": { "s3Object": { "bucket": "mi-bucket-de-deploys", "key": "mi-api.zip" } },
      "runtimeConfig": { "runtime": "nodejs24.x" }
    },
    "serviceConfig": {
      "executionRoleArn": "arn:aws:iam::111122223333:role/mi-api-execution-role",
      "timeoutSeconds": 30,
      "maxConcurrencyPerEnvironment": 32
    }
  }' \
  --endpoint-config '{
    "endpointName": "prod",
    "endpointType": "HomeRegion",
    "authType": "IamAuth",
    "autoDeploymentMode": "Disabled"
  }'

aws lambda-web wait web-function-revision-active --function-name mi-api --revision-id rev-abc12
aws lambda-web get-web-function-endpoint --function-name mi-api --endpoint-name prod

Cada revisión nueva lleva toda la configuración (buildConfig y serviceConfig completos): una revisión no hereda nada de la anterior.

4. Canary y rollback

Con el endpoint en autoDeploymentMode: Disabled, el tráfico se mueve a mano con pesos:

# 10% a la revisión nueva
aws lambda-web update-web-function-endpoint \
  --function-name mi-api \
  --endpoint-name prod \
  --revision-weights '[{"revisionId": "rev-abc12", "weight": 90}, {"revisionId": "rev-def45", "weight": 10}]'

aws lambda-web wait web-function-endpoint-updated --function-name mi-api --endpoint-name prod

# Promoción
aws lambda-web update-web-function-endpoint \
  --function-name mi-api \
  --endpoint-name prod \
  --revision-weights '[{"revisionId": "rev-def45", "weight": 100}]'

# Rollback: todo a la revisión conocida (incluí el modo para que funcione en cualquier estado)
aws lambda-web update-web-function-endpoint \
  --function-name mi-api \
  --endpoint-name prod \
  --auto-deployment-mode Disabled \
  --revision-weights '[{"revisionId": "rev-abc12", "weight": 100}]'

Un detalle del rollback que conviene saber: si la revisión de destino no tiene entornos corriendo, Lambda la escala mientras mueve el tráfico, y en ese lapso puede haber latencia extra o algunos 429. Mantener la revisión anterior con un poco de tráfico durante el canary ayuda.

5. Límites de escalado sin crear revisión

aws lambda-web update-web-function-endpoint \
  --function-name mi-api \
  --endpoint-name prod \
  --scaling-config '{"maxEnvironments": 50}' \
  --throttle-config '{"rateLimit": 8000}'

Usalo para proteger lo que está atrás: si tu RDS aguanta 400 conexiones, maxEnvironments es tu forma de no tumbarla.

6. Salida a la VPC

aws lambda-core create-network-connector \
  --name mi-connector \
  --configuration '{
    "VpcEgressConfiguration": {
      "SubnetIds": ["subnet-0ab1c2d3e4f5a6b78", "subnet-1bc2d3e4f5a6b7c89"],
      "SecurityGroupIds": ["sg-0123456789abcdef0"],
      "NetworkProtocol": "IPv4",
      "AssociatedComputeResourceTypes": ["WebFunction"]
    }
  }' \
  --operator-role arn:aws:iam::111122223333:role/NetworkConnectorOperatorRole

Después, en la revisión, agregás "egressNetworkConnectorArn" dentro de serviceConfig con el ARN con versión del connector (termina en :4, por ejemplo). Ni el nombre ni el ARN sin versión sirven.

7. Guardarraíl organizacional

Esta SCP, tomada de la documentación, impide crear o actualizar endpoints sin IAM en las cuentas donde la apliques:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": [
        "lambda:CreateWebFunction",
        "lambda:CreateWebFunctionEndpoint",
        "lambda:UpdateWebFunctionEndpoint"
      ],
      "Resource": "*",
      "Condition": {
        "StringEquals": { "lambda:Request/WebFunctionAuthType": "ApplicationManaged" }
      }
    }
  ]
}

Con esa SCP activa, aws lambda-web deploy falla con acceso denegado salvo que agregues --auth-type IamAuth.

Trampas comunes

• "Active" no significa "anda". Lambda no verifica que tu servidor responda: una revisión puede quedar en Active y fallar todas las requests. Siempre mandá una request de prueba después de desplegar.
• Puerto hardcodeado. Si hacés app.listen(3000), el entorno nunca queda listo. Usá AWS_LAMBDA_HTTP_ENDPOINT.
• Arranque lento. Tenés 10 segundos para escuchar. Diferí la inicialización pesada (conexiones, clientes) para después del listen o hacela perezosa en la primera request.
• Estado global compartido. Con 64 requests en el mismo proceso, una variable global mutable es un bug esperando a pasar. El código tiene que ser seguro para concurrencia, igual que en un contenedor.
• Memoria compartida. Son 2 GB por entorno para todo: heap, buffers y las requests en vuelo. El heap de V8 arranca en 1.024 MB; si lo necesitás más grande, NODE_OPTIONS=--max-old-space-size=.... Para cargas que usan mucha CPU o memoria por request, bajá maxConcurrencyPerEnvironment.
• Caché de DNS. Los entornos cachean DNS; si cambiás un registro privado, creá una revisión nueva para forzar un recambio limpio.
• El connector solo funciona con HomeRegion. Si planeabas un endpoint MultiRegion que hable con RDS en tu VPC, eso no está soportado.
• Requests firmadas a mano. En IamAuth, toda request firmada tiene que incluir X-Amz-Content-SHA256, aunque no tenga cuerpo.
• Limpieza incompleta. aws lambda-web delete-web-function --function-name mi-api borra endpoints y revisiones, pero no el rol por defecto, ni los paquetes en S3, ni los log groups de CloudWatch.

Para probar antes de subir, LocalStack ya emula Web Functions desde su versión 2026.10.0 (planes Hobby en adelante).

Precios

Web Functions tiene cuatro dimensiones: requests, CPU activa, memoria consumida durante la vida de cada entorno (incluido el tiempo ocioso entre requests) y transferencia de datos estándar. El cómputo se mide con granularidad de 1 ms. La página de precios no menciona capa gratuita para Web Functions.

AWS publica cuatro ejemplos, todos con un solo entorno atendiendo el tráfico durante un mes de 2.592.000 segundos, sin capa gratuita ni transferencia:

Para ponerlo en contexto hice la cuenta con Event Functions (precio x86 que figura en la misma página: USD 0,0000166667 por GB-segundo y USD 0,20 por millón de requests), suponiendo 512 MB de memoria configurada y sin capa gratuita. Es una suposición mía, no un número de AWS:

La lectura honesta: para requests cortas, Web Functions no es automáticamente más barato. El precio de la vCPU por segundo es alto y el de la request es 50% más caro. Donde la diferencia es enorme es en requests largas que pasan casi todo el tiempo esperando, como el streaming de tokens: ahí pagar solo la CPU activa y compartir la memoria entre varias requests en vuelo cambia el orden de magnitud.

Cómo bajar costos en la práctica:

• Subí maxConcurrencyPerEnvironment en cargas con mucho I/O. Más requests por entorno es menos memoria total pagada.
• Cuidá la memoria, no solo la CPU. La memoria se cobra mientras el entorno vive, aunque esté ocioso. Un proceso de Node que retiene caches gigantes paga por eso.
• Cacheá en CloudFront. Lo que se sirve desde el borde no llega a la función: ni CPU ni request.
• No migres por migrar. Si tenés una API de 30 ms que hoy corre bien como Event Function, hacé la cuenta antes. El ahorro aparece cuando la duración es mucho mayor que la CPU.
• Medí con métricas reales. EndpointActiveEnvironments y EnvironmentConcurrentRequests te dicen si estás aprovechando la concurrencia.

Disponibilidad y lo que conviene mirar con lupa

• ¿Está en sa-east-1? No. Al lanzamiento está en Norte de Virginia, Ohio, Oregón, Tokio e Irlanda. Si tus usuarios están en Argentina, Chile o Brasil, hoy la opción más cercana es us-east-1, con la latencia que eso implica. CloudFront adelante ayuda con TLS en el borde y caché de lo estático, pero lo dinámico sigue viajando a Estados Unidos.
• Residencia de datos. Si usás MultiRegion o PerRegion, tu código y configuración se replican en las regiones elegidas, y la documentación de monitoreo indica que las métricas de requests y los logs se centralizan de forma asíncrona en la región de origen. Si tenés requisitos regulatorios sobre dónde se procesan o guardan los datos, quedate en HomeRegion o elegí regiones con cuidado.
• Transferencia entre regiones. Se cobra la transferencia de datos estándar. Un endpoint global que atiende en Tokio pero consulta una base en us-east-1 te va a generar tráfico interregional (y latencia). Para que el multirregión tenga sentido, los datos también tienen que estar cerca.
• Cifrado. Podés usar una clave KMS propia por revisión; para endpoints multirregión necesitás una clave multirregión con réplica en cada región.
• Madurez. El anuncio no lo etiqueta como preview, pero es un servicio de días. Solo hay un runtime, el soporte de herramientas de terceros (Terraform, frameworks de despliegue) va a tardar algunas semanas en ponerse al día, y conviene probar con tráfico real antes de comprometer una API crítica.

¿Vale la pena?

Depende de qué estés corriendo hoy. Si tenés APIs en Node.js sobre Lambda con serverless-http o la Lambda Web Adapter, Web Functions te saca una capa de adaptación y te da concurrencia real; la migración es casi trivial. Si tenés endpoints que hablan con LLMs y hacen streaming, es probablemente el caso más claro: la diferencia de costo frente al modelo por duración es grande y el streaming viene de fábrica. Si tenés una API en EKS o ECS que pasa buena parte del día con poco tráfico, vale la pena hacer la cuenta, porque el escalado a cero es algo que un Deployment con réplicas mínimas no te da.

Donde no lo usaría todavía: APIs en otros lenguajes (no hay opción), servicios que dependen de WebSockets (no encontré soporte documentado al lanzamiento), cargas con usuarios concentrados en Sudamérica y requisitos de latencia estrictos, y servicios con tráfico alto y sostenido donde un contenedor bien dimensionado sigue siendo más barato.

Mi lectura: lo más interesante no es "Express en Lambda", que ya se podía hacer, sino que AWS cambió la unidad de cobro y de aislamiento de su servicio serverless más usado. Durante diez años Lambda nos obligó a pensar en una request por entorno y a pagar el tiempo de espera; eso tenía sentido con funciones cortas y orientadas a eventos, y dejó de tenerlo con aplicaciones que pasan segundos esperando a un modelo. Web Functions acerca Lambda al modelo de Cloud Run o de un contenedor bien escalado, pero sin clúster y con revisiones, canary y multirregión incluidos. El punto flojo es el arranque: solo Node.js, solo cinco regiones y sin São Paulo. Para quienes trabajamos con plataformas en la región, lo pondría a prueba ya en un servicio no crítico de Node, especialmente si habla con Bedrock, y esperaría a ver la hoja de ruta de runtimes y regiones antes de proponerlo como estándar.

Recursos

• Anuncio en What's New: AWS Lambda announces Lambda Web Functions
• Post en AWS News Blog (Micah Walter)
• CloudFront soporta Lambda Web Functions como origen
• Guía de Lambda Web Functions
• Crear una Web Function (consola, CLI y API)
• Comportamiento de escalado y cuotas
• Control de acceso a endpoints (IamAuth, OAC, SCP)
• Redes y conectividad con la VPC
• Precios de AWS Lambda
• LocalStack: probar Web Functions localmente
• Classmethod: análisis de lambda-web a partir del código fuente público (en japonés)
• En este blog: AWS Lambda MicroVMs, sandboxes serverless para IA y código no confiable