Para aislar en AWS el código que genera tu agente de IA, ahora puedes ejecutar cada pod de EKS, tarea de ECS o VM en su propia máquina virtual ligera del Nitro Hypervisor. AWS las llama Nitro Sandboxes, las anunció el 9 de noviembre de 2026 y no cobra nada adicional por ellas más allá de las instancias que ya pagas.
Nota sobre regiones (al momento de publicar esta nota, 10 de noviembre de 2026): el anuncio dice que Nitro Sandboxes está disponible en todas las regiones comerciales de AWS, pero la guía de usuario de EKS indica que los pods aislados y confidenciales están disponibles “en las regiones comerciales de AWS en Estados Unidos”. Si usas EKS en São Paulo, México o Madrid, revisa la guía de EKS antes de planificar en torno a esta función.
AWS es explícita sobre el objetivo: junto a las cargas multi-tenant y reguladas, menciona a los agentes de IA que ejecutan código generado por un LLM. Es el problema con el que tarde o temprano se encuentra cualquier equipo que conecta un agente a un pipeline de CI, a un bot de code review o a un flujo de “arregla este issue”: el agente produce código, algo tiene que ejecutarlo, y el kernel compartido de un contenedor no es una frontera en la que quieras apostar. Si tu agente corre en tu propia máquina, el camino es otro: lo explicamos en Cómo usar Dev Containers con agentes de IA en VS Code.
¿Qué es un sandbox para agentes de IA en AWS Nitro?
Un Nitro Sandbox es una VM hija ligera, virtualizada por hardware, que corre junto a tu carga de trabajo en una instancia EC2. La instancia padre le cede vCPU y memoria; Nitro aísla el sandbox de la instancia padre, de los demás sandboxes, de los operadores de AWS y, en modo confidencial, incluso de tus propios operadores.
La diferencia práctica frente a un contenedor normal: cada sandbox tiene su propio kernel. Si alguien escapa de un contenedor en un pod, cae dentro de una VM, no en el nodo.
¿En qué se diferencia de un contenedor, de Firecracker y de Nitro Enclaves?
Vale la pena ubicarlo frente a tres cosas que probablemente ya conoces:
- Un contenedor (runc): comparte el kernel del host. Nitro Sandboxes pone una frontera de virtualización por hardware alrededor de cada pod.
- Firecracker: es el VMM (virtual machine monitor) que AWS recomienda para manejar Nitro Sandboxes en EC2. Nitro Sandboxes no reemplaza a Firecracker: en EC2 ejecutas Firecracker y Nitro aporta el aislamiento y la attestation por debajo. QEMU y otros VMM necesitan compatibilidad adicional antes de poder usar attestation o el modo confidencial.
- Nitro Enclaves: mismos cimientos, otro alcance. Un enclave se conecta con su instancia padre solo por un canal vsock y sirve para tareas pequeñas y acotadas. Nitro Sandboxes suma dispositivos virtuales de red y de bloque, así que puede ejecutar cargas normales del tamaño de un contenedor.
¿Modo aislado o confidencial?
Hay dos modos. Se eligen al crear el sandbox y no cambian mientras está en ejecución:
- Modo confidencial (el predeterminado en EC2): la memoria del sandbox sale de la instancia padre, que ya no puede leerla, y el sandbox incluye un Nitro Security Module para la attestation. Un verificador externo, normalmente AWS KMS mediante una condición en la política de la clave, entrega los secretos solo cuando las mediciones coinciden.
- Modo directo (opcional): la instancia padre comparte la memoria del sandbox, el rendimiento de I/O es mayor y no hay attestation. AWS recomienda usarlo solo cuando la misma parte de confianza opera la instancia padre y el sandbox.
En EKS esto se traduce en dos runtime classes: isolated-sandbox (el nodo padre es de confianza) y confidential-sandbox (el nodo padre no es de confianza).
Una advertencia de la documentación de EKS que conviene repetir: sin una política de clave KMS que verifique los valores PCR, la medición de attestation se registra pero nunca se verifica. Si eliges el modo confidencial, configura condiciones kms:RecipientAttestation:PCR<PCR_ID> en cada clave KMS que proteja esos datos; de lo contrario, la garantía queda incompleta.
¿Cómo se activa en Amazon EKS?
En EKS Auto Mode es literalmente una línea en el spec del pod. Con tus propios node groups, primero necesitas una AMI personalizada.
EKS Auto Mode: la ruta que recomienda AWS
Auto Mode incluye soporte para Nitro Sandboxes sin configuración adicional: no tienes que construir ninguna AMI. El único requisito es la versión del cluster. Nitro Sandboxes necesita Kubernetes 1.36 o superior, y eksctl usa por defecto una versión más antigua, así que pasa --version de forma explícita:
eksctl create cluster --name sandbox-demo --region us-west-2 --version 1.37 --enable-auto-mode
Después, define runtimeClassName en el pod:
apiVersion: v1
kind: Pod
metadata:
name: my-app
spec:
runtimeClassName: isolated-sandbox
containers:
- name: main
image: public.ecr.aws/amazonlinux/amazonlinux:2023
command: ["sleep", "3600"]
resources:
limits:
cpu: "1"
memory: 512Mi
kubectl apply -f manifest.yaml
kubectl get pod my-app
Los pods sin runtimeClassName siguen usando el runtime de contenedores predeterminado, así que puedes poner en sandbox solo las cargas que ejecutan código del agente y dejar todo lo demás como está.
En Deployments, Jobs, CronJobs y otros controladores, runtimeClassName y todas las anotaciones sandbox.amazonaws.com/ van en la plantilla del pod (spec.template.spec y spec.template.metadata.annotations). AWS advierte que una anotación en los metadatos del propio controlador se acepta y luego se ignora sin aviso: un error fácil de pasar por alto en una revisión.
¿Y si usas node groups propios?
Fuera de Auto Mode necesitas:
- Construir una AMI personalizada que incluya el runtime de Nitro Sandbox (AWS documenta el proceso en su página “Create and update a Nitro Sandbox AMI”).
- Usar un tipo de instancia compatible.
- Habilitar Nitro Enclaves en el launch template del node group:
EnclaveOptions.Enabled=true. - Unir los nodos al cluster y definir
runtimeClassNameen el pod.
El paso 3 es el que la gente se salta. La documentación es directa: elegir un tipo de instancia compatible con Nitro Enclaves no basta; sin Nitro Enclaves habilitado, el nodo nunca anuncia capacidad para sandboxes.
¿Se puede dejar el sandbox sin red?
Sí. Una sola anotación arranca el sandbox sin ningún dispositivo de red:
metadata:
annotations:
sandbox.amazonaws.com/network-isolated: "true"
La contrapartida: kubectl port-forward deja de funcionar y las sondas HTTP o TCP del kubelet no pueden tener éxito, así que cambia a exec probes. Para un agente que solo necesita correr tests sobre código que ya está dentro del pod, es la configuración más limpia disponible.
¿Hay un ejemplo listo con un agente de código?
Sí. AWS publica un conjunto de blueprints ejecutables en aws-samples/sample-eks-nitro-sandbox, con licencia MIT-0. El más relevante para este público ejecuta Claude Code dentro de un sandbox que lee un issue de GitHub, lo corrige y abre un pull request, usando modelos Claude a través de Amazon Bedrock. Incluye un egress-policy.yaml junto al manifiesto del job, y parte del blueprint “Hello sandbox”, que por sí solo ya alcanza para ver la frontera de aislamiento.
Lo que necesitas, según la página del blueprint: una cuenta de AWS con el AWS CLI configurado, eksctl, kubectl, Docker, Git (con user.name y user.email definidos), la GitHub CLI con sesión iniciada y acceso a un modelo Claude en Bedrock en tu región. Los manifiestos usan us-west-2 por defecto; para otra región, cámbiala en fix-issue.yaml y en egress-policy.yaml.
El resto del catálogo es un buen mapa de dónde espera AWS que se use esto: warm pools de sandboxes pre-arrancados, runners de GitHub Actions y GitLab CI, builds de Docker, políticas de red de salida, límites de DNS y conexiones por sandbox, sandboxes autoalojados para los managed agents de Claude y de OpenAI, y blueprints confidenciales donde KMS entrega claves solo a sandboxes con attestation válida.
¿Funciona con ECS o directamente en EC2?
ECS: sí, como “isolated and confidential tasks”, pero solo en Amazon ECS Managed Instances. Cada tarea corre en su propia VM ligera, y AWS lo presenta como un aislamiento similar al de Fargate, manteniendo la elección del tipo de instancia, el bin-packing de varias tareas por instancia y las Capacity Reservations. Al momento de publicar esta nota, la página de ECS no muestra la sintaxis de la task definition; revisa la ECS Developer Guide antes de activarlo.
EC2 directamente: para tener control total, lanzas una instancia con enclaves habilitados y manejas el sandbox con Firecracker. Según la guía de usuario de EC2:
aws ec2 run-instances \
--image-id ami-id \
--instance-type instance-type \
--enclave-options Enabled=true
{
"boot-source": { "kernel_image_path": "sandbox-image" },
"machine-config": { "vcpu_count": 2, "mem_size_mib": 2048 },
"drives": [{
"drive_id": "rootfs", "path_on_host": "rootfs.ext4",
"is_root_device": true, "is_read_only": false
}],
"network-interfaces": [{ "iface_id": "eth0", "host_dev_name": "tap0" }],
"enclave": {}
}
firecracker --config-file sandbox.json
Un objeto "enclave": {} vacío selecciona el modo confidencial; "enclave": { "direct_mode": true } selecciona el modo directo. En esta ruta te haces cargo de todo lo que EKS y ECS resuelven por ti: imágenes guest, backends de dispositivos, contabilidad de recursos, borrado de memoria, apagado y el relay de la attestation.
¿Qué límites tiene?
- Tipos de instancia: Nitro Sandboxes corre solo en tipos de instancia compatibles con Nitro Enclaves. La mayoría de las familias actuales M, C, R, X, D e I califican, con excepciones por tamaño (a menudo
.largey.metal) que aparecen en la guía de usuario de EC2. Revisa el tamaño exacto, no solo la familia. - Sin GPU passthrough hacia el sandbox, al momento de publicar esta nota.
- Presupuesto de vCPU: el total de vCPU de todos los sandboxes de una instancia no puede superar 5 veces las vCPU de la instancia. En una instancia de 4 vCPU eso son 20 vCPU de sandbox, por ejemplo 20 sandboxes de 1 vCPU.
- La memoria no se sobreasigna: la instancia padre cede la cantidad completa al arrancar el sandbox y solo la recupera al terminarlo. Ni la vCPU ni la memoria se pueden cambiar mientras el sandbox está en ejecución.
- En EKS, aislamiento no es reserva de rendimiento: la documentación de EKS dice que las vCPU se comparten en el tiempo entre los sandboxes de un nodo y que la asignación total puede sobresuscribir el nodo.
- Recursos de red compartidos: un solo sandbox puede agotar los presupuestos de conntrack y DNS de la instancia padre. Limita cada sandbox; los blueprints incluyen un ejemplo.
- Nunca montes el mismo volumen EBS en dos sandboxes a la vez: corrompe el sistema de archivos.
El anuncio dice que Pod Identity, VPC CNI, el almacenamiento EBS, EFS y S3 y CloudWatch funcionan sin modificaciones en EKS y ECS. AWS no publica cifras de overhead ni benchmarks más allá de describir un rendimiento cercano al nativo de EC2: tómalo como una afirmación de AWS hasta que midas tu propia carga.
¿AWS Nitro Sandboxes, GKE Agent Sandbox o E2B?
Si buscas una alternativa a E2B o comparas opciones de agent sandbox, la diferencia de fondo es quién opera la infraestructura y qué tipo de frontera de aislamiento obtienes.
| AWS Nitro Sandboxes | GKE Agent Sandbox | E2B | |
|---|---|---|---|
| Aislamiento | VM ligera por pod o tarea sobre el Nitro Hypervisor, con kernel propio | gVisor (kernel en espacio de usuario) | Servicio administrado de sandboxes |
| Dónde corre | Tu EKS, ECS Managed Instances o EC2 | Tu cluster de GKE | Infraestructura de E2B (BYOC en Enterprise) |
| Cargo adicional | Ninguno; pagas las instancias | Ninguno; aplica el precio de GKE | Se cobra por segundo de sandbox en ejecución |
| Attestation | Sí, en modo confidencial | — | — |
| Versión de Kubernetes | 1.36+ | GKE 1.35.2-gke.1210000+ | No aplica |
Precios y condiciones según las páginas de cada proveedor al 10 de noviembre de 2026.
La división honesta: GKE Agent Sandbox y Nitro Sandboxes son “trae tu propio cluster”: el aislamiento no cuesta extra y la operación es tuya. E2B es el intercambio opuesto: nada que operar, y pagas por segundo a cambio. Entre los dos primeros, la diferencia arquitectónica es la frontera misma: gVisor intercepta las llamadas al sistema en un kernel en espacio de usuario; Nitro pone una VM virtualizada por hardware alrededor de cada pod.
¿AWS Nitro Sandboxes es gratis? La visión de Grego
La frase que se va a repetir es “sin cargo adicional”. Es precisa e incompleta. Sigues pagando la capacidad de EC2 donde viven los sandboxes, y la memoria de cada sandbox es dedicada, no sobreasignada, así que la densidad la limita la RAM antes que la vCPU.
Lo que sí cambia es la forma de la factura. Un servicio administrado como E2B pone precio al sandbox en sí: en su plan Pro, 150 dólares al mes más el uso por segundo, y con las tarifas publicadas el sandbox predeterminado de 2 vCPU y 4 GiB sale a unos 0,17 dólares por hora. Con Nitro Sandboxes, ejecutar código de agentes pasa a ser una carga más sobre capacidad que ya planificas, reservas y negocias. Para un equipo que ya corre EKS con Savings Plans o Capacity Reservations, esa es la oferta real: aislamiento por hardware incluido en un compromiso que ya existe, en lugar de un proveedor nuevo en el presupuesto.
Donde E2B sigue ganando es en el tiempo hasta el primer sandbox y en la operación cero. Si todavía no corres Kubernetes en AWS, levantar un cluster 1.36 con Auto Mode es mucha plataforma solo para ejecutar código de un agente. Elige según dónde vive ya tu cómputo.
¿Y tú? ¿Dónde ejecuta hoy tu equipo el código que generan sus agentes de IA?
- Contenedores normales en mi propio cluster
- Un servicio administrado (E2B u otro)
- Dev Containers o un sandbox local
- Prefiero otra opción (cuéntanos cuál)
Comenta abajo o, si este artículo te llegó por correo, responde directamente al email: tu respuesta se publica aquí.
Relacionado: Los agentes de código necesitan sandboxing — no solo buenos prompts