AWS Nitro Sandboxes on EKS: isolated or confidential pods

AWS made Nitro Sandboxes available on Amazon EKS, Amazon ECS and EC2 on November 9, 2026. Each opted-in pod or task now runs in its own hardware-isolated virtual machine on a shared instance, at no additional charge. On EKS, the choice comes down to one pod-spec field: runtimeClassName: isolated-sandbox when you trust the node but not the code, or confidential-sandbox when the node itself is outside your trust boundary.

That choice matters most for teams running AI agents that write and execute code. AWS names that use case directly. A standard EKS node shares one Linux kernel across its pods, so a container escape or kernel bug can expose one workload to another. Nitro Sandboxes replace that shared kernel with a VM boundary per pod, but confidential mode's guarantees are incomplete until a KMS key policy or another external verifier checks the attestation.

What are AWS Nitro Sandboxes?

A Nitro Sandbox is a lightweight VM that runs alongside your workload on an EC2 instance and is isolated by the Nitro hypervisor. The EC2 user guide says Nitro isolates each sandbox "from the parent instance, from other Nitro Sandboxes, and from AWS operators."

The AWS announcement lists three ways to use it:

• Amazon EKS: each pod that opts in gets its own sandbox. AWS calls enabling it "a one-line change" and says Pod Identity, VPC CNI, EBS, EFS, S3 storage and CloudWatch keep working.
• Amazon ECS: isolated and confidential tasks are a capability of ECS Managed Instances, which AWS compares to the isolation of Fargate while keeping instance-type choice and bin-packing.
• EC2 directly: you run your own orchestrator and a virtual machine monitor. AWS recommends Firecracker and says Amazon Linux and Firecracker are supported natively.

AWS says the feature runs on "most nitro-based ec2 instances, in all commercial regions worldwide, at no additional charge," with near-native EC2 performance. The sandboxes run on your own EC2 instances, and the announcement does not address instance pricing.

How do isolated-sandbox and confidential-sandbox differ?

The two EKS runtime classes answer different threat models. Isolated mode protects the node and other pods from your workload. Confidential mode protects your workload from the node. The EKS sandboxing guide describes both:

Scroll sideways to see all 3 columns.

Comparison dimension	isolated-sandbox	confidential-sandbox
Trusted party	The node (parent instance)	Only the sandbox itself
Protects against	A compromised container reaching the node or other pods	A node operator or compromised node reading workload data
exec, logs, process listing	Allowed	exec, stdin and process listing denied
Admission policy	Accepts any valid container spec	Pins image digests, args, environment variables, mounts and capabilities
AWS credentials	Pod Identity, IMDS and NTP allowed	IMDS and service account token allowed, for KMS calls
Extra setup	No KMS key-policy work required	KMS key policies with attestation conditions

Every sandboxed pod also gets a Cedar policy, generated from the pod spec, that controls which images load and whether exec and logs are permitted. The sandbox enforces it inside the guest, so it holds even when the node is not trusted.

Confidential pods need a KMS key policy

Confidential mode is incomplete until something checks the attestation. The EKS guide is blunt: without a KMS key policy or another external verifier that checks the sandbox's measurements, "the attestation measurement is recorded but never verified, and the confidentiality guarantees of confidential mode are incomplete." AWS tells you to add kms:RecipientAttestation:PCR<PCR_ID> conditions to every KMS key that protects confidential data.

The split of duties is spelled out too. AWS owns the hypervisor, the sandbox boundary and the guest system image. You own container images, Cedar policies, KMS key policies and application code.

BaristaLabs interpretation: switching the runtime class to confidential-sandbox without touching KMS gives you the stricter admission rules and the lost exec access, but not the guarantee that secrets only reach verified code. Treat the key policy change as part of the same deployment, not a follow-up ticket.

What limits apply to sandboxed pods?

Pods that avoid the affected features run unchanged, but a sandbox is a VM, and some Kubernetes behavior changes. The EKS considerations page lists the ones most likely to bite an agent platform:

• No GPUs. GPU and device passthrough are not supported at launch. AWS's workaround is to run pods that need a GPU without a sandbox runtime class.
• CPU is shared, not reserved. AWS calls the isolation "a security boundary, not a performance reservation." On instance types with two threads per core, sandboxed pods get roughly half the advertised vCPUs, and AWS suggests requesting CPU in multiples of two. Graviton instances are not affected.
• Density caps. Total sandbox vCPUs on a node cannot exceed five times the node's vCPU count, and AWS says memory usually runs out first.
• Network defaults. hostNetwork: true pods fail to start. Each pod defaults to 100 DNS queries per second and 4,096 simultaneous outbound connections per IP family, both adjustable with annotations.
• IMDS is mostly gone. Only a few placement and service paths answer. Credentials come from EKS Pod Identity, not IMDS.
• No in-place resize. CPU and memory are fixed at boot; recreate the pod to change them.
• Instance types. Only types that support Nitro Enclaves qualify, and the EC2 list excludes the smallest sizes in most families (for example m7i.large) and most metal sizes.

How to run generated code with no network

For agent code that should never talk to the network, EKS offers a separate pod annotation: sandbox.amazonaws.com/network-isolated: "true". The network isolation page says the sandbox then boots with no network interface, no DNS, no IMDS and no Pod Identity credentials. Logs and exec still work over a vsock channel.

Two details change how you build around it. HTTP and TCP probes cannot succeed, so you need exec probes. And AWS says the vsock channel is reachable from inside the guest, "so this is not absolute isolation." Our post on OpenAI's microVM escape findings shows why that kind of side channel deserves an audit rather than an assumption.

Who should switch agent pods now?

BaristaLabs recommendation: if you already run EKS and your agents execute model-generated code in pods that share nodes with other workloads, move those pods to isolated-sandbox first. It needs no key-policy work and keeps your normal debugging tools.

Use confidential-sandbox when the data inside the pod must be protected from whoever administers the node, such as a third-party model or regulated customer data, and only together with the KMS conditions above.

Wait if your agent pods need GPUs, hostNetwork, or in-place resizing, or if your nodes are instance types the EC2 list excludes. Teams not on EKS or ECS have other options from AWS's own guidance: Nitro Enclaves for small, tightly scoped jobs, and Lambda MicroVMs if you don't want to manage servers. Local coding agents are a different boundary again, covered in our post on Docker Sandboxes and host-side MCP servers.

Recommended first step: one agent workload, isolated mode

BaristaLabs recommendation: run one week of a single agent workload in isolated-sandbox before touching anything else.

1. Pick one agent pod that runs generated code and does not need a GPU.
2. Check the node group's instance type against the EC2 supported list, and set CPU requests in multiples of two on SMT instances.
3. Set runtimeClassName: isolated-sandbox and replace any HTTP or TCP probes if you also add the network-isolation annotation.
4. Watch DNS and connection limits on agents that fan out to many APIs, and raise the annotation values for agents that hit them (AWS suggests raising network limits before you benchmark).
5. Plan confidential mode separately, starting with the KMS key policy, if the workload handles secrets you need to hide from node operators.

AWS's getting-started page points to runnable blueprints for AI coding agents, warm pools and CI runners. For help scoping agent infrastructure on AWS, see AI consulting.

Sources and scope

• Introducing AWS Nitro Sandboxes on Amazon EKS, ECS and EC2, AWS What's New, November 9, 2026
• Isolate workloads with AWS Nitro Sandboxes, Amazon EC2 User Guide, retrieved November 9, 2026
• Sandboxing on Amazon EKS with isolated and confidential pods, Amazon EKS User Guide, retrieved November 9, 2026
• Considerations and Network isolation, Amazon EKS User Guide, retrieved November 9, 2026
• Isolated and confidential tasks, Amazon ECS Developer Guide, retrieved November 9, 2026

BaristaLabs did not run Nitro Sandboxes on a test cluster for this post. Performance, limits and availability come from AWS's announcement and documentation as of November 9, 2026, and these sources give no benchmark figures beyond "near-native." Lines marked BaristaLabs interpretation or recommendation are BaristaLabs' views, not AWS's.