Lambda MicroVMs vs AgentCore Runtime: cuándo usar cada uno para agentes en producción

El 22 de junio de 2026, AWS lanzó algo que no es una feature ni una actualización: es un primitivo de cómputo nuevo. Lambda MicroVMs permite dar a cada usuario o sesión su propia VM Firecracker aislada, con estado que persiste hasta 8 horas, arranque desde snapshot en segundos, y sin infraestructura que gestionar.

Si llevas meses trabajando con AgentCore Runtime como yo, la reacción instintiva al leer el anuncio es la misma que registró la prensa técnica: otro caso de uso obvio para agentes de IA, pero AWS ya ofrece AgentCore Runtime, que se parece bastante a MicroVMs.

Y es correcto identificar el solapamiento. Pero es un error llevarlo hasta la conclusión de que son intercambiables.

Pasé los últimos días revisando la documentación oficial, los hands-on notes de Aidan Steele (quien exploró el servicio el día de lanzamiento), y el análisis de Yan Cui, además de mapear todo contra lo que ya conozco de AgentCore Runtime de haberlo cubierto en profundidad en esta serie. Este artículo es el resultado de ese trabajo.

🎯 ProTip #1: La pregunta correcta no es “¿Lambda MicroVMs o AgentCore Runtime?”. La pregunta correcta es “¿quién ejecuta el código — mi agente, o mis usuarios?” Esa distinción determina todo lo demás.

Lo que Tienen en Común: El Mismo Motor

Antes de hablar de diferencias, hay que entender por qué la confusión es razonable.

Ambos servicios corren sobre Firecracker, el VMM open-source que AWS desarrolló internamente y que ya potencia más de 15 billones (15 trillion) de invocaciones mensuales de Lambda Functions. Ambos dan aislamiento real a nivel de VM: sin kernel compartido, sin recursos compartidos entre sesiones. Ambos soportan hasta 8 horas de duración máxima. Y ambos agregaron soporte de shell interactivo en junio de 2026: Lambda MicroVMs con la API CreateMicrovmShellAuthToken, y AgentCore Runtime con InvokeAgentRuntimeCommandShell.

Eso es suficiente similitud para que la confusión sea comprensible. Pero la analogía que mejor captura la diferencia la escribió Yan Cui:

“AgentCore Runtime es a Lambda MicroVMs lo que Fargate es a EC2.”

Fargate corre tu contenedor en una microVM pero controla lo que puedes hacer dentro. EC2 te da la máquina completa. AgentCore te da hosting gestionado de contenedores en microVM. Lambda MicroVMs te da la VM en sí.

La frontera de aislamiento es la misma — Firecracker. Lo que puedes hacer dentro no lo es.

AgentCore Runtime: La Plataforma Gestionada

AgentCore Runtime es lo que AWS llama un “managed agent platform”. Despliegas tu código de agente — LangGraph, Strands, CrewAI, o el framework que uses — y AWS gestiona todo lo demás. Fleet management. Routing de sesiones a VMs. Scaling y teardown de sesiones idle. Auth inbound y outbound. Soporte nativo de protocolos MCP y A2A. Versionado. Endpoints.

Cuando tu usuario habla con tu agente, no piensas en VMs. El runtime provisiona la microVM, enruta la sesión, y cuando la sesión termina destruye el entorno y limpia la memoria.

Lo que corres dentro del contenedor de AgentCore Runtime es tu lógica de agente: el loop de razonamiento, las tools, el estado conversacional. El modelo LLM vive en Bedrock, en el lado de Anthropic, o donde lo hayas configurado. AgentCore pone a tu agente en un entorno seguro, escalable, y con observabilidad built-in — CloudTrail para auditoría, CloudWatch para logs.

Las restricciones son las de cualquier plataforma gestionada: corres dentro de un contenedor que AWS configura y opera, no tienes la VM completa a tu disposición. El entorno está deliberadamente más acotado que una VM con todas las capabilities del sistema operativo, porque ejecutar un agente no requiere ese nivel de control. AgentCore sí te da shell interactivo — pero a través de una API gestionada (InvokeAgentRuntimeCommandShell), no acceso crudo al device del pseudoterminal. Si tu caso necesita cosas como /dev/ptmx directo, correr tu propio daemon de Docker, o manipular el stack de red a bajo nivel, ese no es el terreno de AgentCore Runtime — es exactamente lo que Lambda MicroVMs habilita, como veremos enseguida.

🔍 ProTip #2: AgentCore está disponible en 15 regiones según el FAQ oficial de AWS — incluyendo us-east-1, us-west-2, eu-central-1 (Frankfurt), ap-northeast-1 (Tokyo), Mumbai, Sydney, Singapur, y varias de Europa. Lambda MicroVMs al lanzamiento está solo en 5 regiones: us-east-1, us-east-2, us-west-2, eu-west-1 (Irlanda), y ap-northeast-1 (Tokyo). Ten en cuenta que ciertas features puntuales de AgentCore Runtime (shell interactivo, MCP stateful, AG-UI) llegan a un subconjunto de esas regiones, así que verifica la lista oficial de regiones soportadas para tu feature específica. Si tu workload necesita una región fuera de las 5 de MicroVMs, AgentCore Runtime sigue siendo la única opción gestionada por ahora.

Lambda MicroVMs: El Primitivo de Bajo Nivel

Lambda MicroVMs es un namespace de API completamente nuevo dentro de Lambda — aws lambda-microvms — con su propia superficie de comandos. No es una opción de configuración de Lambda Functions. Es un recurso distinto.

El flujo es diferente desde el principio. En lugar de un handler que responde a eventos, tú empaquetas tu aplicación (cualquier cosa que corra en Linux) y un Dockerfile en un zip, lo subes a S3, y llamas create-microvm-image. Lambda ejecuta el Dockerfile, inicializa la aplicación, y captura un snapshot Firecracker del estado en memoria y disco. Eso es tu imagen.

Cuando necesitas un entorno aislado — para un usuario, un job, una sesión de sandbox — llamas run-microvm. Lambda lanza la VM desde el snapshot con startup near-instant y te devuelve un endpoint HTTPS dedicado con un ID único para esa VM. Los clientes se conectan sobre HTTP/2, gRPC, o WebSockets. Cada conexión requiere un bearer token que generas con CreateMicrovmAuthToken.

Lo que puedes hacer dentro de ese entorno es completamente diferente a AgentCore Runtime:

# Dentro de una MicroVM tienes un Linux completo
# Docker dentro de la MicroVM: funciona
# /dev/ptmx para pseudoterminales: disponible
# iptables, eBPF, namespaces de red: disponibles
# Hasta 16 vCPUs y 32 GB de memoria
# 32 GB de disco

El gotcha más importante que documentó Aidan Steele el día del lanzamiento: todo UDP outbound está bloqueado por defecto. El resolver DNS por defecto es un stub local. Si corres contenedores Docker dentro de tu MicroVM, el DNS dentro de los contenedores intentará caer a 8.8.8.8 — que falla porque el UDP está bloqueado. La solución es forzar el DNS de Lambda: docker run --dns 169.254.169.253.

⚠️ ProTip #3: Las imágenes MicroVM se construyen exclusivamente desde un Dockerfile en un ZIP subido a S3 — no desde una imagen ECR directamente. La documentación oficial sugiere que ECR está soportado, pero Aidan Steele lo verificó el día del lanzamiento: no lo está. Tu Dockerfile puede hacer FROM alguna-imagen-ecr, pero el proceso siempre parte de un Dockerfile en S3. Otro detalle: Lambda construye dos copias de la imagen — una para Graviton 3 y otra para Graviton 4 — por eso piden el Dockerfile fuente en lugar de la imagen compilada.

Además, la escala horizontal es tuya. Lambda MicroVMs hace escala vertical automática dentro de cada VM (hasta 4x el baseline configurado), pero si necesitas más entornos aislados, tu aplicación los crea, les hace tracking, enruta usuarios al entorno correcto, y los limpia. No hay fleet management automático. No hay routing built-in.

Eso no es una limitación — es una decisión de diseño deliberada. Lambda MicroVMs es un primitivo. La plomería de fleet management es lo que tú construyes encima.

El Modelo Mental Correcto

La manera más clara que encontré de pensar en esto:

AgentCore Runtime: “corre mi agente para que mis usuarios puedan hablar con él”.

Lambda MicroVMs: “dale a cada usuario su propia VM aislada para que corran código en ella”.

En AgentCore Runtime, tu agente ejecuta código. El código que ejecuta es el razonamiento del LLM, las tools que definiste, la lógica que programaste. Los usuarios interactúan con el agente — no ejecutan código arbitrario en el entorno.

En Lambda MicroVMs, tus usuarios ejecutan código. O más precisamente, el código que genera el agente — output de un LLM, scripts de un usuario, queries de análisis — se ejecuta en el entorno aislado. El agente es el origen del código, no el ejecutor.

Esta distinción define los casos de uso de cada servicio.

🎓 ProTip #4: Hay un caso de uso donde Lambda MicroVMs y AgentCore Runtime se complementan directamente: coding agents con sandboxes de ejecución. AgentCore Runtime corre tu agente (el razonamiento). Cada vez que el agente genera código para ejecutar, lanza una Lambda MicroVM para ejecutarlo de forma aislada. El resultado vuelve al agente. Es la arquitectura que AWS documenta en la guía oficial para Claude Managed Agents con self-hosted sandboxes.

Cuándo Usar AgentCore Runtime

AgentCore Runtime es el primitivo correcto cuando:

Construyes un agente que presta un servicio a usuarios. Un asistente de soporte técnico. Un agente de análisis financiero. Un bot de coding que ayuda a debuggear código del usuario, pero donde el agente tiene su propio estado, tools y razonamiento. El usuario habla con el agente, no ejecuta código en el entorno del agente.

Necesitas el ecosistema gestionado de AgentCore. Si usas AgentCore Memory para persistencia episódica, AgentCore Policy para límites determinísticos, AgentCore Payments para micropagos, o el Agent Registry para governance — todo eso está construido sobre el Runtime y se integra sin código adicional.

Necesitas disponibilidad en más regiones. Quince regiones incluyendo Mumbai, Sydney, Singapur, y varias de Europa que Lambda MicroVMs no cubre todavía.

La complejidad operacional de fleet management no es parte de tu producto. No quieres escribir el código que decide cuántas VMs tener en pie, cuáles asignar a qué usuario, y cuándo limpiarlas. AgentCore lo hace por ti.

Tu agente pasa buena parte del tiempo esperando I/O. AgentCore Runtime solo cobra CPU por consumo activo — si tu agente no consume CPU mientras espera la respuesta del LLM, una tool call, o una query a base de datos, ese tiempo no se factura (pricing oficial de AgentCore Runtime). En workloads agénticos, que típicamente pasan entre 30% y 70% del tiempo en I/O wait, esto es una ventaja de costo real frente a un modelo que factura toda la duración de la sesión sin distinguir CPU activo de CPU idle.

💡 ProTip #5: Si ya tienes AgentCore Runtime en producción y tu agente ejecuta código que los usuarios envían, ese es el único caso donde deberías plantearte migrar la ejecución de ese código a Lambda MicroVMs como sandbox. No migrar el agente — migrar la capa donde se ejecuta el código no confiable.

Cuándo Usar Lambda MicroVMs

Lambda MicroVMs es el primitivo correcto cuando:

Construyes una plataforma multi-tenant donde cada usuario necesita su propio entorno de ejecución. Un notebook interactivo de análisis de datos. Un coding assistant que ejecuta el código que el LLM genera. Una plataforma de CI/CD que corre pipelines en aislamiento por tenant. Un escáner de vulnerabilidades que inspecciona paquetes. En todos estos casos, el producto es el entorno de ejecución aislado — no el agente que razona.

Necesitas acceso completo al sistema operativo. Correr Docker dentro de la VM. eBPF. Montar filesystems. Instalar paquetes a nivel de sistema operativo. Nada de esto es posible en AgentCore Runtime porque corre en un contenedor, no en una VM completa.

Construyes algo que no es un agente de IA. Un servidor de juegos que ejecuta scripts de usuarios. Un entorno de CI con fuerte aislamiento por tenant. Una herramienta de research de seguridad. Lambda MicroVMs no está atado al ecosistema de agentes.

Quieres control granular del lifecycle. Lambda MicroVMs expone APIs directas para suspend-microvm, resume-microvm, y terminate-microvm. Puedes construir exactamente la lógica de lifecycle que tu producto necesita.

🚨 ProTip #6: El modelo de precios de Lambda MicroVMs es por segundo de instancia — más cercano a Fargate que a Lambda Functions. Se cobra por vCPU-segundo + GB de memoria por segundo + snapshot reads/writes + data transfer. A diferencia de Lambda Functions (por milisegundo), Lambda MicroVMs factura por segundo. Mientras la VM está suspended, los cargos de cómputo cesan — solo pagas el snapshot storage. El suspend/resume es la palanca principal para controlar costos en sesiones con períodos largos de inactividad. Verifica los precios actuales en la página oficial de pricing de AWS Lambda antes de presupuestar cualquier workload.

La Tabla de Decisión Honesta

Para bajar todo esto a algo accionable:

El Caso del Coding Agent: Los Dos Juntos

Hay un caso donde los dos servicios son la respuesta — no uno u otro. Es el que AWS formalizó con su guía oficial para Claude Managed Agents con sandboxes self-hosted.

La arquitectura es:

1. AgentCore Runtime corre tu agente — el loop de razonamiento, el modelo, la gestión de sesión conversacional.
2. Cuando el agente genera código para ejecutar (bash, Python, Node.js), tu control plane lanza una Lambda MicroVM por sesión.
3. El código del agente se ejecuta en ese sandbox aislado.
4. El resultado vuelve al agente como output de tool.

El flujo concreto según la documentación oficial:

1. Anthropic envía webhook session.status_run_started
2. Una Lambda Function verifica la firma y llama run-microvm
3. La MicroVM levanta, ejecuta tool calls en /workspace
4. Resultados vuelven a Anthropic
5. La MicroVM se suspende o termina al cerrar la sesión

Tu API key de Anthropic nunca toca cómputo de AWS en este flujo. El launcher solo pasa una referencia a Secrets Manager — la MicroVM lee la clave en runtime con credenciales temporales via IMDSv2.

🔧 ProTip #7: Si implementas este patrón, configura la idle-policy de tu MicroVM con suspendedDurationSeconds: 0 y autoResumeEnabled: false para sesiones por usuario. Quieres que las MicroVMs terminen cuando la sesión cierra, no que se suspendan esperando tráfico que puede no volver. Usa maximumDurationInSeconds como ceiling de seguridad para sesiones bloqueadas — el máximo es 28,800 segundos (8 horas).

Lo Que No Se Sabe Todavía

Sería deshonesto no incluir las limitaciones actuales que hay que monitorear:

Lambda MicroVMs está disponible desde el 22 de junio. La curva de adopción es corta y hay detalles que todavía emergen:

El tamaño máximo de imagen no está documentado. Aidan Steele verificó en el lanzamiento que la máquina que construye las imágenes tiene aproximadamente 7.2 GB de espacio libre en disco. Imágenes grandes pueden fallar en el build con un error críptico.

Las variables de entorno requieren rebuild de imagen. En Lambda Functions, actualizar env vars es inmediato. En MicroVMs, los env vars van en la imagen — cambiarlos requiere create-microvm-image de nuevo. Diseña el acceso a configuración dinámica (Secrets Manager, SSM Parameter Store) como llamadas en runtime, no como env vars.

ECR como source no está soportado a pesar de que los docs lo sugieren. La fuente siempre es un Dockerfile en un ZIP en S3. Tu Dockerfile puede hacer FROM a una imagen ECR, pero el proceso parte del Dockerfile.

Regiones limitadas al lanzamiento. El equipo de Lambda tiene track record de expandir regiones rápidamente, pero si us-east-1, us-east-2, us-west-2, eu-west-1, o ap-northeast-1 no sirven para tu caso, aguarda a la expansión.

🎯 ProTip #8: Antes de diseñar una arquitectura de producción sobre Lambda MicroVMs, ejecuta el tutorial oficial completo: create-microvm-image + run-microvm + auth token + request HTTP real. Según las mediciones de Aidan Steele el día del lanzamiento, el ciclo de run-microvm a estado RUNNING tomó ~2 segundos, y la app sirviendo HTTP 200 OK ~2 segundos adicionales — pero él mismo advierte que tomes esos números con pinzas, porque estaba conectándose a us-east-1 desde el otro lado del mundo. El suspend y el resume rondaron 1 segundo cada uno en sus pruebas. Mídelo tú mismo desde tu región antes de comprometer cualquier número a tu diseño: si tu UX requiere sub-segundo en el arranque desde cero, ese delta importa.

Mi Evaluación

Si construyes agentes que sirven a usuarios, AgentCore Runtime sigue siendo el punto de partida correcto. El ecosistema de Memory, Policy, Payments, y Session Storage existe para ese caso, y el fleet management gestionado elimina una clase entera de trabajo de plataforma.

Si construyes plataformas donde los usuarios ejecutan código, Lambda MicroVMs es la opción más limpia que AWS ha ofrecido hasta ahora. Era un problema que antes requería operar Firecracker directamente, o pagar a un vendor especializado, o hacer concesiones de aislamiento con contenedores. Ahora es un run-microvm.

Si construyes coding agents — agentes que razonan sobre código y necesitan ejecutarlo de forma segura — la arquitectura correcta probablemente use los dos: AgentCore Runtime para el razonamiento, Lambda MicroVMs para el sandbox de ejecución.

La pregunta que debes responder antes de elegir no es técnica. Es de diseño de producto: ¿en tu sistema, quién ejecuta el código que no escribiste tú?

Si la respuesta es el agente — AgentCore Runtime.

Si la respuesta son tus usuarios — Lambda MicroVMs.

Si la respuesta son los dos — los dos.

¿Estás evaluando Lambda MicroVMs para un caso de uso específico? ¿O ya tienes AgentCore Runtime en producción y te preguntas si migrarlo tiene sentido? Me interesa saber qué arquitectura están considerando — los comentarios están abiertos.

¡Nos vemos en el próximo artículo! 🚀

Recursos Oficiales 📚

• Anuncio oficial: AWS Lambda MicroVMs
• Blog de lanzamiento: Run isolated sandboxes with full lifecycle control
• Developer Guide: AWS Lambda MicroVMs
• API Reference: Lambda MicroVMs
• Guía: Lambda MicroVMs como sandbox para Claude Managed Agents
• Pricing: AWS Lambda MicroVMs
• Pricing: Amazon Bedrock AgentCore
• Hands-on notes de Aidan Steele — día del lanzamiento
• Análisis de Yan Cui: What you need to know about Lambda MicroVMs
• Documentación oficial: AgentCore Runtime
• API: InvokeAgentRuntimeCommandShell