AWS Nitro Sandboxes Put Each EKS Pod Inside Its Own Virtual Machine
"AWS Nitro Sandboxes run each EKS pod in its own hardware-isolated VM through one runtime class field, with a confidential mode built on KMS attestation and an egress list declared per workl
TL;DR
- AWS Nitro Sandboxes is a feature of Amazon EKS, announced on 9 November 2026, that runs each Kubernetes pod inside its own lightweight virtual machine on the Nitro System, the same hardware layer that keeps EC2 instances apart.
- On EKS Auto Mode the whole opt-in is one pod field:
runtimeClassName: isolated-sandbox. Images, Helm charts and deployment pipelines stay as they are. - A second runtime class,
confidential-sandbox, treats the machine operator as untrusted and releases an AWS KMS secret only against an attestation document naming the expected system image and Cedar policy. - The boot sequence inside a Nitro Partition runs through the scheduler, a VM boot, an in-guest policy check and a standard container runtime, while the kubelet still sees an ordinary pod.
- Egress is declared per workload: the sample coding agent reaches Amazon Bedrock through Pod Identity and one GitHub repository through a scoped token, and an ApplicationNetworkPolicy allows only CoreDNS and HTTPS to those hostnames.
- Resources that stay shared on a packed node, including network bandwidth, disk I/O, DNS queries, log output and connection tracking, are protected by default with configurable throttles.
- The boundary is enforced in hardware and AWS reports every Kubernetes conformance test passing; standard EKS needs a sandbox-enabled AMI.
- Where the boundary stops: the egress policy matches hostnames, a name that resolves to the same addresses as an allowed one stays reachable, and node-level resources keep a shared path between tenants.
What one pod field adds to a cluster
Kubernetes containers share a host operating system kernel, which is what makes them cheap and fast to start and what makes one container's kernel bug a problem for every other container on the machine. The usual answer is a dedicated machine per sensitive workload, and that answer wastes most of the machine. AWS's launch post frames Nitro Sandboxes as the alternative: a pod that keeps its scheduling behaviour and gains a hardware boundary.
On EKS Auto Mode the runtime classes ship with every cluster, so there is nothing to install. kubectl get runtimeclass lists isolated-sandbox and confidential-sandbox, and a pod that sets one of them keeps the same Pod Identity credentials, EBS and EFS volumes, CloudWatch metrics and VPC CNI networking. AWS states that Nitro Sandboxes passes every Kubernetes conformance test.
The evidence that a pod landed in a VM is visible from inside. AWS's own example prints the value of /sys/class/dmi/id/product_name, which returns 8i.enclave inside a sandbox and shows block devices named vda, vdb and vdc where a regular pod on the same node sees nvme0n1, nvme1n1 and zram0.
Isolated mode and confidential mode
The two runtime classes answer different questions. Isolated mode protects the host and the neighbouring pods from whatever runs inside the container, which is the case for agent workloads, multi-tenant SaaS and privileged build jobs. Confidential mode adds a threat model in which the person operating the cluster counts as untrusted: cryptographic attestation proves the exact code inside the sandbox, and AWS Key Management Service releases a secret only when presented with an attestation document that covers the system image and the configured Cedar policy.
That second mode is the one to read carefully in a regulated context. Healthcare work under HIPAA, card payment work under PCI DSS and public sector work under FedRAMP increasingly ask for evidence that a workload ran untampered, and an attestation document supplies cryptographic evidence about the workload's state. AWS also states the design prevents a cluster administrator from reading the pod's memory, which changes who can be given cluster-admin rights on a shared platform.
The boot sequence inside a Nitro Partition
The mechanics are short enough to follow in five steps, and each one leaves the Kubernetes API untouched. The scheduler places the pod as usual, and the RuntimeClass carries the node selector and toleration, so on Auto Mode a pod lands on a sandbox-capable node without extra spec fields. Amazon EKS then asks EC2 for a Nitro Partition and boots a lightweight VM inside it, and from that point the Nitro Hypervisor enforces the CPU and memory boundary in hardware.
Inside the guest, a component receives the pod spec and its Cedar policy, checks that what is about to run is what the policy allows, pulls the images and starts the containers under a standard container runtime. Logs, exec, port-forward, probes and metrics flow back to the kubelet over an internal control channel, and Pod Identity credentials, CSI volumes and VPC networking arrive in the VM the way they reach a regular pod.
The egress list a coding agent receives
The most useful part of the post is a worked example that runs a coding agent inside a sandbox. The agent reads a GitHub issue, writes a fix, runs the tests and opens a pull request, and the entire security model is visible in what the pod declares. Model access is an IAM role scoped to bedrock:InvokeModel* through Pod Identity, with no long-lived API keys. Repository access is one short-lived fine-grained token mounted as a Secret, limited to Contents and Pull requests read and write plus Issues read, on a single repository.
Everything else is refused. An EKS Auto Mode ApplicationNetworkPolicy allows egress only to CoreDNS and to HTTPS on the Bedrock and GitHub hostnames, which matters because a standard Kubernetes NetworkPolicy cannot match hostnames. AWS notes that the policy is enforced once the amazon-vpc-cni ConfigMap in kube-system sets enable-network-policy-controller: "true", and that the sample relies on a GitHub App token if the pull request should show a bot author.
What stays shared on a packed node
Packing isolated pods onto one node raises the noisy-neighbour question, and AWS answers it in two layers. CPU and memory are carved out in hardware per sandbox, so neither the EC2 host nor a neighbouring pod can read or touch that slice. The rest of a node is shared by design: network bandwidth, disk I/O, DNS queries, log output and connection tracking entries all pass through the same kernel, and AWS applies configurable throttles to each by default so a runaway agent hits its own ceiling first.
That default matters more than the field itself. These default throttles address the risk that one tenant could saturate the node's network while sitting inside its own VM. AWS ships the throttles on, which sets a floor that a platform team can then raise per workload.
Where the boundary stops
Two limits deserve to sit next to the launch. The first is the hostname-based egress policy: a name that resolves to the same addresses as an allowed one is reachable, so a CDN or a shared cloud endpoint in front of an allowed service widens the path. The second is that the boundary is per pod, and on standard EKS AWS directs users to build an AMI for Nitro Sandboxes before using the feature.
Tenancy economics are the part that will decide adoption. A SaaS platform that today dedicates an EC2 instance per customer can bin-pack those tenants onto one node with a VM each, and the platform team keeps the same Cluster API objects it already manages. AWS names the supporting pieces: the SIG project agent-sandbox for warm pools that keep pre-booted VMs ready to claim in about two seconds, Temporal driving sandboxes as a compute provider, and remote IDE sessions that give each developer a VM they cannot escape.
A conformance check for the isolation claim
A team can verify the isolation claim without trusting the marketing: run a pod with runtimeClassName: isolated-sandbox, print /sys/class/dmi/id/product_name and the block device list, and compare the output with the same commands in a regular pod on the same node. A reading of 8i.enclave and vda where the other pod shows nvme0n1 is direct evidence the container sits in a VM.
The second check is the policy. Set the annotation sandbox.amazonaws.com/network-isolated: "true" and confirm the VM boots with loopback as its sole interface, then remove it and confirm the egress list behaves as declared. Those two checks turn a vendor claim into a repeatable test that a platform team can run after every node image update, which is where isolation properties usually drift.
For estates that run this on their own hardware or move between clouds, the same question about kernel-level blast radius shapes the architecture review, and the same question also applies to sovereign infrastructure and cloud exit projects. A runtime class is one more property to test the same way.
Nitro Sandboxes moves a security control from a patched shared kernel to a hardware boundary that a pod opts into with one field. The engineering question it leaves is the one AWS states plainly in its own sample: the boundary contains what a workload can reach, and the reach itself is still a list someone has to write.
Sources
Source: the AWS Containers Blog announcement of 9 November 2026 by Carlos Santana and Trishi Mehta, retrieved 14 November 2026. That page carries the runtime class names, the two modes, the boot sequence, the coding agent sample, the egress policy details, the shared-resource throttles and the conformance statement quoted above.