AWS has launched Nitro Sandboxes, lightweight virtual machines managed by the Nitro Hypervisor, so an Amazon EKS pod, an Amazon ECS task or a lightweight VM—including AI agents running inside them—can sit in its own hardware-isolated environment on a customer’s EC2 instance. The What’s New post is dated 9 November 2026.
AWS says the sandboxes run “with near-native EC2 performance,” that enabling them in EKS or ECS is “a one-line change,” and that they are “available today on most nitro-based ec2 instances, in all commercial regions worldwide, at no additional charge.” Near-native is AWS’s claim with no accompanying benchmark in the launch materials. Coverage is “most” Nitro-based instances, not every SKU; operators still need the EC2 supported-instance list. Amazon Linux and Firecracker are natively supported; AWS says patches for other options are available today.
How EKS isolated and confidential pods use them
The Amazon EKS sandboxing guide makes the opt-in explicit: set runtimeClassName to isolated-sandbox or confidential-sandbox. Each opted-in pod runs inside a Nitro Sandbox implemented as a Firecracker microVM. The parent instance runs a shim that launches the sandbox; inside it, a guest agent manages containers through its own containerd.
AWS is careful about what isolation does and does not buy. “This isolation is a security boundary, not a performance reservation: a sandbox does not get dedicated physical cores.” vCPUs are time-shared and can be oversubscribed across sandboxes on a node. Isolated mode trusts the parent and aims to protect the node from a compromised workload; confidential mode treats the parent as untrusted and leans on attestation and tighter policy so secrets are released only to sandboxes that prove their integrity.
For untrusted or LLM-generated code that should not talk to the network, a pod annotation can boot the sandbox with no network device. Logs and exec can still travel over vsock, so AWS itself notes that this is not absolute isolation. Pod Identity, VPC CNI, EBS/EFS/S3 storage and CloudWatch are described as continuing to work without leaving the native EKS or ECS path.
Why agent runtimes keep converging on microVMs
The same day-to-day problem—running untrusted agent code beside other tenants without giving every session a whole machine—already shows up across vendors. TSN has covered Google’s Agent Compute Engine microVMs, AWS’s own Infinity agent runtime, and Google’s move of Agent Substrate and gVisor toward CNCF. Nitro Sandboxes put that pattern on the Nitro hardware path with a Kubernetes-native runtime class rather than a separate product brand.
AWS’s pitch for agents is utilisation: share one EC2 instance across multiple agentic workloads while still giving each pod a VM boundary. Cryptographic attestation is the hook for regulated or confidential paths, so KMS can gate decryption on PCR measurements rather than on node trust alone. That is the same class of problem other agent sandboxes try to solve with different hypervisors and policy engines; Nitro’s difference is the first-party EKS/ECS runtime-class path on customers’ own instances. For fleet operators the practical questions are which instance families sit outside “most Nitro,” how confidential-mode attestation policies behave under real KMS key policies, and whether network-isolated sandboxes become the default pattern for LLM-generated code.
Hardware isolation is cheap only if density still works
A free, one-line sandbox sounds like an easy security win. The durable constraint is density. If every pod becomes a Firecracker guest, the node still has a finite set of time-shared vCPUs and a startup cost for each sandbox. AWS’s own docs warn that isolation is not a core reservation and that oversubscription is allowed. That is the right honesty for operators sizing agent fleets: the security boundary is real; the performance story is still “near-native” as claimed, not proven in the launch post.
The useful next evidence is operational. Which instance families sit outside “most Nitro,” how confidential-mode attestation policies behave under real KMS key policies, and whether network-isolated sandboxes become the default pattern for LLM-generated code. Until those answers land in customer write-ups, treat Nitro Sandboxes as a first-party microVM runtime class on EC2—hardware-isolated, optionally attesting, and priced at zero—rather than as a measured performance product.
Sources
- AWS What’s New: Nitro Sandboxes on EKS, ECS and EC2 (9 November 2026)
- Amazon EKS User Guide: Sandboxing with isolated and confidential pods
Related stories
Google Cloud’s Agent Compute Engine is the nearest peer launch: another microVM path for packing AI agents without sharing a kernel with every neighbour.
Follow @tsnmediahub on X for breaking AI news as it happens.
Follow on X
