Un agente de IA cada vez «hace» más y «dice» menos: genera código y lo ejecuta para resolver un cálculo, transformar un archivo o montar un análisis. Pero ahí aparece un problema incómodo: ¿dónde ejecuta ese código? Si lo corre dentro de su propio entorno, ese código —que el agente acaba de escribir y nadie ha revisado— puede tocar credenciales, memoria y datos que no debería. El 22 de junio de 2026, AWS presentó Lambda MicroVMs, una pieza pensada justo para eso: dar a cada usuario, sesión o agente su propio entorno aislado donde ejecutar código sin poner en riesgo el resto. En esta guía verás qué es, para qué sirve, cuándo usarlo frente a otras opciones y qué no resuelve.
En resumen
- AWS Lambda MicroVMs es una nueva primitiva de cómputo serverless para ejecutar código generado por usuarios o por IA en entornos aislados y con estado.
- Usa Firecracker, la misma tecnología de virtualización ligera que ya mueve billones de invocaciones de Lambda al mes.
- Ofrece aislamiento a nivel de máquina virtual, arranque y reanudación casi instantáneos, y conserva el estado hasta 8 horas.
- No sustituye a las funciones Lambda de siempre: resuelve un problema distinto y se complementan.
El problema: dónde ejecuta un agente el código que genera
Cuando construyes una aplicación en la que se ejecuta código que tú no escribiste —el script que pega un usuario, el snippet que genera un agente, la dependencia de un pull request— te topas siempre con la misma pregunta: cómo correrlo sin entregarle a un desconocido las llaves de la casa. Hasta ahora había tres caminos y cada uno con su pega: una máquina virtual da aislamiento fuerte pero tarda minutos en arrancar; un contenedor arranca en segundos pero comparte el núcleo del sistema, así que ejecutar código no fiable exige mucho blindaje; y una función Lambda es segura y rápida pero no guarda estado y tiene un máximo de 15 minutos.
Ese es el hueco que AWS dice cubrir con los MicroVMs: aislamiento de máquina virtual, arranque rápido y sesiones con estado, las tres cosas a la vez.
Qué son los AWS Lambda MicroVMs
Según AWS, cada sesión se ejecuta en su propio MicroVM, sin núcleo ni recursos compartidos con otras sesiones. Eso significa que el código no fiable de un usuario queda contenido en su propio entorno, sin acceso a los de los demás ni al sistema subyacente. El aislamiento lo aporta Firecracker, la misma virtualización ligera que sostiene una enorme parte del tráfico de Lambda.
Lo interesante para tareas largas es el estado. Un MicroVM puede quedarse inactivo, suspenderse —guardando su memoria y disco en una instantánea— y, cuando llega una nueva petición, reanudarse con todo intacto. Desde el lado del cliente, la pausa ni se nota. El estado se conserva hasta ocho horas, y tú controlas el ciclo de vida: lanzar, suspender, reanudar y terminar cuando quieras.
Para qué sirve
AWS lo orienta a aplicaciones donde cada usuario o sesión necesita su propio entorno para ejecutar código que no escribió el desarrollador. Entre los casos que menciona:
- Sandboxes para código generado por IA: entornos efímeros donde un agente ejecuta el código que produce, de forma segura.
- Entornos de código interactivos: espacios donde la persona escribe y ejecuta código en tiempo real.
- Plataformas de análisis de datos: cuadernos y procesamiento que ejecutan scripts proporcionados por el usuario.
- Escaneo de seguridad: herramientas que inspeccionan paquetes o binarios sospechosos en aislamiento.
- CI/CD multiinquilino y entornos de aprendizaje por refuerzo para evaluar y entrenar agentes, levantando un entorno limpio en cada ejecución.
MicroVMs frente a funciones Lambda y a AgentCore
Conviene no confundirlos, porque resuelven cosas distintas:
- Funciones Lambda: siguen siendo la opción correcta para cargas event-driven de petición y respuesta. No guardan estado y tienen el límite de 15 minutos. Una aplicación puede usar funciones para su columna vertebral y llamar a un MicroVM solo para los pasos que necesitan ejecutar código aislado.
- AgentCore Runtime: también se apoya en Firecracker y admite hasta 8 horas, pero es una plataforma gestionada de agentes, más acotada en lo que puedes hacer dentro. Los MicroVMs, en cambio, te dan la máquina completa con acceso de shell. La analogía que se ha usado: AgentCore es a los MicroVMs lo que Fargate es a EC2.
La regla práctica: si necesitas un entorno con estado, runtime a medida y aislamiento más fuerte que el de un contenedor compartido, el MicroVM encaja; si tu carga es un disparo rápido sin estado, la función Lambda sigue ganando.
Cómo encaja con agentes Claude
AWS ha publicado una guía y un ejemplo para usar MicroVMs como sandbox de agentes gestionados de Anthropic Claude: el ejemplo lanza un MicroVM por cada sesión del agente desde un plano de control en tu propia cuenta de AWS. Es una buena validación del patrón, pero también deja clara la frontera de responsabilidad: la verificación de webhooks, los secretos, la construcción de imágenes, la política de red, la monitorización y la limpieza siguen siendo tu trabajo de plataforma.
Lo que NO resuelve (y conviene tener en cuenta)
- No es un modelo de seguridad completo por sí solo. El MicroVM aísla la ejecución, pero tu sandbox seguramente necesite acceso de red a otros recursos, y eso hay que gobernarlo aparte. La pregunta de revisión es simple: ¿qué puede alcanzar este MicroVM y bajo qué autoridad?
- Sigues gestionando el ciclo de la imagen. El arranque rápido viene de una instantánea preinicializada, así que tu entorno tiene su propio ciclo de versiones: dependencias, parches del sistema, runtimes y certificados necesitan versionado y reversión.
- Cuidado con lo que se genera en la construcción. Como todos los MicroVMs parten de la misma instantánea, lo que crees en tiempo de construcción (identificadores únicos, secretos, semillas aleatorias, conexiones) se comparte entre todos. Lo que deba ser único por sesión hay que generarlo en el arranque de cada MicroVM, no antes.
- Disponibilidad acotada. En el lanzamiento está en un conjunto limitado de regiones (Norte de Virginia, Ohio, Oregón, Irlanda y Tokio) y sobre arquitectura ARM64 (Graviton), con un máximo por MicroVM de 16 vCPU, 32 GB de memoria y 32 GB de disco.
Cómo se paga
El cobro es por segundo de uso (vCPU, memoria, almacenamiento de la instantánea y transferencia de datos). La clave para el bolsillo en cargas interactivas: cuando el MicroVM se suspende, cesan los cargos de cómputo y solo pagas el almacenamiento de la instantánea. Es decir, no pagas por entornos «zombi» mientras el usuario piensa o está ausente.
Conclusión
Los Lambda MicroVMs llegan en un momento muy concreto: el de los agentes que ejecutan código y necesitan un sitio seguro donde hacerlo. Su combinación de aislamiento de máquina virtual, arranque rápido y estado durante horas cubre un hueco real que antes obligaba a elegir entre seguridad, velocidad o persistencia. Eso sí, quitan trabajo de infraestructura, no la responsabilidad: sigues decidiendo qué puede alcanzar cada entorno, cómo gestionas imágenes y secretos, y cuándo limpiar. Como con cualquier pieza nueva, lo sensato es probarlo en un caso acotado y medir antes de construir sobre ello en producción.
Artículo elaborado por Daniel Bellido. Para escribirlo se han contrastado los anuncios oficiales de AWS; cuando se citan datos, proceden de AWS.
Preguntas frecuentes
¿Qué son los AWS Lambda MicroVMs?
Una primitiva de cómputo serverless de AWS que da a cada usuario, sesión o agente un entorno aislado, con estado y basado en Firecracker para ejecutar código generado por usuarios o por IA sin gestionar infraestructura de virtualización.
¿En qué se diferencian de las funciones Lambda normales?
Las funciones Lambda son para cargas de petición y respuesta, sin estado y con un máximo de 15 minutos. Los MicroVMs son para sesiones interactivas y con estado que pueden durar hasta 8 horas, suspenderse y reanudarse. Se complementan.
¿Sirven para ejecutar el código que genera un agente de IA?
Sí, es uno de sus casos principales: dar al agente un entorno aislado por sesión donde ejecutar el código que produce, sin que ese código acceda al estado del propio agente ni al de otros usuarios. AWS incluso publica una guía para usarlos como sandbox de agentes de Anthropic Claude.
¿Garantizan por sí solos la seguridad?
No. Aíslan la ejecución, pero el control de red, los secretos, la gestión de imágenes y la limpieza siguen siendo responsabilidad de quien construye la plataforma.
¿Dónde están disponibles y cuánto cuestan?
En el lanzamiento, en un conjunto limitado de regiones (Norte de Virginia, Ohio, Oregón, Irlanda y Tokio) y sobre ARM64. El cobro es por segundo de uso; cuando el MicroVM se suspende, cesan los cargos de cómputo.
¿Cuándo se anunciaron?
AWS los presentó el 22 de junio de 2026.
Fuentes
- Blog oficial de AWS: AWS Lambda introduce los MicroVMs
- Documentación de AWS: guía de Lambda MicroVMs
