Lambda Web Functions cobra la memoria mientras el entorno viva: el punto de equilibrio contra Lambda clásica

AWS lanzó Lambda Web Functions el 12 de octubre de 2026. Corre un servidor HTTP normal, atiende hasta 128 peticiones a la vez por entorno y cobra CPU activa en vez de tiempo de reloj. Suena a un descuento directo sobre AWS Lambda clásica. No lo es: el costo pasa de "el tiempo que corre una petición" a "la memoria que ocupa un entorno mientras existe". Este post calcula dónde se cruzan las dos líneas y lo prueba con una API real.

Qué cambia en la factura

Lambda clásica (us-east-1, Arm) cobra cada petición mientras corre:

• $0.0000133334 por GB-segundo de memoria configurada, en tiempo de reloj, incluido el tiempo que pasa esperando a la base de datos
• $0.20 por millón de peticiones

Web Functions cobra tres cosas:

• $0.0000276944 por vCPU-segundo de CPU activa. Esperar I/O casi no cuesta.
• $0.0000036667 por GB-segundo de memoria, mientras el entorno exista, incluido el tiempo ocioso entre peticiones
• $0.30 por millón de peticiones

Dos consecuencias:

1. La memoria se vuelve un piso mensual. Si llega tráfico cada pocos minutos, el entorno nunca se apaga. Con 1 GB son unos $9.50 al mes antes de cobrar una sola petición.
2. La CPU cuesta casi el doble por segundo, pero sólo cuenta la CPU. Una petición que tarda 200 ms y calcula durante 50 ms paga 50 ms.

Así que Web Functions gana por petición sólo cuando las peticiones esperan mucho más de lo que calculan, y necesita suficientes peticiones para pagar el piso.

El punto de equilibrio

Los dos modelos pagan por petición; Web Functions además paga el piso. El cruce está en:

break-even requests/month = floor / (classic cost per request - Web Functions cost per request)

classic per request        = latency_s * classic_GB * 0.0000133334 + 0.0000002
Web Functions per request  = cpu_s * 0.0000276944 + 0.0000003
floor                      = env_GB * 2,592,000 * 0.0000036667

La página de precios de AWS trae un ejemplo de "API backend con mucho I/O": 200 ms por petición, 50 ms de CPU, unos 0.29 GB por entorno. Contra una función clásica de 1 GB:

Web Functions memory floor   $2.76/month
classic, per million         $2.87
Web Functions, per million   $1.68
break-even                   2,331,877 requests/month

Arriba de 2.3 millones de peticiones al mes, Web Functions sale más económica. Ahora la misma carga contra una función clásica de 512 MB:

Web Functions memory floor   $2.76/month
classic, per million         $1.53
Web Functions, per million   $1.68
Web Functions never pays off: per request it costs as much or more than classic.

La respuesta se voltea según cuánta memoria necesitaría la función clásica. La comparación sólo tiene sentido contra la configuración clásica que de verdad usarías. Una advertencia: Lambda clásica asigna CPU en proporción a la memoria, así que 50 ms de CPU a 1 GB tardan más a 512 MB, y la latencia sube con ellos. Mide antes de confiar en la línea más económica.

Una API real

Una API pequeña en producción: FastAPI en una tarea de AWS Fargate (0.25 vCPU, 1 GB, Arm), detrás de un Application Load Balancer, con PostgreSQL en Amazon RDS. Catorce días de métricas de Amazon CloudWatch:

RequestCount                 101865.0
latency_s avg=0.075 max=33.25 p50=0.0085 p99=1.096
minutes with >=1 request: 20159 of 20160
p50 requests/min: 1
peak requests/min: 283 (4.72 rps)
MemoryUtilization  68.65622133758562

Unas 218,000 peticiones al mes, con tráfico en casi todos los minutos y una petición por minuto en la mediana. Como hay tráfico en cada minuto, un entorno se quedaría vivo todo el mes y el piso se paga completo.

El punto de equilibrio en el caso más favorable para Web Functions, cero CPU por petición:

Web Functions memory floor   $6.56/month
classic, per million         $1.20
Web Functions, per million   $0.30
break-even                   7,286,426 requests/month
your traffic                 218,282 requests/month (3.0% of break-even)

Esta API necesitaría 33 veces su tráfico para que Web Functions le gane a Lambda clásica, aunque sus peticiones no usaran nada de CPU.

La factura mensual completa:

El hallazgo más grande está en la segunda fila. A este tamaño, el dinero no se va en el cómputo. El balanceador, sus dos direcciones IPv4 públicas y el WAF regional cuestan cuatro veces lo que cuesta el contenedor que tienen detrás. Cualquiera de las dos opciones de Lambda ahorra sobre todo porque quita el ALB, no porque calcule de forma más eficiente. Un dominio propio o un WAF delante de Lambda siguen necesitando Amazon CloudFront, así que el costo del WAF se muda en vez de desaparecer.

Para esta API la pregunta es teórica de todos modos: en el lanzamiento, Web Functions sólo corre Node.js, y esta API es Python.

Cuándo conviene

• Usa Web Functions cuando el tráfico sea constante y alto, las peticiones pasen casi todo su tiempo esperando I/O, el código sea Node.js y la función clásica que reemplazas necesite mucha memoria.
• Quédate en Lambda clásica cuando el tráfico sea bajo o a ráfagas. Si un entorno atiende unas cuantas peticiones por minuto, el piso de memoria es puro gasto extra.
• Si estás en contenedores, revisa la puerta de entrada antes que el cómputo. Un servicio pequeño detrás de un ALB puede pagar más por el balanceador que por la tarea.