AWS Lambda MicroVMs: sandboxes serverless para IA y código no confiable
AWS acaba de presentar uno de los lanzamientos más interesantes de Lambda en bastante tiempo: AWS Lambda MicroVMs. Y vale aclararlo de entrada: no es “Lambda Functions pero más grande”. Es una nueva forma de ejecutar entornos serverless aislados, pensada para un problema que se volvió urgente con la llegada de agentes de IA: cómo correr de forma segura código que tu aplicación no escribió.
Si estás construyendo un asistente de programación con IA, un IDE en el browser, una plataforma de notebooks, un scanner de vulnerabilidades, un runner de CI multi-tenant o cualquier producto que ejecute scripts de usuarios, el dilema es bastante conocido. Las máquinas virtuales aíslan bien, pero suelen ser pesadas y lentas de iniciar. Los contenedores arrancan rápido, pero comparten kernel y requieren mucho trabajo extra si el código es no confiable. Las funciones serverless son excelentes para request-response y eventos cortos, pero no están pensadas para sesiones interactivas que necesitan conservar estado.
Lambda MicroVMs apunta exactamente a ese hueco.
Qué anunció AWS
En el anuncio oficial, AWS presenta Lambda MicroVMs como una opción serverless para crear entornos aislados a nivel máquina virtual. La promesa es concreta: arrancar rápido, pausar y reanudar sesiones, y conservar estado mientras se ejecuta código generado por usuarios o por IA.
La base técnica es Firecracker, la misma tecnología de virtualización liviana que usa AWS Lambda. AWS menciona que Firecracker potencia más de 15 billones de invocaciones mensuales de Lambda Functions. Ese dato importa porque no estamos hablando de un experimento aislado ni de una feature pegada con cinta: AWS está reutilizando una capa de virtualización que ya opera a escala enorme.
El post de lanzamiento en AWS News Blog lo plantea desde casos de uso muy concretos: asistentes de coding con IA, entornos interactivos de desarrollo, plataformas de analytics, scanners de seguridad y game servers que ejecutan scripts provistos por usuarios. Todos comparten una necesidad: asignar un entorno aislado por usuario, trabajo o sesión.
La diferencia fuerte es el límite de aislamiento. No es simplemente un contenedor endurecido. Cada sesión corre en una MicroVM dedicada, sin kernel compartido ni recursos compartidos entre usuarios.
Cómo funciona el modelo
El flujo de trabajo es distinto al de una Lambda Function tradicional. La guía de Lambda MicroVMs describe el proceso así:
1. Empaquetás tu código y un Dockerfile en un zip.
2. Subís ese zip a Amazon S3.
3. Llamás a la API de Lambda para crear una imagen de MicroVM.
4. Lambda ejecuta el Dockerfile, inicia la aplicación y captura un snapshot del entorno ya inicializado.
5. Cuando tu aplicación necesita un sandbox, llamás a run-microvm.
6. Lambda lanza una MicroVM desde ese snapshot y crea un endpoint HTTPS dedicado.
7. Si la sesión queda inactiva, la MicroVM puede suspenderse conservando memoria y disco.
8. Cuando vuelve el tráfico, se reanuda.
9. Cuando termina el trabajo, la terminás.
La parte del snapshot es clave. En vez de arrancar todo desde cero, la MicroVM se crea desde un entorno preinicializado. Para workloads interactivos —por ejemplo, un notebook o un sandbox de agente— eso permite una experiencia mucho más rápida sin resignar aislamiento fuerte.
Ejemplo concreto con CLI
La documentación de running and using MicroVMs muestra un comando run-microvm como este:
aws lambda-microvms run-microvm \
--image-identifier arn:aws:lambda:us-east-1:123456789012:microvm-image:my-microvm-image \
--ingress-network-connectors "arn:aws:lambda:us-east-1:aws:network-connector:aws-network-connector:ALL_INGRESS" \
--egress-network-connectors "arn:aws:lambda:us-east-1:aws:network-connector:aws-network-connector:INTERNET_EGRESS" \
--idle-policy '{"autoResumeEnabled":true,"maxIdleDurationSeconds":900,"suspendedDurationSeconds":1800}' \
--maximum-duration-in-seconds 14400El único parámetro obligatorio es --image-identifier. El resto sirve para configurar networking, rol de ejecución, política de inactividad, logging, payload de runtime y duración máxima. Según la documentación, el máximo para que una MicroVM permanezca corriendo o suspendida es 28.800 segundos, es decir 8 horas.
También hay un detalle importante de arquitectura: cada MicroVM tiene su propio endpoint HTTPS dedicado. No hay balanceo de carga entre varias MicroVMs detrás de un único endpoint. El endpoint representa una sesión o sandbox puntual, lo cual encaja perfecto con el patrón “un usuario, un entorno”.
Por qué importa para aplicaciones con IA
Los agentes de IA cambiaron el perfil de riesgo de muchas aplicaciones. Hoy es normal que un sistema genere código, lo ejecute, instale paquetes, lea archivos, transforme datos o corra tests. Si eso ocurre dentro de un pool genérico de contenedores compartidos, el problema de seguridad aparece rápido.
Lambda MicroVMs le da a los equipos de producto una abstracción administrada para ejecutar código no confiable sin tener que operar su propia plataforma de virtualización. Por ejemplo:
- Una plataforma de notebooks podría crear una MicroVM por sesión de usuario, precargar dependencias, suspenderla luego de 15 minutos de inactividad y reanudarla cuando el usuario vuelve.
- Un asistente de programación podría correr código generado por IA en una MicroVM aislada por conversación o tarea.
- Un scanner de seguridad podría ejecutar cada análisis dentro de un límite de VM independiente.
- Un sistema de CI multi-tenant podría aislar jobs de clientes sin administrar hosts Firecracker propios.
Esto no elimina el trabajo de seguridad de aplicación. Todavía necesitás IAM bien diseñado, límites de red, manejo cuidadoso de secretos, cuotas, logs, monitoreo y protección contra abuso. Pero sí mueve una parte difícil —el aislamiento de cómputo— a un servicio administrado.
Límites y decisiones de arquitectura
El lanzamiento es interesante, pero no reemplaza todos los patrones de cómputo.
Primero, está limitado por regiones. El anuncio lista disponibilidad inicial en US East (N. Virginia), US East (Ohio), US West (Oregon), Asia Pacific (Tokyo) y Europe (Ireland).
Segundo, el modelo está pensado para sesiones. Si necesitás un servicio siempre encendido, probablemente ECS, EKS, EC2 o Lambda Managed Instances sigan siendo mejores opciones. Lambda MicroVMs tiene más sentido cuando necesitás entornos aislados, con estado y de vida relativamente corta.
Tercero, el pricing requiere mirarlo con cuidado. La página de precios de AWS Lambda indica que Lambda MicroVMs se cobra por recursos de cómputo usados, operaciones de lectura/escritura de snapshots, almacenamiento de snapshots y transferencia de datos estándar. El anuncio también aclara que pagás recursos base mientras la MicroVM está corriendo, y duración activa adicional cuando la carga supera ese baseline. Traducido: la suspensión por inactividad no es un detalle simpático; es parte central de la economía del servicio.
Mi lectura
Este lanzamiento muestra hacia dónde se está moviendo serverless. La abstracción original de Lambda era: “ejecutá esta función cuando llega un evento”. Lambda MicroVMs propone algo distinto: “dame un entorno seguro, stateful y administrado para este usuario, job o agente”.
Para aplicaciones AI-native, es un bloque que conviene mirar de cerca. No como reemplazo general de contenedores, sino como servicio de lifecycle para sandboxes. La clave va a estar en modelar bien las sesiones, mantener las imágenes chicas, definir políticas de idle explícitas, restringir egress, separar secretos y terminar agresivamente los entornos cuando ya no hacen falta.
AWS está convirtiendo infraestructura que antes requería mucho trabajo de plataforma en primitives administrados. Bedrock cubre modelos y agentes. Lambda MicroVMs empieza a cubrir el lugar donde ejecutás, de forma más segura, el código impredecible que esos agentes o usuarios generan.
