Easel, hosting de apps web, deja AWS Lambda por costos

Lambda Web Functions: la promesa de AWS y el test de Easel

AWS anunció Lambda Web Functions en octubre de 2026 como una forma de correr aplicaciones web Node.js —Express, Hono, Fastify, Next.js— directamente sobre Lambda, sin adaptadores y con facturación de CPU solo mientras el procesador trabaja. Según InfoQ, la propuesta incluía peticiones HTTP concurrentes, streaming de respuestas y un único entorno de ejecución capaz de atender varias solicitudes a la vez, lo que reduce los cold starts. Las funciones Lambda tradicionales pasaron a llamarse Lambda Event Functions.

Para Easel, una plataforma que ejecuta aplicaciones web para sus clientes, la promesa era directamente relevante: llevaban meses construyendo infraestructura propia para correr apps web sobre Lambda tradicional. Si Web Functions funcionaba como esperaban, podían reemplazar buena parte de ese trabajo.

La compañía lo probó y publicó los resultados en su blog. Las primeras señales fueron buenas: Web Functions manejó 300 peticiones concurrentes sin errores y una función nueva empezó a servir tráfico en menos de nueve segundos. Pero unas semanas después, Easel decidió quedarse con su propio compute.

¿Y esto cómo se aplica en tu negocio?

Dueños de negocio de Latinoamérica y España usan un agente de IA para ganar más y recuperar su tiempo. El Kit «tu mano derecha con IA» te muestra cómo en un video de 11 minutos, con una ficha para armar el tuyo. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.

👥 Quiero el Kit →

¿Por qué la memoria de Lambda Web Functions se factura 5–7 minutos de más?

El hallazgo central del experimento es incómodo para cualquiera que esté modelando costos de serverless. Los entornos de ejecución de Web Functions seguían vivos y acumulando cargos de memoria entre 5 y 7 minutos después de la última petición.

El matiz importa: Web Functions factura CPU solo cuando se usa, pero la memoria se cobra durante toda la vida del entorno de ejecución, incluso sin tráfico. AWS documenta ese comportamiento; lo que sorprendió a Easel fue la duración real de esas ventanas de inactividad.

Sobre seis entornos representativos, la compañía midió períodos ociosos de 313 a 411 segundos, con los procesos activos todo el tiempo y sin ningún timeout de inactividad configurable para acortarlos. El ejemplo que resume el problema: una petición de 200 ms seguida de 345 segundos sin actividad equivale a unas 1.700 veces la duración del request en tiempo de memoria facturado.

Cruzando los números con CloudWatch y AWS Cost Explorer, la memoria representó aproximadamente el 88% de los costos calculados de compute y requests a precios de lista publicados, aunque la aplicación solo usaba entre 160 y 210 MB. El experimento completo costó alrededor de dos centavos a precios de lista: nada alarmante en sí mismo.

El problema aparece a escala. Easel necesita soportar miles de aplicaciones con tráfico impredecible: algunas con demanda sostenida, otras con apenas unas pocas peticiones por día. Ahí, pagar por cada entorno ocioso e independiente deja de ser un detalle.

La compañía intentó una salida manual: terminar los entornos ella misma tras 10 segundos de inactividad. Redujo el tiempo de entorno facturado unas 20 veces, pero AWS registró cada salida intencional como un fallo de runtime. No era algo que quisieran tener en producción.

¿Cómo rindió el compute propio de Easel frente a AWS?

En lugar de adoptar Web Functions, Easel movió la ejecución de aplicaciones a servidores que opera ella misma, y dejó Lambda tradicional disponible para el overflow. Ese diseño le da control sobre el scheduling y la asignación de recursos: puede compartir capacidad entre aplicaciones sin pagar a AWS por cada entorno ocioso, y escalar fuera de su propia infraestructura cuando la demanda lo exige. Su primer host propio entró en producción en US East el 2 de noviembre, sirviendo aplicaciones que incluyen el sitio web de la propia Easel.

Pero tomar el control del compute abría otra pregunta: ¿cómo se comparaba el rendimiento contra AWS? Desplegaron la misma aplicación Next.js 16 en ambas plataformas y corrieron una serie de benchmarks desde un cliente en Ashburn, Virginia.

Peticiones en caliente: el host propio entregó tiempos medianos 1,5 a 3 veces más rápidos en las cuatro cargas de trabajo evaluadas.
Cómputo puro: las mismas 20.000 operaciones encadenadas de SHA-256 tomaron 29,2 ms en el host de Easel frente a 43,8 ms en Web Functions, cerca de 1,5 veces más rápido. La diferencia no era solo red o ruteo.
Cold starts: tras dejar ambas aplicaciones inactivas 12 minutos, Easel empezó a servir peticiones unas 3,5 veces más rápido en los dos ensayos pareados.
Reanudación tras pausa corta: después de una pausa de cinco minutos, Web Functions ya había terminado su entorno y necesitó 908 ms para responder; Easel reanudó su entorno pausado y respondió en 14 ms.

Easel es explícita sobre los límites de su propio estudio: son resultados tempranos de una sola región y una aplicación pequeña, la comparación de cold starts tiene solo dos muestras pareadas y no midieron throughput sostenido. Además, las plataformas corrían sobre hardware y configuraciones de recursos distintas, así que comparan despliegues, no hardware normalizado. Los benchmarks se corrieron el 11 y 12 de noviembre y las mediciones de memoria ociosa son del 26 de octubre.

¿Qué significa esto para tu startup?

Si estás evaluando serverless para correr una aplicación web, este caso deja tres lecciones operativas que se pueden aplicar esta semana.

1. Modela el costo con tu patrón de tráfico real, no con un request aislado. El error clásico es calcular el precio por milisegundo de CPU y multiplicar. La memoria se factura por la vida completa del entorno de ejecución, así que una app con picos y largos silencios paga por tiempo que nadie está usando. Antes de migrar, saca de CloudWatch y Cost Explorer la duración real de tus entornos y separa el gasto de memoria del de CPU. Si la memoria domina la factura, el problema no es el precio unitario: es el tiempo de vida.

2. Pregunta por el timeout de inactividad antes de comprometerte. Easel no encontró ningún parámetro configurable para acortar la vida de los entornos. Si tu arquitectura depende de apagar capacidad ociosa, verifica ese punto en la documentación y en una prueba propia, no en el material de lanzamiento.

3. Compara contra las alternativas que ya resuelven scale-to-zero. InfoQ señala que Google Cloud Run y Azure Container Apps también corren aplicaciones web sin capas de adaptación, con scale-to-zero y concurrencia configurable. Si tu carga es intermitente o en ráfagas, esa comparación es obligatoria antes de decidir. Vale recordar además que Web Functions solo soporta Node.js y está disponible en cinco regiones —Northern Virginia, Ohio, Oregon, Tokio e Irlanda— según InfoQ.

¿Cuándo conviene Lambda Web Functions y cuándo no?

La conclusión de Easel no es que Web Functions sea mala: es que encaja mejor con aplicaciones de tráfico sostenido, donde el costo de la memoria ociosa pesa menos en la ecuación. Para plataformas que corren muchas aplicaciones independientes y de tráfico irregular, la economía empuja en otra dirección.

También hay una lección de arquitectura que trasciende el caso. Operar compute propio agrega responsabilidades reales: gestionar capacidad, manejar fallos y distribuir recursos entre aplicaciones. Easel lo asume explícitamente. A cambio, gana libertad para optimizar todo el camino de ejecución en lugar de trabajar alrededor de las restricciones de otra plataforma.

Para un founder, la pregunta útil no es «¿serverless o servidores?», sino «¿mi patrón de tráfico se parece más al de una app con demanda constante o al de miles de apps que despiertan de vez en cuando?». La respuesta define si el modelo de facturación juega a tu favor o en tu contra.

Conclusión

El caso de Easel es un recordatorio de que en infraestructura los detalles de facturación pesan tanto como las capacidades técnicas. Lambda Web Functions resolvió un problema real —correr servidores HTTP estándar en Lambda sin adaptadores— y aun así no encajó en un modelo de negocio concreto, porque la memoria se cobra por la vida del entorno y no por el uso.

La parte más valiosa del experimento no es el resultado de los benchmarks, que la propia compañía califica de preliminares, sino el método: medir con datos propios, cruzar contra las herramientas de costos del proveedor y estar dispuesto a cambiar de rumbo cuando los números no cierran. Eso es replicable en cualquier startup, con cualquier proveedor de nube.