{"id":497,"date":"2026-03-09T13:22:48","date_gmt":"2026-03-09T13:22:48","guid":{"rendered":"https:\/\/blog.rebalai.com\/es\/2026\/03\/09\/cloudflare-workers-vs-aws-lambda-which-edge-runtim\/"},"modified":"2026-03-18T22:31:24","modified_gmt":"2026-03-18T22:31:24","slug":"cloudflare-workers-vs-aws-lambda-which-edge-runtim","status":"publish","type":"post","link":"https:\/\/blog.rebalai.com\/es\/2026\/03\/09\/cloudflare-workers-vs-aws-lambda-which-edge-runtim\/","title":{"rendered":"Cloudflare Workers vs AWS Lambda: Lo que aprend\u00ed despu\u00e9s de 5 meses en producci\u00f3n"},"content":{"rendered":"

Llevamos cuatro a\u00f1os usando AWS Lambda en nuestro equipo. Somos tres personas \u2014 cuatro cuando hay presupuesto para contratar \u2014 y construimos el backend de una plataforma SaaS B2B. Lambda nos funcion\u00f3 bien desde el principio: deploy predecible, escala autom\u00e1tica, costo proporcional al uso. No ten\u00edamos razones reales para cuestionarlo.<\/p>\n

Pero hace unos ocho meses empec\u00e9 a ver demasiados complaints sobre latencia en los logs de nuestros clientes europeos. La arquitectura era est\u00e1ndar: API Gateway + Lambda en us-east-1, con CloudFront delante. Funcional, pero la experiencia para usuarios fuera de EEUU era notoria en los P95. Fue ah\u00ed cuando empec\u00e9 a investigar Workers m\u00e1s en serio.<\/p>\n

Termin\u00e9 corriendo los dos sistemas en paralelo durante cinco meses, con los mismos endpoints, las mismas m\u00e9tricas y la misma carga real. Ac\u00e1 est\u00e1 lo que aprend\u00ed<\/a>.<\/p>\n

V8 Isolates vs Contenedores<\/a>: La Diferencia que Determina Todo lo Dem\u00e1s<\/h2>\n

La primera vez que intent\u00e9 explicarle Workers a un compa\u00f1ero, empec\u00e9 por el marketing: “es serverless en el<\/a> edge, latencia ultrabaja, red global…” y los ojos se le pusieron vidriosos. La segunda vez empec\u00e9 por la arquitectura, y ah\u00ed s\u00ed prest\u00f3 atenci\u00f3n.<\/p>\n

Lambda funciona con micro-VMs. AWS usa Firecracker internamente \u2014 una tecnolog\u00eda muy buena, de hecho \u2014 que levanta entornos virtualizados con su propio kernel Linux liviano. Cuando una funci\u00f3n estuvo inactiva unos minutos, esa VM se destruye. La pr\u00f3xima invocaci\u00f3n tiene que arrancar el kernel, inicializar el runtime de Node.js, cargar tus m\u00f3dulos, ejecutar el c\u00f3digo de inicializaci\u00f3n. Eso es el cold start. No es un bug, es la consecuencia natural del modelo.<\/p>\n

Cloudflare Workers usa V8 isolates. El proceso de V8 ya est\u00e1 corriendo en el<\/a> servidor de Cloudflare. Crear un nuevo isolate \u2014 el contexto de ejecuci\u00f3n aislado para tu Worker \u2014 toma microsegundos porque no hay kernel que arrancar. Es conceptualmente m\u00e1s parecido a crear un nuevo web worker en el<\/a> browser que a levantar una VM. El overhead es de otro orden de magnitud.<\/p>\n

Esto explica los cold starts casi inexistentes. Pero tambi\u00e9n explica las restricciones: vives dentro del sandbox de V8, sin acceso al sistema operativo real. Nada de m\u00f3dulos nativos (archivos .node<\/code>), nada de filesystem local, nada de sockets TCP directos. El runtime es b\u00e1sicamente el mismo que en el browser, con las APIs de Service Workers m\u00e1s algunas extensiones de Cloudflare.<\/p>\n

Una cosa que no anticip\u00e9 \u2014 y me quem\u00f3 una vez \u2014 es el comportamiento de la memoria entre requests. En Lambda, cada instancia caliente conserva su estado en memoria mientras no se destruya. En Workers, cada isolate es te\u00f3ricamente ef\u00edmero, aunque Cloudflare reutiliza isolates para requests consecutivos del mismo Worker (lo documentan como “isolate reuse”). El comportamiento exacto no est\u00e1 completamente especificado. Tuve un bug sutil con un array global que se estaba acumulando entre requests en staging, hasta que<\/a> lo not\u00e9 en los logs. Culpa m\u00eda por usar estado global mutable \u2014 pero en Lambda ese patr\u00f3n era m\u00e1s predecible.<\/p>\n

wrangler dev<\/code> es genuinamente bueno: corre un isolate local que se comporta casi id\u00e9ntico a producci\u00f3n. Con Lambda, el desarrollo local v\u00eda SAM local o LocalStack siempre tiene alguna peque\u00f1a diferencia que te aparece en producci\u00f3n<\/a>. No es decisivo, pero el ciclo de iteraci\u00f3n con Workers se siente m\u00e1s \u00e1gil.<\/p>\n

Cold Starts en Producci\u00f3n:<\/a> Los N\u00fameros con Contexto Real<\/h2>\n

Para tener n\u00fameros honestos, instrument\u00e9 ambos sistemas con OpenTelemetry desde el primer mes de la prueba, enviando trazas a Axiom. Quer\u00eda medir cold starts espec\u00edficamente \u2014 que en OTel se manifiestan como un span de inicializaci\u00f3n m\u00e1s largo en la primera invocaci\u00f3n tras inactividad \u2014 y separar eso de la latencia de negocio real.<\/p>\n

Las condiciones: endpoints de API REST con tr\u00e1fico variable, per\u00edodos de baja actividad de madrugada, Node.js 20 en Lambda con 256MB de memoria asignada.<\/p>\n

Los cold starts de Lambda en P50 andaban en 350-400ms. El P95 llegaba a 720ms. Y cuando hab\u00eda un pico de tr\u00e1fico despu\u00e9s de<\/a> un per\u00edodo inactivo \u2014 el lunes a las<\/a> 9am cuando varios clientes entraban casi simult\u00e1neamente \u2014 el P99 superaba 1.2 segundos. Para endpoints de una UI que el usuario est\u00e1 esperando, eso se nota.<\/p>\n

Workers: P50 de 2ms para cold starts. P95 de 7ms. El valor m\u00e1s alto que registr\u00e9 en todo el per\u00edodo de prueba fue 21ms, y fue un outlier claro en el gr\u00e1fico.<\/p>\n

Para ser honesto con Lambda: hay herramientas para mitigar todo esto. Provisioned Concurrency mantiene instancias calientes y pr\u00e1cticamente elimina los cold starts, pero tiene costo fijo por hora independiente del tr\u00e1fico. Para nuestra carga de trabajo \u2014 irregular, con picos diurnos y casi nada de madrugada \u2014 ese costo no se justificaba. SnapStart es la otra opci\u00f3n buena, pero es Java solamente.<\/p>\n

Lambda mejor\u00f3 los cold starts entre Node.js 18 y 20, y hay t\u00e9cnicas con pre-loading de m\u00f3dulos usando --import<\/code> que reducen el tiempo de inicializaci\u00f3n si te tomas el tiempo de configurarlo. Pero la diferencia con Workers sigue siendo de un orden de magnitud para cualquier funci\u00f3n sin provisioned concurrency.<\/p>\n

El L\u00edmite de CPU Que Nadie<\/a> Menciona Hasta que<\/a> te Explota en Producci\u00f3n<\/h2>\n

Ac\u00e1 viene la parte que quisiera haber le\u00eddo antes de migrar<\/a>, y el motivo por el que escrib\u00ed este post.<\/p>\n

Workers tiene un l\u00edmite de CPU time: 10ms en el plan free, 50ms en el plan paid. No es wall-clock time. Si tu funci\u00f3n hace await fetch(algunaApi)<\/code> y espera 300ms a una respuesta externa, eso no cuenta. Es tiempo de CPU puro: el tiempo que el hilo de JavaScript est\u00e1 activamente ejecutando c\u00f3digo.<\/p>\n

La mayor\u00eda de tutoriales mencionan este l\u00edmite en un p\u00e1rrafo peque\u00f1o con la nota de que “es suficiente para la mayor\u00eda de casos de uso”. T\u00e9cnicamente cierto. En la pr\u00e1ctica, m\u00e1s tramposo de lo que<\/a> suena.<\/p>\n

Migr\u00e9 nuestro endpoint de procesamiento de documentos a Workers. El endpoint recibe un JSON con hasta 200 registros, normaliza campos de texto con regex, calcula checksums y devuelve el resultado. En staging, con mis 10-20 registros de prueba, todo perfecto. Push a producci\u00f3n un viernes<\/a> por la tarde \u2014 s\u00e9, s\u00e9 \u2014 y a las<\/a> dos horas los logs empezaban a mostrar errores 1101.<\/p>\n

\/\/ workers\/process-documents.js \u2014 la versi\u00f3n que explot\u00f3 en prod\nexport default {\n  async fetch(request, env, ctx) {\n    const { records } = await request.json();\n\n    \/\/ Con 200 registros reales, este .map() consume ~70ms de CPU puro.\n    \/\/ El l\u00edmite es 50ms. El isolate muere a la mitad sin un error claro.\n    const results = records.map(record => ({\n      id: record.id,\n      normalized: normalizeFields(record),  \/\/ regex + string ops en varios campos\n      checksum: computeChecksum(record.data) \/\/ SubtleCrypto, operaci\u00f3n costosa\n    }));\n\n    return Response.json({ results });\n  }\n};\n<\/code><\/pre>\n
El error 1101 de Workers es un “Worker threw an exception” y los logs por defecto no te<\/a> dicen mucho m\u00e1s. Tard\u00e9 un par de horas en conectar los puntos. Lo que<\/a> me confundi\u00f3 al principio es que la funci\u00f3n fallaba en producci\u00f3n con<\/a> payloads grandes pero pasaba todos mis tests \u2014 porque mis fixtures de test eran peque\u00f1os.<\/p>\n
La soluci\u00f3n inmediata fue dividir el procesamiento en chunks m\u00e1s peque\u00f1os y ceder el event loop entre ellos:<\/p>\n
\/\/ workers\/process-documents.js \u2014 versi\u00f3n que s\u00ed funciona\nexport default {\n  async fetch(request, env, ctx) {\n    const { records } = await request.json();\n    const CHUNK_SIZE = 35; \/\/ ~8ms de CPU por chunk, bien dentro del l\u00edmite\n    const results = [];\n\n    for (let i = 0; i < records.length; i += CHUNK_SIZE) {\n      const chunk = records.slice(i, i + CHUNK_SIZE);\n\n      for (const record of chunk) {\n        results.push({\n          id: record.id,\n          normalized: normalizeFields(record),\n          checksum: await computeChecksum(record.data) \/\/ async ahora\n        });\n      }\n\n      \/\/ scheduler.wait(0) cede el event loop y resetea el contador de CPU time.\n      \/\/ Requiere compat_date: "2023-03-01" en wrangler.toml\n      if (i + CHUNK_SIZE < records.length) {\n        await scheduler.wait(0);\n      }\n    }\n\n    return Response.json({ results });\n  }\n};\n<\/code><\/pre>\n
Funciona. Pero ese endpoint no deber\u00eda estar en Workers \u2014 y esa es la lecci\u00f3n real. Es CPU-intensivo por naturaleza, y Workers est\u00e1 dise\u00f1ado para workloads donde el cuello de botella es la red, no el CPU. Lo mov\u00ed de vuelta a Lambda y no volv\u00ed a tener el problema. A veces la soluci\u00f3n correcta no es ajustar el c\u00f3digo sino cuestionar si est\u00e1s usando la herramienta correcta.<\/p>\n
D\u00f3nde Lambda Sigue Ganando Sin Discusi\u00f3n<\/h2>\n
Hay casos donde Lambda gana por razones estructurales que Workers no puede resolver, y despu\u00e9s de<\/a> cinco meses tengo claro cu\u00e1les son.<\/p>\n
El ecosistema de Node.js completo es el m\u00e1s obvio. Workers tiene un modo de compatibilidad (nodejs_compat<\/code> en wrangler.toml) pero no es paridad total. Tuve que reescribir fragmentos que usaban Buffer<\/code> de formas espec\u00edficas, y hay paquetes npm que simplemente no funcionan porque dependen de APIs de Node.js fuera del subset de Workers. Si tu codebase tiene dependencias profundas del ecosistema Node.js, Lambda es la \u00fanica opci\u00f3n que no implica reescribir dependencias de terceros.<\/p>\n
Los jobs de larga duraci\u00f3n son otro caso claro. Workers tiene un l\u00edmite de 30 segundos de wall-clock time en el plan est\u00e1ndar. Lambda llega a 15 minutos. Para exports de datos<\/a>, procesamiento de archivos pesados, o cualquier tarea que tome tiempo real, Workers simplemente no alcanza \u2014 aunque los Durable Objects pueden ser una soluci\u00f3n para ciertos patrones, no es lo<\/a> mismo.<\/p>\n
Y si tu stack ya vive en AWS \u2014 DynamoDB, SQS, EventBridge, Step Functions \u2014 la integraci\u00f3n es nativa y co-locada. Invocar DynamoDB desde un Worker en un datacenter de Cloudflare implica atravesar internet hasta la regi\u00f3n de AWS correspondiente. Med\u00ed ~18ms adicionales en promedio para calls a DynamoDB desde Workers vs desde Lambda co-locada en us-east-1. No es el fin del mundo, pero se suma cuando haces m\u00faltiples calls por request.<\/p>\n
La diversidad de runtimes tambi\u00e9n importa si tienes un equipo mixto. Lambda soporta Python, Java con SnapStart, Go, Rust v\u00eda custom runtime. Workers es JavaScript, TypeScript y WebAssembly. Si parte del equipo trabaja en Python para data processing, no hay discusi\u00f3n.<\/p>\n
Los N\u00fameros Reales y Mi Veredicto<\/h2>\n
Despu\u00e9s de cinco meses con ~25M requests\/mes en los endpoints migrados, los costos quedaron as\u00ed:<\/p>\n
Lambda (Node 20, 256MB, ~45ms de duraci\u00f3n promedio): unos $11-13\/mes dependiendo del tr\u00e1fico del mes. Requests y duration costs combinados, despu\u00e9s del free tier.<\/p>\n
Workers (plan Paid): $5 base con 10M requests incluidas, m\u00e1s $4.50 por los 15M adicionales. Total ~$9.50\/mes fijo y predecible.<\/p>\n
La diferencia existe pero no cambia vidas a esta escala. A vol\u00famenes mucho m\u00e1s altos \u2014 cientos de millones de requests \u2014 Workers escala m\u00e1s predeciblemente porque el costo de duraci\u00f3n de Lambda crece con el tiempo de ejecuci\u00f3n, mientras que Workers cobra por CPU time consumido. Si tus funciones pasan mucho tiempo esperando I\/O, Lambda cobra ese tiempo tambi\u00e9n.<\/p>\n
Honestamente, despu\u00e9s de<\/a> todo esto la decisi\u00f3n no es tan complicada. Workers gana cuando tus handlers son ligeros en CPU \u2014 autenticaci\u00f3n, routing, rate limiting, proxying de requests, respuestas desde cach\u00e9 \u2014 y cuando sirves usuarios distribuidos globalmente donde los cold starts te est\u00e1n afectando. Si ya apuestas por el ecosistema Cloudflare, R2, KV y Durable Objects se integran bien entre s\u00ed y tiene sentido<\/a> centralizar ah\u00ed. Lambda es la respuesta cuando tienes procesamiento CPU-intensivo, dependencias profundas en npm, necesitas m\u00faltiples runtimes o tu stack ya est\u00e1 integrado con servicios AWS. En esos casos no hay mucho que debatir.<\/p>\n
Nosotros terminamos con arquitectura mixta: Workers maneja el routing global, autenticaci\u00f3n JWT y respuestas desde Cloudflare KV; Lambda maneja el procesamiento de documentos, los jobs en background y todo lo que<\/a> toca DynamoDB directamente. Operacionalmente es un poco m\u00e1s complejo de mantener \u2014 dos sistemas de deploy, dos sets de observabilidad, dos modelos de debugging \u2014 pero es honesto con lo que<\/a> cada runtime hace bien.<\/p>\n
No soy 100% seguro de que esta separaci\u00f3n siga siendo la correcta conforme escalemos. Probablemente a mayor tama\u00f1o de equipo, el costo cognitivo de mantener dos runtimes distintos empiece a pesar m\u00e1s que los beneficios t\u00e9cnicos. Pero para donde estamos ahora, funciona mejor que tener todo en un solo lugar.<\/p>\n
<\/p>\n","protected":false},"excerpt":{"rendered":"
Llevamos cuatro a\u00f1os usando AWS Lambda en nuestro equipo.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"site-sidebar-layout":"default","site-content-layout":"","ast-site-content-layout":"default","site-content-style":"default","site-sidebar-style":"default","ast-global-header-display":"","ast-banner-title-visibility":"","ast-main-header-display":"","ast-hfb-above-header-display":"","ast-hfb-below-header-display":"","ast-hfb-mobile-header-display":"","site-post-title":"","ast-breadcrumbs-content":"","ast-featured-img":"","footer-sml-layout":"","ast-disable-related-posts":"","theme-transparent-header-meta":"","adv-header-id-meta":"","stick-header-meta":"","header-above-stick-meta":"","header-main-stick-meta":"","header-below-stick-meta":"","astra-migrate-meta-layouts":"default","ast-page-background-enabled":"default","ast-page-background-meta":{"desktop":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"ast-content-background-meta":{"desktop":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"footnotes":""},"categories":[1],"tags":[],"class_list":["post-497","post","type-post","status-publish","format-standard","hentry","category-general"],"_links":{"self":[{"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/posts\/497","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/comments?post=497"}],"version-history":[{"count":11,"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/posts\/497\/revisions"}],"predecessor-version":[{"id":772,"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/posts\/497\/revisions\/772"}],"wp:attachment":[{"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/media?parent=497"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/categories?post=497"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/tags?post=497"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}