Benchmarking Cloudflare Containers vs AWS MicroVMs

En pocas palabras: En el benchmark de Alchemy del 1 de julio de 2026 (700 arranques, 16 variantes), ganó AWS: sus MicroVMs sobre Firecracker levantaron en 3-4 segundos, mientras que los Cloudflare Containers tardaron entre 10 y casi 60 segundos en responder el primer request.

Alchemy publicó el 1 de julio de 2026 un benchmarking de Cloudflare Containers vs AWS MicroVMs sobre arranques en frío, y el resultado sorprende: 700 boots, 16 variantes, y ganó AWS. Los MicroVMs arrancaron en 3 a 4 segundos parejos. Los containers de Cloudflare tardaron de 10 a casi 60 segundos.

El benchmarking de Cloudflare Containers vs AWS MicroVMs es una prueba de latencia de cold start hecha por Alchemy (empresa de infraestructura como código para el ecosistema Cloudflare Workers). Midió cuánto tarda cada plataforma en levantar una instancia fresca hasta que responde un request real. Los MicroVMs son máquinas virtuales livianas sobre Firecracker; los Containers de Cloudflare corren sobre su red edge global.

Cloudflare es una plataforma de infraestructura y seguridad web fundada en 2009 que proporciona servicios de CDN, DNS, protección DDoS y cómputo distribuido. Opera una red global de centros de datos para optimizar la velocidad y seguridad de aplicaciones web.

¿Qué midió el benchmark de Alchemy?

Alchemy midió el tiempo de cold start hasta servicio usable: bootear una instancia fresca, esperar a que respondiera un request real, anotar el tiempo, destruirla y repetir. Fueron 700 boots en 16 variantes, según el informe de Alchemy (2026). Un boot cuenta como listo recién cuando el server contesta su health check.

El detalle importante: no midieron ping ni “encendió la lucecita”. Midieron cuándo la cosa realmente atiende.

Eligieron dos workloads. Uno es opencode, un agente de código popular que corre como proceso local, pesa cerca de 100 MB y tiene latencia de arranque real. Es justo el tipo de cosa que meterías en un sandbox por usuario. El otro es un “hello world” mínimo, que sirve de piso: si algo tarda con un hello world, no hay app que lo salve.

Y acá está lo picante: los MicroVMs se arrancaron cross-cloud, por la API pública de AWS, desde fuera del datacenter. Los Containers de Cloudflare corrieron en su casa. Aun con esa desventaja de red para AWS, el resultado no se dio vuelta. Tema relacionado: gestión segura de secretos.

¿Qué dice el benchmarking de Cloudflare Containers vs AWS MicroVMs sobre la latencia?

La latencia de cold start fue mejor y más estable en AWS. Para opencode, el AWS MicroVM levantó en 3,4 segundos de mediana y ninguno de sus boots superó los 4,5 segundos, tanto vía Lambda como vía Worker. El Cloudflare Container, en cambio, tuvo dos tercios de sus boots por encima de 10 segundos, con outliers que llegaron a 58,6 segundos. Esa cola larga es el problema real.

Variante (opencode)	Mediana	Pico máximo
AWS MicroVM (Lambda)	3,4 s	≤ 4,5 s
AWS MicroVM (Worker)	3,4 s	≤ 4,5 s
Cloudflare Container (Worker)	2/3 > 10 s	58,6 s

Mirá los picos de la última fila. Un usuario que espera 3 segundos abre la app y sigue. Uno que a veces espera 45 o 58 segundos cree que se colgó todo. La mediana no cuenta esa historia; la cola sí.

En el hello world la brecha se achica, pero no se da vuelta. AWS mantuvo el mismo comportamiento parejo tanto con la app pesada como con la liviana. Eso es lo que más llama la atención del estudio: la consistencia de AWS casi no depende del tamaño del workload.

¿Por qué los AWS MicroVMs son más consistentes que Cloudflare?

Los AWS MicroVMs son más consistentes porque capturan el estado de memoria en tiempo de build. Pagás el costo de arranque una sola vez, cuando se arma el snapshot, y después cada instancia resume desde ese estado congelado. Cloudflare, con su modelo on-demand, rearma parte del laburo en cada cold start bajo carga real, y ahí aparece la cola impredecible de 1 a 60 segundos.

Ponele que tenés un agente de código de 100 MB. Con snapshot, ese arranque caro ya quedó resuelto de antemano. Sin snapshot, cada instancia nueva tiene que hacer parte de ese trabajo otra vez, y cuando el sistema está bajo presión, esa parte se estira. Relacionado: opciones de almacenamiento en la nube.

¿Es Cloudflare “malo”? No. Es que tres segundos consistentes y cuarenta y cinco segundos ocasionales son dos productos distintos para el usuario, aunque el promedio te diga que están cerca.

¿Qué diferencia hay entre V8 isolates y Firecracker microVMs?

Los V8 isolates arrancan en menos de 5 ms; los Firecracker microVMs parten de unos 125 ms base más el restore del snapshot. Cloudflare Workers usa isolates: contextos livianos dentro de un mismo runtime, sin VM completa. AWS usa Firecracker, la tecnología de virtualización liviana que también corre por debajo de Lambda. Son dos filosofías de aislamiento, y cada una paga un precio distinto.

El isolate es imbatible en velocidad pura cuando el workload es chico. El tema es que el modelo de isolates de Cloudflare tiene fricción para escalar con procesos grandes tipo un agente de 100 MB, que es justo donde el benchmark lo pescó flojo.

Del otro lado, AWS metió snapshots para tapar el costo de arranque de Firecracker. Con AWS Lambda SnapStart el restore puede caer a 15 a 20 ms. Ese es el truco que hace competitivo a un microVM contra un isolate: no arrancás de cero, resumís.

¿Cuándo conviene Cloudflare Containers y cuándo AWS MicroVMs?

Depende de qué te duele más: la latencia global o la variabilidad. Cloudflare brilla cuando querés que el cómputo esté cerca del usuario en cualquier parte del mundo y el workload es simple. AWS gana cuando necesitás arranques predecibles, estado en memoria preservado o cargas complejas y pesadas.

Elegí Cloudflare Containers si…

• Necesitás latencia global baja: tareas cortas cerca del usuario, como transformar una imagen en el edge o responder un endpoint liviano en milisegundos.
• El workload es simple: poca memoria, poco disco, sin dependencias pesadas que estiren el arranque.
• Ya vivís en Workers: si tu app está armada sobre Durable Objects y bindings, la integración es directa.

Elegí AWS MicroVMs si…

• La consistencia es innegociable: preferís 3 segundos siempre antes que 1 segundo a veces y 45 otras.
• Corrés cargas complejas: un sandbox por usuario con un agente de código, o cualquier proceso que pese decenas o cientos de MB.
• Necesitás preservar estado en memoria: el snapshot te deja resumir en vez de reinicializar todo.

Si tu producto es para clientes de Latinoamérica y buscás hosting o infraestructura web administrada acá, mirá también donweb.com para la parte de dominios y servidores en Argentina, y dejá el edge global para las piezas que de verdad lo necesitan.

¿Qué es el snapshot restore y cómo mejora el rendimiento?

El snapshot restore captura el estado completo de memoria y filesystem de una instancia ya inicializada, y después la resume desde ahí en vez de arrancarla de cero. Con SnapStart, ese resume puede bajar a 15 a 20 ms. La diferencia clave: AWS es snapshot-based (guarda el estado), mientras que Cloudflare tira más al modelo stateless on-demand. Más contexto en optimizar pipelines de despliegue.

La jugada más nueva de acá son los AWS Lambda MicroVMs, que suman snapshots persistentes como opción. La promesa es preservar el estado entre invocaciones sin repetir el arranque caro cada vez.

Pensalo así: arrancás una app, la dejás lista, sacás una foto de esa memoria y guardás la foto. La próxima vez no volvés a cocinar, servís el plato ya hecho. Ese es todo el truco, y explica por qué los microVMs con snapshot le pelean de igual a igual a algo tan liviano como un isolate.

¿Qué impacto real tienen los cold starts en la experiencia?

El impacto real no está en el promedio, está en la variabilidad. Los usuarios toleran bien 3 segundos consistentes; se frustran con la variabilidad, ese 45 ocasional que rompe la percepción de que la cosa “anda”. Un cold start importa mucho en APIs públicas, webhooks y agentes serverless, y casi nada en batch jobs o tareas de fondo.

Cualquiera que haya puesto un endpoint serverless en producción conoce la escena: subís el servicio, lo probás en local, anda joya, lo mandás a prod, y el primer request después de un rato de inactividad se cuelga tanto que el usuario recarga tres veces antes de que responda. Ese primer request lento es el cold start mordiendo.

¿Y dónde no te importa? En un job que corre a las 3 de la mañana y le nadie le mira el reloj. Si tu carga es asincrónica, la cola de 58 segundos es ruido estadístico, no un problema de negocio. Cubrimos ese tema en detalle en elegir entre herramientas CI/CD.

Errores comunes al comparar cold starts

• Mirar solo la mediana: el p50 puede verse lindo mientras el p99 te arruina la experiencia. En este benchmark, la mediana de Cloudflare era manejable, pero el pico de 58,6 segundos es lo que el usuario recuerda. Mirá siempre la cola.
• Testear con un “hello world” y creer que representa tu app: tu agente de 100 MB no arranca como un endpoint que devuelve texto. El error clásico es benchmarkear liviano y desplegar pesado.
• Ignorar el estado en memoria: si tu app inicializa un modelo, una conexión o un cache al arrancar, un modelo stateless te hace pagar esa inicialización una y otra vez. Ahí el snapshot no es un lujo, es la diferencia entre usable y no usable.
• Confundir latencia de red con cold start: el edge global reduce la distancia al usuario, pero no arregla un arranque lento. Son dos métricas distintas y conviene medirlas por separado.

Preguntas Frecuentes

¿Cuáles fueron los resultados del benchmark entre Cloudflare Containers y AWS MicroVMs?

AWS MicroVMs ganó en velocidad y consistencia. Para opencode, arrancaron en 3,4 segundos de mediana y ninguno superó los 4,5 segundos; los Cloudflare Containers tuvieron dos tercios de sus boots por encima de 10 segundos y picos de 58,6 segundos. El benchmark de Alchemy corrió 700 boots en 16 variantes el 1 de julio de 2026.

¿Cuánto demora un cold start en Cloudflare vs AWS en 2026?

Con un workload pesado tipo agente de código, AWS MicroVM ronda los 3 a 4 segundos parejos, mientras que Cloudflare Container va de 10 a casi 60 segundos según la carga del sistema. La diferencia grande no es la mediana, es la cola larga e impredecible de Cloudflare.

¿Qué diferencia hay entre V8 isolates y Firecracker microVMs?

Los V8 isolates arrancan en menos de 5 ms pero cuestan escalar con procesos grandes; los Firecracker microVMs parten de 125 ms base más el restore del snapshot. Cloudflare usa isolates, AWS usa Firecracker con snapshots que bajan el resume a 15 a 20 ms con SnapStart.

¿Cuándo conviene usar Cloudflare para aplicaciones serverless?

Cloudflare conviene cuando necesitás latencia global baja para tareas cortas y simples cerca del usuario, como transformar imágenes en el edge o servir endpoints livianos. Para cargas pesadas o donde la consistencia del arranque es crítica, los AWS MicroVMs rinden mejor según el benchmark de Alchemy.

¿Qué son los AWS Lambda MicroVMs?

Son una opción de AWS que agrega snapshots persistentes a los microVMs de Firecracker. Permiten preservar el estado de memoria entre invocaciones y resumir sin repetir el arranque caro, lo que explica la consistencia que mostraron en la prueba.

Conclusión

El benchmark de Alchemy cambia una intuición que muchos dábamos por hecha: que Cloudflare, jugando de local en su edge, iba a ganarle a AWS arrancado por API pública desde afuera. No pasó. Con opencode, los MicroVMs fueron más rápidos (3 a 4 segundos) y muchísimo más predecibles que los Containers, que se estiraron hasta casi un minuto.

La lección práctica: para sandboxes por usuario y cargas pesadas donde el cold start se nota, elegí snapshots. Para tareas chicas y globales, el edge de Cloudflare sigue teniendo sentido. Y si vas a decidir con datos, medí tu propio workload, mirá el p99, no el promedio, y no confíes en el hello world.

Fuentes

• Alchemy – Benchmarking Cloudflare Containers vs AWS MicroVMs (1 de julio de 2026)
• Cloudflare – Comparación de performance serverless: Workers vs Lambda
• AWS – Anuncio de Lambda MicroVMs y SnapStart
• TechBytes – MicroVM snapshots vs V8 isolates en serverless (2026)
• Upstash – AWS Lambda vs Cloudflare Workers