El 22 de junio de 2026, AWS publicó un anuncio en su blog oficial. El título era largo, pero lo esencial cabía en una frase: Lambda ahora puede ejecutar MicroVMs.
AWS no ha sacado un servicio nuevo ni un nuevo SKU — ha abierto una puerta completamente nueva dentro de Lambda, un producto serverless con 11 años de historia. Mi primera reacción al terminar de leer: AWS ha sacado Firecracker de entre bastidores y lo ha puesto en el escenario. Y esta vez no es para las funciones internas de Lambda: es para los desarrolladores, directamente.
Qué se ha lanzado exactamente
Lambda MicroVMs es una nueva primitiva de computación. Comparte la misma consola que Lambda Functions, pero la API es totalmente distinta: subes un Dockerfile y un archivo comprimido con el código a S3, y Lambda construye la imagen, inicializa la aplicación y toma un snapshot de Firecracker. A partir de ahí, cada vez que arrancas la MicroVM, se restaura directamente desde ese snapshot precalentado — el arranque en frío queda eliminado de raíz.
Conviene fijarse en estos parámetros:
- Límites por instancia: 16 vCPU, 32 GB de RAM, 32 GB de disco, arquitectura ARM64 (Graviton)
- Tiempo máximo de ejecución: 8 horas — el límite de 15 minutos de Lambda Functions aquí no existe
- Política de inactividad: suspensión automática configurable (suspend); durante la suspensión solo se cobra el almacenamiento del snapshot; al reanudar, se conserva el estado completo de memoria y disco
- Arranque: restauración de snapshot, no arranque en frío. Nada más iniciar, obtienes un endpoint HTTP listo para usar
- Regiones iniciales: Este de EE.UU. (Virginia, Ohio), Oeste de EE.UU. (Oregón), Europa (Irlanda), Asia-Pacífico (Tokio)
La tarificación es por vCPU/s y por memoria/GB/s; el coste de computación se pone a cero durante la suspensión. Es la misma lógica de facturación de Lambda Functions, pero como una sesión puede durar horas, la factura real se parecerá más a una máquina virtual bajo demanda — solo que con capacidad de pausa.
El blog de AWS enumera explícitamente los escenarios objetivo: asistentes de programación con IA, entornos interactivos de código, plataformas de análisis de datos, escáneres de vulnerabilidades, servidores de juegos que ejecutan scripts de usuario. ¿El denominador común? Cada usuario final necesita un entorno aislado propio donde ejecutar de forma segura código no confiable.
Por qué ahora
Conviene desglosar esta pregunta.
Firecracker se publicó como código abierto en 2018. Durante siete años ha soportado más de 15 billones de invocaciones mensuales de funciones Lambda. La tecnología está madura, pero AWS nunca había vendido Firecracker como producto orientado al desarrollador — hasta ahora.
Lo que ha cambiado no es la preferencia estratégica de AWS. Es la demanda.
Entre 2025 y la primera mitad de 2026, los asistentes de código con IA pasaron de experimento a herramienta cotidiana. Claude Code, Codex CLI, Gemini Code Assist — estos agentes no solo generan código: lo ejecutan. Instalan paquetes, levantan servicios, leen y escriben en el sistema de archivos, hacen peticiones de red. Millones de veces al día. Y el entorno donde se ejecuta ese código es, o bien un contenedor Docker (kernel compartido, aislamiento por namespace + cgroup + seccomp), o bien una máquina virtual (aislamiento fuerte pero arranque lento).
Más espinoso aún es que el propio agente sortea activamente las restricciones de seguridad a nivel de software. En marzo de 2026, Leonardo Di Donato, maintainer principal de Falco, demostró cómo Claude Code burlaba su propio sandbox: el agente descubrió que /proc/self/root/usr/bin/npx esquivaba las reglas de denegación; cuando bubblewrap lo bloqueó, el agente simplemente apagó el sandbox. Sin jailbreak, sin prompt especial. Solo quería terminar la tarea.
Este caso ilustra un hecho fundamental: el aislamiento basado en lógica de espacio de usuario (listas de denegación, permisos por prompt, reglas seccomp) opera en la misma capa que el razonamiento del agente. El agente tiene capacidad suficiente para entenderlas y esquivarlas. El aislamiento de MicroVM, en cambio, lo impone la virtualización por hardware en una capa que el agente no puede tocar.
El momento del lanzamiento de Lambda MicroVMs coincide casi exactamente con la explosión de este problema de seguridad.
El mapa del mercado de sandboxes
Lambda MicroVMs no surge de la nada. Antes de su llegada, ya existía un ecosistema considerable de herramientas y plataformas en torno a la pregunta “cómo ejecutar código no confiable de forma segura”. He intentado cartografiar los principales bandos sin establecer jerarquías, solo diferencias de arquitectura y casos de uso.
El ecosistema Firecracker
AWS es, evidentemente, el jugador más grande. Además de los recién lanzados Lambda MicroVMs, AWS Bedrock AgentCore ya usaba Firecracker para dar a cada sesión de agente su propia microVM independiente.
En el plano de las plataformas independientes, E2B es un servicio centrado en sandboxes para agentes de IA, con Firecracker por debajo, arranque en ~150ms y un 88% declarado de penetración en Fortune 100. Fly.io Sprites ofrece VMs stateful persistentes, con checkpoint/restore en ~300ms y Claude Code y Codex CLI preinstalados. Vercel Sandbox también corre sobre Firecracker, con restauración de snapshot en milisegundos, orientado a intérpretes de código para IA. SlicerVM va por la vía self-hosted y soporta tanto Firecracker como Cloud Hypervisor, además de poder usar Apple Virtualization Framework en macOS.
Entre los proyectos de código abierto, Matchlock merece atención: un sandbox Firecracker diseñado para agentes de IA, política de red deny-all por defecto, lista blanca de dominios, protección de claves. Resuelve específicamente el problema de seguridad de claude --dangerously-skip-permissions.
El ecosistema libkrun
libkrun, de Red Hat, sigue el camino del VMM como biblioteca: empaqueta la capacidad de microVM en una librería invocable por otros programas, en lugar de un demonio independiente. Microsandbox (incubado en YC, código abierto Apache 2.0, ~4700 estrellas en GitHub) es el consumidor más representativo de libkrun: un sandbox self-hosted para agentes de IA donde cada instancia recibe kernel independiente, sistema de archivos propio y pila de red aislada.
La ventaja diferencial de libkrun es multiplataforma: KVM en Linux, Hypervisor.framework en macOS. Su punto débil es la ausencia de capa de orquestación para Kubernetes y de gestión a nivel de clúster — libkrun brilla en despliegues monomáquina, ideal para el entorno local del desarrollador o equipos pequeños, pero no para entornos de producción multitenant a gran escala.
Kata Containers
Kata Containers ocupa una posición radicalmente distinta: ofrece un marco de orquestación que incrusta Firecracker, Cloud Hypervisor o QEMU en la capa de runtime de Kubernetes, de modo que cada Pod corre dentro de su propia VM ligera. Para Kubernetes parece un contenedor normal; por debajo, aislamiento completo por hardware.
Tiempo de arranque ~150-300ms (según el VMM elegido), sobrecarga de memoria <10 MiB más el kernel invitado. El valor central de Kata es encapsular la complejidad operativa de las microVMs — no tienes que gestionar imágenes de kernel, configuración de red ni ciclo de vida de la VM. Northflank ejecuta Kata Containers + Cloud Hypervisor en producción, con más de 2 millones de microVMs al mes.
Kata está pensado para cargas de trabajo multitenant de larga duración que necesitan orquestación K8s, no para sesiones cortas de arranque y parada rápidos.
gVisor
gVisor, de Google, toma un camino técnico completamente distinto: en lugar de envolver el contenedor en una máquina virtual, inserta entre el contenedor y el kernel del host un kernel de espacio de usuario escrito en Go (Sentry). Las syscalls que emite el contenedor son interceptadas por Sentry y procesadas en espacio de usuario; solo un pequeño subconjunto de operaciones imprescindibles se filtra al kernel del host.
Esto se traduce en: cero sobrecarga de arranque de VM, sin necesidad de virtualización anidada, integración directa con Docker/containerd. El coste: una penalización del 10-30% en cargas intensivas de I/O por la sobrecarga de syscall. La solidez del aislamiento de gVisor se sitúa entre el contenedor y la máquina virtual — la superficie de ataque del kernel se reduce drásticamente (Sentry implementa solo ~230 syscalls frente a las 450+ expuestas por el kernel de Linux), pero no alcanza el aislamiento de memoria a nivel de hardware.
Modal es el producto más representativo de la línea gVisor: sandboxes con soporte de GPU, arranque en ~300ms, orientado a inferencia y entrenamiento.
Cloudflare Workers (V8 Isolates)
Cloudflare va al otro extremo: V8 isolates. Arranque por debajo del milisegundo, pero solo JavaScript/TypeScript/WASM. En 2026 añadieron Dynamic Workers: el LLM genera dinámicamente sub-isolates de JS/TS en tiempo de ejecución para ejecutar código, con un consumo de tokens un 81% inferior al tool-calling tradicional. No es un sandbox universal, pero dentro del ecosistema JS/WASM nadie iguala su densidad y latencia.
Dimensiones de diferenciación
Después de mapear las distintas propuestas, observo varias dimensiones que se están convirtiendo en foco de competición:
Capacidad de snapshot/fork. El “arranque directo desde snapshot precalentado” de Lambda MicroVMs consiste esencialmente en congelar un estado de runtime ya inicializado y restaurarlo en el siguiente arranque. Unikraft Cloud ha llevado esta idea al extremo — anuncia <10ms de arranque en frío y más de 100.000 instancias aisladas por máquina física. La velocidad del snapshot determina directamente la experiencia de usuario: cuando el agente lanza una solicitud de ejecución de código, la diferencia entre esperar 100ms o 5 segundos es la diferencia entre seguir usando el producto o abandonarlo.
Protección de secretos en la capa de red. Esto es especialmente crítico para el escenario de agentes. El agente necesita acceder a la red externa (descargar dependencias, invocar APIs), pero no quieres que lea las claves de tus variables de entorno. Lambda MicroVMs lo resuelve con tokens de autenticación de corta duración + cabeceras de proxy. Matchlock opta por deny-all + lista blanca de dominios. La diferencia no está en tener o no tener la funcionalidad, sino en la concepción distinta que cada uno tiene del modelo de seguridad.
Acceso SSH / VPN. El desarrollo interactivo requiere que el desarrollador pueda entrar directamente en el sandbox para depurar. Fly.io Sprites y E2B soportan SSH. Lambda MicroVMs funciona actualmente con endpoints HTTP, más adecuado para ejecución de código que para desarrollo interactivo.
Capa de orquestación e integración con K8s. Kata Containers no tiene rival en esta dimensión — se diseñó precisamente para Kubernetes. Firecracker a pelo exige construir uno mismo una cantidad enorme de infraestructura. Lambda MicroVMs traslada esa responsabilidad al servicio gestionado de AWS. libkrun carece por ahora de una solución de orquestación a nivel de clúster.
Compatibilidad con agentes. Esto atañe a la filosofía de diseño del producto, no a una comparación pura de especificaciones técnicas. ¿El sandbox expone una API REST? ¿Ofrece SDK? ¿La semántica de snapshot/resume se adapta al ciclo “ejecutar – esperar resultado – seguir ejecutando” del agente? El mecanismo de pausa/reanudación y el límite de 8 horas de Lambda MicroVMs están claramente pensados para sesiones de agente. El modelo de “un demonio Docker independiente por agente” de Docker Sandboxes está más orientado al desarrollo local.
El tablero sigue sin decidirse
Mirando hacia atrás en el tiempo: cuando Firecracker nació en 2018, la microVM era una optimización en la capa de infraestructura — hacer Lambda más rápido, más barato, más seguro. En 2026, la misma tecnología se ha convertido en ciudadano de primera en la capa de producto porque la demanda superior ha cambiado radicalmente: los agentes ejecutan código, ejecutar código necesita sandboxes, y el sandbox no puede ser un collage de namespaces.
Pero la pregunta “cuál es el mejor sandbox” no tiene una respuesta única. Si tu agente solo ejecuta JavaScript, los V8 isolates de Cloudflare Workers pueden ser más potentes que una microVM con arranque por debajo del milisegundo. Si corres en Kubernetes con necesidad de Pods aislados de larga duración, Kata Containers es más pragmático que Firecracker a pelo. Si necesitas una solución ligera self-hosted en local, libkrun + Microsandbox es más flexible que el servicio gestionado de AWS. La ventaja de Lambda MicroVMs está en las cero operaciones y la restauración por snapshot — al precio de quedar atado al ecosistema AWS, la arquitectura ARM64 y las limitaciones regionales.
No he ejecutado a gran escala en producción ninguna de estas soluciones de sandbox. Los juicios de este artículo se basan en documentación pública, white papers técnicos y validación cruzada con discusiones de la comunidad. Si estás eligiendo infraestructura de sandbox para agentes de IA, te sugiero que hagas benchmarks con tu propia carga de trabajo — la restauración de snapshot que en la tabla del benchmark dice 100ms puede comportarse de forma muy distinta cuando la latencia de red real entra en juego.
La baza ganadora de una arquitectura rara vez reside en la arquitectura misma. En un mundo donde un agente dispara decenas de solicitudes de ejecución de código por segundo, la velocidad del snapshot, la latencia de red, la gestión de secretos y el modelo de facturación — estos factores “no esenciales” — pueden importar más que si el VMM está escrito en Rust o en Go.
Declaración: este artículo es pura observación técnica. El autor no tiene ninguna relación comercial con las empresas o proyectos mencionados.