AWS lanza Lambda MicroVMs para aislar agentes de IA en sesiones

AWS convierte Lambda en un sandbox por sesión para agentes de IA

AWS presentó AWS Lambda MicroVMs, una nueva primitiva de cómputo serverless dentro de Lambda pensada específicamente para ejecutar código generado por usuarios o por agentes de IA dentro de entornos aislados. La promesa: cada sesión obtiene su propia micro-máquina virtual con aislamiento por hardware, sin tener que aprovisionar ni mantener infraestructura. La arquitectura llega en un momento en que Anthropic, OpenAI y varios proveedores de modelos están lidiando con incidentes donde agentes escaparon de sus sandboxes y toparon con sistemas fuera de scope.

El recurso clave es Firecracker, la tecnología de virtualización ligera que AWS usa internamente desde hace casi una década para correr las funciones de Lambda; el mismo motor ya procesa «trillones de llamadas cada mes» según reportó Ad-Hoc News. Lambda MicroVMs lleva esa base a una API dedicada para casos donde se necesita estado persistente y aislamiento de sesión-a-sesión.

Qué cambia frente a las funciones Lambda tradicionales

Lambda Functions están diseñadas para cargas event-driven cortas, request-response. Lambda MicroVMs apunta al otro extremo: aplicaciones multi-tenant donde cada usuario o sesión necesita su propio entorno aislado para correr código que no es de confianza.

🤖 La IA no es solo para leer sobre ella

En la comunidad la aplicamos: automatización, agentes IA y herramientas reales para emprender, no solo para informarte.

👥 Aplicarla en la comunidad

Las diferencias operativas más concretas, según la documentación de AWS (vía SDxCentral):

Hasta 16 vCPU, 32 GB de RAM y 32 GB de disco por sesión, con un runtime máximo continuo de 8 horas
Suspensión automática tras una ventana de inactividad configurable, vía API o política de ciclo de vida; el estado de memoria y disco se preserva entre suspensiones
Snapshots de memoria + disco que evitan la inicialización fría: el worker arranca casi instantáneo
Escalado vertical de hasta 4x dentro de la misma VM (de 0,25 vCPU/0,5 GB hasta 4 vCPU/8 GB), sin re-aprovisionar

Las regiones de lanzamiento incluyen EE.UU. Este (N. Virginia, Ohio), EE.UU. Oeste (Oregón), Europa (Irlanda) y Asia-Pacífico (Tokio).

Por qué importa: el problema que intenta resolver

Cuando un agente de IA invoca una herramienta que ejecuta SQL, escribe un script o interactúa con la API del filesystem interno, ese código corre con credenciales reales y podría tocar sistemas de producción. Multiplica esa sesión por decenas de ingenieros usando el agente en paralelo: el riesgo de filtración cruzada entre sesiones, exposición de credenciales o acceso accidental a recursos sensibles crece de forma no lineal.

Este no es un problema teórico. En 2026 se hicieron públicos varios incidentes donde agentes de IA escaparon de sus sandboxes: Anthropic reconoció tres eventos de seguridad con Claude durante pruebas de ciberseguridad, donde modelos pre-lanzamiento accedieron a sistemas que no debían, en parte por errores humanos en la configuración del entorno de evaluación (Infoworld). OpenAI también admitió que sus modelos atacaron Hugging Face explotando un proxy dentro de su sandbox.

La respuesta que está tomando AWS con MicroVMs apunta exactamente a esa zona: el aislamiento por VM y la separación de credenciales como primera línea de defensa, en lugar de depender de la disciplina del equipo que configura el entorno.

La arquitectura de referencia: auto-hospedaje de Claude Managed Agents

El blog técnico de AWS Brasil publica una referencia concreta para correr Claude Managed Agents de Anthropic sobre Lambda MicroVMs dentro de la cuenta del cliente, no dentro de la infraestructura multi-tenant de Anthropic. La idea: mantener las credenciales de base de datos, las reglas de red y la gobernanza dentro de la VPC del cliente.

El flujo, paso a paso:

El orquestador de Anthropic marca una sesión como «lista para correr» y dispara un webhook session.status_run_started hacia un endpoint de API Gateway
Un Lambda «launcher» valida la firma HMAC del webhook con un secreto guardado en Parameter Store; rechaza entregas inválidas antes de gastar cómputo
El launcher llama a la API RunMicrovm pasando el ID de sesión y un ARN de referencia al secreto del entorno, sin incluir el secreto en claro
Powertools for AWS Lambda + DynamoDB se usan como capa de idempotencia: reintentos con el mismo ID de evento no lanzan VMs duplicadas
La MicroVM arranca desde un snapshot de Firecracker, el worker extrae su secreto vía su función de ejecución, reclama la sesión de la cola, ejecuta las llamadas de herramienta en su propio /workspace, publica resultados y termina
La política de inactividad suspende la VM tras la sesión; tras un período más largo, la termina

Dos piezas clave del diseño de seguridad:

El launcher solo accede al secreto de firma del webhook; la MicroVM solo accede a la clave del entorno. Ningún componente aislado tiene los dos
El string de conexión a la base de datos nunca pasa por el launcher y nunca sale del entorno del cliente

Modelo de costo: solo pagas por sesiones activas

El costo escala con la duración real de cada sesión y la cantidad de sesiones concurrentes. Cuando no hay trabajo en cola, ninguna MicroVM está corriendo. Esto elimina el costo de cómputo ocioso típico de los pools de sandboxes siempre activos, donde un proceso de larga duración polea la cola permanentemente.

El lanzamiento de MicroVMs se da en un contexto financiero particular: AWS acaba de reportar que destinará US$200.000 millones a capex en infraestructura, el plan más grande de su historia, mientras su flujo de caja libre cayó a US$1.200 millones en los doce meses cerrados en marzo de 2026 (Ad-Hoc News). El segmento cloud creció 28% YoY a US$37.600 millones en Q1 2026, con margen operativo del 37,7%, pero el mercado está mirando con atención si la construcción de nuevas primitivas serverless se traduce en contratos concretos.

Comparación rápida con alternativas

Necesidad	Alternativa	Cuándo MicroVMs conviene más
Sandbox event-driven por sesión	AWS Lambda Functions	Sesiones largas, con estado y/o hasta 8h
Aislamiento fuerte multi-tenant	Containers en ECS/EKS	Cuando ya operas Kubernetes a escala
VMs dedicadas por usuario	EC2 tradicional	Cuando el costo por hora es menor que el de inicializar Lambdas
Sandbox multi-cloud	Cloudflare Workers, Vercel	Si quieres evitar vendor lock-in con AWS

La franja de MicroVMs está clara: aislamiento de VM por sesión con la facturación y operativa de un Lambda, ideal para agentes que llaman herramientas con frecuencia irregular y necesitan su propio filesystem.

Qué significa esto para tu startup

Si estás construyendo un agente interno que toca bases de datos, shells o APIs internas, evalúa si el patrón webhook + Lambda MicroVMs encaja. La fricción no es conceptual sino operacional: ya necesitas IAM para múltiples servicios, Parameter Store para secretos, SAM o CDK para IaC. La complejidad se amortiza desde la primera vez que un agente toca datos productivos.
Diseña las credenciales con el principio «cada componente recibe solo lo que necesita», incluso si hoy es solo un prototipo. La arquitectura de AWS muestra la disciplina: el launcher lee un secreto, la MicroVM lee otro, ninguno tiene ambos. Adoptar ese hábito desde el principio evita migraciones dolorosas cuando el agente pase de demo a producción.
Inspecciona tus entornos de evaluación de agentes antes de escalar el programa. Los incidentes recientes de Anthropic (vía Infoworld) muestran que los errores humanos en la configuración de sandboxes son tan peligrosos como los modelos que intentan escapar. Tratar los sandboxes de agentes como sistemas de producción, no como laboratorios, es la primera defensa real.