AWS Lambda Web Functions, el servicio que AWS anunció en octubre con servidores HTTP nativos y facturación por CPU activa, llegó con la promesa de reemplazar buena parte de la infraestructura casera que muchas empresas construyen sobre Lambda clásica. Easel.sh, una plataforma de despliegue, lo probó durante varias semanas y encontró un problema que la documentación de AWS no aclara: un entorno inactivo sigue facturando memoria entre 5 y 7 minutos después de atender la última petición, sin ningún parámetro para acortar ese margen. La empresa terminó construyendo su propio compute y, de paso, midió que respondía hasta 3,5 veces más rápido que AWS Lambda Web Functions.

A diferencia de Lambda clásica, que ejecuta una función por invocación y la apaga enseguida, Web Functions mantiene un servidor capaz de atender varias peticiones a la vez. Para una empresa como Easel, que opera infraestructura de despliegue para miles de aplicaciones de terceros, eso prometía reemplazar buena parte del trabajo que ya habían invertido en correr apps web eficientemente sobre Lambda clásica.

AWS Lambda Web Functions: nueve segundos para arrancar, cinco minutos facturando sin uso

Las primeras pruebas de Easel fueron buenas. Web Functions manejó 300 peticiones concurrentes sin errores y una función nueva ya atendía tráfico en menos de nueve segundos, según el reporte de la empresa. El problema apareció después: AWS documenta que Web Functions facturan memoria durante toda la vida del entorno de ejecución, incluso sin peticiones corriendo, pero no especifica cuánto tiempo sigue vivo un entorno ocioso antes de apagarse.

Easel midió seis entornos representativos y, según su propio reporte, encontró períodos ociosos de entre 313 y 411 segundos (poco más de 5 a casi 7 minutos), sin ningún timeout configurable para acortarlos. Para una petición de 200 milisegundos seguida de 345 segundos de inactividad, eso equivale a facturar memoria por un tiempo unas 1.700 veces mayor que la propia petición. En su comparación con AWS Cost Explorer, la memoria representó alrededor del 88% del costo calculado de cómputo y peticiones a precios de lista, aunque la aplicación de prueba solo usaba entre 160 y 210 MB.

El experimento completo costó apenas unos dos centavos de dólar a precios de lista, así que para una app con tráfico constante el problema puede no importar mucho: el mismo entorno atiende muchas peticiones y reparte el costo ocioso entre todas. Pero Easel aloja miles de aplicaciones con tráfico impredecible, muchas de las cuales reciben solo un puñado de peticiones al día. Multiplicado por miles de despliegues independientes, la cuenta cambia.

📌 Nota: Easel probó apagar sus propios entornos a los 10 segundos de inactividad. Eso redujo el tiempo de entorno facturado unas 20 veces, pero AWS registró cada cierre voluntario como un fallo de runtime, algo que la empresa no quiso arriesgar en producción.
Easel.sh midió entornos ociosos de 313 a 411 segundos antes de probar compute propio.

Compute propio: de 1,5 a 3,5 veces más rápido en el mismo Next.js

En vez de adoptar Web Functions, Easel movió la ejecución a servidores que opera ella misma, dejando la Lambda clásica solo para el desborde de tráfico. El primer host de compute propio entró en producción en el este de Estados Unidos el 2 de noviembre de 2026, sirviendo aplicaciones de clientes y el propio sitio de Easel.

Para comparar el rendimiento, la empresa desplegó la misma aplicación Next.js 16 en ambas plataformas y corrió benchmarks desde un cliente en Ashburn, Virginia, según su propio reporte. El resultado fue de 1,5 a 3 veces más rápido en tiempo de respuesta en caliente en los cuatro tipos de carga que probó: una API JSON tardó 9,3 ms en Easel frente a 27,0 ms en Web Functions (2,9 veces), el renderizado del lado del servidor pasó de 26,0 ms a 12,2 ms (2,1 veces), el primer fragmento de una respuesta en streaming bajó de 18,1 ms a 9,1 ms (2,0 veces) y una API con uso intensivo de CPU pasó de 61,4 ms a 39,7 ms (1,5 veces).

La diferencia no fue solo enrutamiento de red: 20.000 operaciones SHA-256 encadenadas tardaron 29,2 ms en el host de Easel frente a 43,8 ms en Web Functions, 1,5 veces más rápido en cómputo puro. En arranque en frío, tras dejar ambas aplicaciones inactivas 12 minutos, Easel respondió en 216 a 250 ms contra 810 a 854 ms de AWS en dos pruebas pareadas, unas 3,5 veces más rápido. Después de un período más corto de cinco minutos de inactividad, Web Functions ya había terminado su entorno y necesitó 908 ms para responder, mientras que Easel reanudó su entorno pausado en apenas 14 ms.

Lambda clásica y Vercel Fluid Compute: el mismo dilema, otro compromiso

Easel no es la primera en chocar con la facturación de memoria ociosa. En la discusión que generó el caso en Hacker News, un usuario identificado como Onavo apuntó que Fluid Compute de Vercel tiene un comportamiento "más correcto", posiblemente porque corre sobre la misma infraestructura de AWS (que además es inversor de Vercel). Es una opinión de la comunidad, no una medición de Easel, pero marca el punto de comparación obvio para quien evalúa estas tres rutas.
PlataformaQué resuelveRiesgo o límiteAWS Lambda clásicaFactura por invocación corta; no mantiene un servidor HTTP persistentePara manejar HTTP concurrente con eficiencia hay que construir infraestructura propia, justo lo que Easel ya tenía antes de probar Web FunctionsVercel Fluid ComputeSegún el comentario de Onavo en HN, mantiene el entorno vivo sin la misma penalización de memoria ociosaLa cifra es una opinión de un usuario de HN, no una medición de Easel; además es una plataforma administrada y cerrada, no compute propioCompute propio de Easel.shHost propio en EE.UU. desde el 2 de noviembre de 2026, con Lambda clásica solo de desbordeExige operar servidores y repartir capacidad entre clientes; no es una opción lista para un equipo que no quiere administrar infraestructuraEl host propio de Easel.sh entró en producción en EE.UU. el 2 de noviembre de 2026.

Qué significa esto para tu stack

Si administrás una API o un backend en Next.js sobre Lambda Web Functions con tráfico esporádico (un SaaS multi-tenant, microservicios internos, paneles que reciben pocas peticiones por hora), conviene abrir AWS Cost Explorer y separar cuánto del costo es memoria facturada contra cuánto es cómputo real. El 88% que midió Easel es la señal de qué buscar antes de comprometerte con esta opción.

Además de Cost Explorer, vale la pena revisar las métricas de CloudWatch por entorno de ejecución (duración por invocación versus tiempo total del entorno) para ver si tu propio tráfico se parece al patrón que describe Easel: peticiones cortas separadas por minutos de silencio. Si la proporción se acerca al 88% que midió la empresa, probablemente estás pagando mucho más por memoria ociosa que por trabajo real.

Un comentario en la discusión de Hacker News ofrece una pista concreta: el usuario torginus escribió que "si cerrás tu proceso de Lambda, el contenedor simplemente se apaga, y podés hacerlo después de devolver la respuesta". Antes de aplicarlo en producción conviene probarlo en un entorno de pruebas: Easel ya intentó algo parecido (apagar entornos a los 10 segundos de inactividad) y AWS registró cada salida voluntaria como un fallo de runtime en vez de un cierre limpio, así que el comportamiento puede no ser tan predecible como suena.

Para equipos con tráfico constante, nada de esto cambia mucho: el mismo entorno reparte el costo ocioso entre muchas peticiones. El problema aparece con tráfico intermitente o en plataformas multi-tenant que hospedan muchas apps chicas, justo el caso de Easel.

Los límites del experimento

Easel aclara que estos son resultados iniciales de una sola región de AWS y de un solo cliente de prueba en Ashburn, Virginia; no hay garantía de que se repliquen en otras regiones o con otro perfil de tráfico. La comparación de arranque en frío se basa en apenas dos pruebas pareadas, una muestra chica para sostener una diferencia de 3,5 veces. Y conviene tener presente que Easel vende compute propio: tiene un incentivo directo para que su infraestructura salga mejor en la comparación, algo que no invalida los números pero sí pide leerlos con ese contexto.

Referencias

Seguimos el tema en @programacion.