Cloudflare Workers o AWS Lambda: la latencia rápida impone límites distintos

Para una API breve con usuarios repartidos por varios países, Cloudflare Workers suele encajar mejor si la respuesta puede generarse cerca de ellos y requiere poco cálculo. AWS Lambda ofrece más margen cuando la función necesita memoria, procesamiento sostenido o acceso directo a servicios de AWS. La ubicación de los datos puede pesar más que la velocidad de arranque.

El coste también depende del recorrido de cada petición. La ejecución de una función Lambda puede resultar barata, pero una API pública puede sumar cargos por su entrada HTTP y por transferencia; un flujo que se activa dentro de AWS tiene otra estructura de costes. Los tres escenarios hipotéticos de este artículo separan la factura de ejecución de esos componentes adicionales.

El arranque rápido no mide toda la respuesta

Workers ejecuta código en la red distribuida de Cloudflare; una función Lambda ordinaria se configura en una región de AWS. Si una petición valida datos y responde sin consultar un origen lejano, ejecutar cerca del usuario puede acortar el trayecto. Si necesita una base de datos regional, todavía debe esperar la comunicación con esa base: mover la función al borde no mueve los datos.

En una prueba externa de transformación de JSON, el autor registró medianas de arranque en frío de 2 ms para Workers y 180 ms para Lambda con Node.js; los valores p99 fueron 8 y 450 ms. Describió cargas de distintos tamaños, pruebas desde tres regiones y 1.000 solicitudes por configuración. Esas cifras corresponden a los despliegues y al método del ensayo, no a una latencia garantizada para otras API.

Para interpretar esa diferencia hay que distinguir el arranque del tiempo total de respuesta. Una consulta remota, una dependencia grande o una proporción distinta de invocaciones en frío puede cambiar el resultado que recibe el usuario. También importa si la respuesta se obtiene de una caché cercana o si cada petición debe volver al mismo origen regional.

Memoria y duración delimitan qué puede ejecutarse

Los límites de Workers fijan 128 MB de memoria por isolate, compartidos por las solicitudes concurrentes que atienda. En el plan de pago, una petición HTTP parte de un límite de 30 segundos de CPU, configurable hasta cinco minutos. La espera de red no consume ese presupuesto de CPU. Mientras el cliente permanezca conectado, la petición HTTP carece de un límite general de tiempo transcurrido; después de la desconexión, las tareas pendientes pueden cancelarse.

Las cuotas de Lambda permiten asignar entre 128 y 10.240 MB a una función ordinaria y establecen un máximo de 15 minutos por invocación. La CPU asignada aumenta con la memoria configurada. Ese margen importa para cálculos largos, dependencias que ocupan mucha memoria o archivos que deban mantenerse completos durante el procesamiento.

La comparación de duración exige cuidado: el límite de CPU de Workers y el tiempo máximo de ejecución de Lambda miden cosas distintas. Un Worker que espera una respuesta de red puede permanecer activo sin consumir CPU durante toda esa espera; una tarea que necesita mantener varios gigabytes en memoria no cabe en su isolate. Dividirla en partes o delegarla cambia la arquitectura y, por tanto, la cuenta económica.

La tarifa de ejecución es solo una parte de la API

El precio oficial de Workers fija un mínimo de 5 dólares mensuales por cuenta para el plan de pago. El modelo Standard incluye diez millones de solicitudes y 30 millones de milisegundos de CPU al mes; después cobra 0,30 dólares por millón de solicitudes y 0,02 dólares por millón de milisegundos de CPU. Workers no añade cargos por transferencia de salida. Un acierto de caché sigue contando como solicitud al Worker, aunque evite el consumo de CPU del código.

Para funciones estándar x86, la tarifa de AWS Lambda utilizada en estos ejemplos es de 0,20 dólares por millón de solicitudes y 0,0000166667 dólares por GB-segundo en el primer tramo de precio. El nivel gratuito mensual incluye un millón de solicitudes y 400.000 GB-segundos. AWS cobra por separado otros servicios utilizados por la función y determinadas transferencias; las operaciones y el almacenamiento de Amazon S3, por ejemplo, no quedan incluidos en el precio de Lambda.

Las cuentas siguientes suponen que ese nivel gratuito de Lambda está disponible y no lo consumen otras funciones. Usan una tarifa x86 de referencia: la región, la arquitectura, las funciones de pago adicionales y los servicios conectados pueden alterar una factura real. En una API HTTP, el tipo de entrada elegido también importa: añadir una puerta de enlace incorpora una partida que no aparece en el precio de ejecución de Lambda.

Tres escenarios calculados con las mismas tarifas

API global de respuesta corta

Supongamos 20 millones de peticiones al mes y 2 ms de CPU por petición en Workers. El uso suma 40 millones de milisegundos de CPU. El plan cuesta 5 dólares, las diez millones de solicitudes adicionales cuestan 3 dólares y los diez millones de milisegundos de CPU adicionales cuestan 0,20 dólares: 8,20 dólares mensuales por Workers.

Si cada invocación equivalente de Lambda dura 30 ms con 128 MB asignados, el cálculo consume 75.000 GB-segundos, dentro del nivel gratuito supuesto. Quedan 19 millones de solicitudes facturables, por 3,80 dólares de ejecución. La comparación aún debe incorporar la entrada HTTP y cualquier transferencia aplicable: según cómo se publique la función, esas partidas pueden cambiar cuál de las dos opciones cuesta menos como API completa.

Proceso intensivo en memoria

Supongamos 100.000 tareas mensuales que necesitan mantener 2 GB de memoria durante 120 segundos. En Lambda representan 24 millones de GB-segundos. Tras descontar los 400.000 del nivel gratuito supuesto, el cómputo cuesta aproximadamente 393,33 dólares; las solicitudes permanecen dentro de su inclusión mensual. Si otras funciones ya agotaron el nivel gratuito, el mismo cómputo rondaría los 400 dólares.

Esa carga no cabe sin cambios en un isolate de Workers porque requiere mantener más memoria de la disponible. Transmitir los datos por partes podría reducir la memoria necesaria, pero sería otro diseño y exigiría calcular de nuevo tiempo, almacenamiento y operaciones. En este caso, el límite de recursos decide antes que la ventaja de latencia de una petición ligera.

Eventos y datos dentro de AWS

Supongamos cinco millones de eventos mensuales de Amazon S3 que activan una función Lambda de 256 MB durante 200 ms. El uso equivale a 250.000 GB-segundos, cubiertos por el nivel gratuito supuesto. Las cuatro millones de solicitudes restantes cuestan 0,80 dólares de ejecución; las operaciones y el almacenamiento de S3 mantienen su propia factura.

Como comparación estrictamente hipotética, cinco millones de peticiones HTTP a Workers con 5 ms de CPU cada una consumirían 25 millones de milisegundos y quedarían dentro de las inclusiones del plan de pago: 5 dólares por Workers. Pero los eventos originados en S3 necesitarían una conexión o un cambio de flujo para llegar al Worker. El precio y la demora de esa pieza adicional no están contenidos en los 5 dólares.

Workers ofrece una ventaja plausible para lógica breve distribuida y datos accesibles cerca de los usuarios. Lambda ofrece más espacio para una ejecución intensiva o estrechamente integrada con servicios regionales de AWS. Para una API concreta, la decisión económica y de latencia depende del recorrido completo: entrada HTTP, origen de datos, caché, procesamiento y transferencia de la respuesta.

Lee también:

• Cloudflare Workers o Vercel: el SSR rápido puede costar más al escalar
• AWS gana con la IA, pero quema caja: la factura detrás del crecimiento
• Cloudflare factura un 36% más: el tráfico de máquinas abre otro mercado