AWS Launches Nitro Sandboxes: Every EKS Pod and ECS Task Can Run in Its Own Hardware-Isolated VM, AI Agents Get One Sandbox per Session for Generated Code, With Attestation at No Extra Charge

Background and the problem it solves

Containers became popular because many of them share one Linux kernel on a host, which makes them light to deploy and efficient to pack. It also means one bug in the shared kernel can expose every container on the host, and cluster operators can see every task. AI agents make this sharper: agents write and run their own code, and after a prompt injection that code may be the attacker's. Until now, a hard boundary meant a dedicated instance per workload or a do-it-yourself setup with Firecracker or gVisor. In the past few days Google's Gemini self-hosted environments and NVIDIA OpenShell have also tackled where agent code runs and how it is isolated.

Architecture and how it works

A Nitro Sandbox is a lightweight VM that you launch and control from your EC2 instance. To the instance it looks like a child VM, but it actually runs alongside the instance on the Nitro Hypervisor, which enforces separation in hardware between the parent, between sandboxes, and from AWS operators. It reuses the isolation technology of Nitro Enclaves with three changes: vCPUs can time-share cores with the parent, the parent can attach standard virtio network and block devices instead of only a vsock channel, and sandboxes can run under standard VMMs such as Firecracker. Security groups and network policies are enforced on the parent outside the sandbox, so a compromised workload cannot turn them off. Confidential mode also produces an attestation document through the Nitro Secure Module, so KMS key policies can release secrets only after the code proves its identity.

Benchmarks and measured results

AWS has not published launch latency or performance benchmarks. It says compute and memory run at near-native EC2 performance and that Isolated mode launches faster than Confidential mode. The cost pitch is no additional charge plus better utilization, since many isolated workloads can be consolidated onto one instance.

Getting started

EKS: use EKS Auto Mode and add runtimeClassName: isolated-sandbox or confidential-sandbox to the pod spec; EKS handles instance selection and scheduling. Self-managed EKS needs a compatible AMI. ECS: enable nitroEnclavesEnabled on an ECS Managed Instances capacity provider, add a trustedExecutionConfiguration block to the task definition with isolationMode set to ISOLATED_SANDBOX or CONFIDENTIAL_SANDBOX, and use awsvpc networking. If you build your own platform, launch Nitro Sandboxes directly on EC2 with Firecracker, after enabling Nitro Enclaves when you launch the parent instance.