Nitro Sandboxes put each EKS pod, ECS task or lightweight VM in its own hardware-isolated virtual machine on a shared instance, at no additional charge. The isolation is real and the documentation is unusually precise about its edges — which is where the useful reading is.
“The Nitro System isolates the compute and memory of each Nitro Sandbox, but the parent instance's network stack is a shared, per-instance resource.”
Executive summary
“An AWS Nitro Sandbox is a lightweight virtual machine, or child VM, that you can run alongside your workload on almost any Amazon EC2 instance.” The boundary is the one that already separates EC2 instances from each other: “Nitro isolates each Nitro Sandbox from the parent instance, from other Nitro Sandboxes, and from AWS operators.”
The problem it solves is stated plainly in the EKS guide: “In a standard Amazon EKS cluster, pods on the same node share a Linux kernel. A container escape or kernel vulnerability can expose one workload to another.” Each sandboxed pod gets “a dedicated hardware-isolated environment with its own Linux kernel” instead.
That is a significant capability, and it arrives “at no additional charge”. What follows is what the charge-free part does not cover: a shared network stack, a vCPU budget, memory that cannot be overcommitted, and an availability scope narrower than the headline.
What changed
Three surfaces at once. On EC2 it is a primitive you drive yourself with a VMM — Firecracker is the
recommended one. On EKS and ECS it is managed: for EKS,
“Isolated and confidential pods are opt-in. You select the feature per pod by setting
runtimeClassName to isolated-sandbox or confidential-sandbox in
the pod spec.”
Two modes, and the difference is the trust direction. Confidential mode is the default and moves the sandbox's memory out of the parent's reach, with attestation. Direct mode does not: “The parent shares the Nitro Sandbox's memory instead of taking exclusive ownership of it. There is no attestation, and the parent retains access to the Nitro Sandbox's memory.” AWS is direct about what that leaves you with — “Its trust model is equivalent to a standard nested virtual machine.”
So the phrase hardware-isolated covers two quite different guarantees depending on a mode you choose at creation and cannot change while it runs.
Architecture
What is isolated, and what is shared
| Resource | Isolated? | What AWS says |
|---|---|---|
| Memory | Yes, in confidential mode | Moved out of the parent instance; the parent can't read it |
| CPU | Yes, as a boundary | “a security boundary, not a performance reservation” |
| Kernel | Yes | “its own Linux kernel”; shares no kernel with the parent or other sandboxes |
| Network stack | No | “a shared, per-instance resource” |
| Device limit | No | “the Nitro Sandboxes share the instance's overall device limit” |
The network row is the one worth acting on, and AWS spells out the consequence: “A single Nitro Sandbox can exhaust parent-side resources, such as the connection-tracking (conntrack) table or the DNS resolver budget, and deny network access to other Nitro Sandboxes on the same instance.”
So the threat model holds for confidentiality and integrity and does not hold for availability. A sandboxed tenant cannot read another tenant's memory; it can starve that tenant of network. For the headline use case — running untrusted or LLM-generated code — that is precisely the kind of misbehaviour you should expect, intentional or not.
And the mitigation is explicitly yours: “As the parent operator, cap or rate-limit these resources for each Nitro Sandbox.” On self-managed EC2 you are the parent operator. On EKS and ECS the managed integration provisions the sandbox, which makes this a question worth asking of those integrations rather than assuming.
Free of charge, bounded in capacity
“To maintain near-native Amazon EC2 performance, the total vCPUs allocated across all Nitro Sandboxes on an instance can't exceed 5 times the instance's vCPU count.” With the worked example: “For example, on a 4-vCPU instance the budget is 20 vCPUs.” That is twenty single-vCPU sandboxes, or ten at two vCPUs each — larger sandboxes buy fewer of them.
Memory is the harder constraint because it cannot be oversubscribed: “The parent donates a Nitro Sandbox's full memory when the Nitro Sandbox starts, and that memory stays reserved until the Nitro Sandbox terminates. Nitro Sandbox memory isn't overcommitted.” An idle sandbox holds its full allocation. For agent sessions that sit waiting on input, that is the number that decides density.
Neither can be adjusted in place: “You can't change a Nitro Sandbox's vCPU and memory allocation during the life of the Nitro Sandbox.” Resizing means terminating and re-creating.
The two CPU stories are different, and that is deliberate
On self-managed EC2, each sandbox vCPU takes a dedicated physical core from the Nitro Enclaves CPU pool by default, unless you enable CPU overcommit. On EKS the managed integration states the opposite default: “This isolation is a security boundary, not a performance reservation: a sandbox does not get dedicated physical cores. vCPUs are time-shared across the sandboxes on a node, and total sandbox vCPU allocation can oversubscribe the node's vCPUs.”
Both are reasonable for their context, and reading one and assuming the other is how a capacity plan goes wrong. If you are sizing EKS nodes for sandboxed pods, the EKS sentence is the one that applies.
Availability is three different answers
| Surface | Where it is available |
|---|---|
| The announcement's headline | “most Nitro-based EC2 instances, in all commercial regions worldwide” |
| The EC2 primitive | Only instance types that support Nitro Enclaves — “If an instance type can't run Nitro Enclaves, it can't run Nitro Sandboxes” |
| EKS isolated and confidential pods | “available in the US commercial AWS Regions”, requiring “Kubernetes version 1.36 or later” |
The gap between row one and row three is the one to check before planning. All commercial regions worldwide describes the EC2 primitive; the EKS integration most readers will reach for first is US commercial Regions only, on a Kubernetes version that is itself recent. The announcement is not wrong — it is scoped to the primitive, and the integration guides carry their own scope.
One more exclusion matters for the stated use case: “GPU passthrough into a Nitro Sandbox is currently unavailable.” Sandboxing an AI agent that generates and runs code works; sandboxing one that needs a GPU for local inference does not, yet.
Business value
The value is density at a VM boundary. Previously, giving a tenant a hardware boundary meant giving it an instance. AWS frames it as: use a sandbox “when you need a boundary as strong as a virtual machine around a container-scale workload, but you don't want the cost of a separate Amazon EC2 instance for each workload or the overhead of nested virtualization.”
For multi-tenant platforms that is a genuine change in what is affordable. A per-tenant VM boundary at container density, with no per-sandbox charge, removes the economic argument for sharing a kernel between tenants — which has been the standard compromise and the standard source of escape risk.
The attestation half is the part regulated workloads will care about more: “a workload can prove that it is running unmodified code before it receives secrets”, gated through a KMS key policy. That is a stronger claim than isolation alone, and it comes with the condition in the next section.
Security considerations
Confidential mode's guarantee is incomplete until you add the KMS condition. The EKS guide states it as a warning rather than a footnote: “Without a KMS key policy (or equivalent external verifier) that checks PCR values, the attestation measurement is recorded but never verified, and the confidentiality guarantees of confidential mode are incomplete.”
So running in confidential mode produces an attestation; it does not by itself cause anything to check
it. The check is a kms:RecipientAttestation:PCR condition you write on the key policy
protecting the data. Measured-but-unverified is the same shape as the previous two posts in this series:
an artefact that exists and asserts nothing until something compares it.
Network isolation is not absolute, and says so. A pod annotated
sandbox.amazonaws.com/network-isolated boots with no network device at all, which is
stronger than filtering. But: “The vsock channel inside the guest can still reach guest-bound
ports, which bypasses the absent network device, so this is not absolute isolation.”
The shared responsibility line is drawn narrowly.
“AWS is responsible for the Nitro hypervisor, the Nitro Sandbox boundary, and the guest system
image. Customers are responsible for their container images, Cedar policies, AWS KMS key policies, and
application code.” The Cedar policy controlling container admission, exec and
mounts is yours, and in confidential mode it is the thing that stops an untrusted parent substituting a
different workload.
Direct mode is not a confidentiality boundary — from the parent. If the sandbox and parent are operated by the same party that is fine and faster. If you reach for Nitro Sandboxes to isolate a tenant from yourself, direct mode does not do it. Worth being precise about what the mode does not weaken: sandbox-to-sandbox isolation is stated unconditionally — “Nitro Sandboxes are isolated from each other and from the parent instance. No matter what runs inside a Nitro Sandbox, it can't access another Nitro Sandbox or the parent.” So the mode choice changes what the parent can see, not what a neighbouring tenant can.
Cost considerations
“at no additional charge” is accurate and worth reading as a statement about the line item rather than about the bill. You pay for the instance; the sandboxes are free. What they consume is instance capacity, and the capacity rules are strict enough to change instance sizing.
The binding constraint will usually be memory, because it is dedicated for the life of each sandbox and not overcommitted. A platform running many small, mostly-idle agent sessions pays for their peak allocation continuously. The vCPU budget of five times the instance count is generous by comparison, and the device limit shared across sandboxes is the one that bites when each sandbox wants its own EBS volume.
Against that, the alternative being replaced is an instance per tenant. Even with conservative density, a sandbox-per-tenant model on fewer, larger instances is the cheaper shape — which is the actual economic argument and does not depend on the feature being free.
Operational considerations
Probes change for network-isolated pods.
“kubectl port-forward does not work, and kubelet HTTP or TCP probes cannot
succeed. Use exec probes for pods with this annotation.” That is a deployment manifest change,
and a readiness probe that silently never succeeds is a rollout that hangs.
Introspection differs by mode. In isolated mode the parent keeps
exec, stdin, logs, stats and process listing. In confidential mode
exec, stdin and process listing are denied by design, so the parent cannot
look inside. Debugging a confidential workload is a different activity from debugging a normal pod, and
worth rehearsing before you need it.
Resizing means replacing. vCPU and memory are fixed for a sandbox's life, so vertical scaling is a terminate-and-recreate operation. For pods that is ordinary; for a long-lived agent session holding state, it is not.
The device budget is per instance, not per sandbox. Hot-plugged devices count toward it too, and you cannot hot-unplug. Plan the per-sandbox device allowance before packing an instance.
Tradeoffs
| Choice | What you gain | What it costs |
|---|---|---|
| Confidential mode | Memory out of the parent's reach, plus attestation | No exec or process listing, no entropy device, and the KMS condition is still yours to write |
| Direct mode | Simpler, higher I/O throughput | No attestation, parent retains memory access — a nested-VM trust model |
| Sandbox per tenant | A VM boundary without an instance per tenant | Dedicated non-overcommitted memory per sandbox, and a shared network stack |
| Shared kernel, as today | Maximum density, no new moving parts | The container-escape exposure the feature exists to remove |
| Network-isolated pods | No network device at all, not merely filtered | No port-forward, no HTTP or TCP probes, and vsock still reaches guest-bound ports |
Implementation guidance
Check the Region and Kubernetes version before designing around EKS sandboxes. US commercial Regions only, Kubernetes 1.36 or later. This is the step that decides whether the rest is relevant this quarter.
Confirm your instance types support Nitro Enclaves. That is the hard gate, and the
exclusions are mostly the smallest size in each family and the bare-metal variants — so a fleet
standardised on large instances may need to move up a size.
Decide the mode from the trust direction, not from performance. Isolated mode protects the node from the workload. Confidential mode protects the workload from the node. They answer different questions and only one of them survives an untrusted parent.
If you choose confidential mode, write the KMS key policy condition in the same change. Attestation without a verifier is the documented incomplete case, and it will not announce itself.
Cap per-sandbox network resources from the start. Conntrack entries and DNS resolver budget are the named exhaustion paths. On self-managed EC2 this is explicitly your job; on EKS and ECS, establish what the integration already does before relying on it.
Size memory first, then count sandboxes. Memory is dedicated and not overcommitted, so it, not the five-times-vCPU budget, will usually set density.
Best practices
Treat hardware-isolated as a claim about confidentiality and integrity, not availability. The documentation supports the first two and explicitly withholds the third for the network stack.
Keep the Cedar policy under the same review as the container image. It controls admission,
exec, logs and mounts, it is measured into the attestation, and it is on the customer side
of the shared responsibility line.
Prefer S3, EFS or another network store for anything shared between sandboxes. A block device “attaches to only one Nitro Sandbox at a time”, and mounting one volume from two sandboxes corrupts the filesystem.
Where a sandbox is meant to be isolated from your own operators, remember that storage isolation is a separate decision: encrypt with a KMS key whose policy releases the data key only to a matching attestation.
Who should adopt this and when
Adopt now if you run untrusted or tenant-supplied code on shared instances and have been accepting shared-kernel risk because per-tenant instances were too expensive. This is the feature that removes that trade-off, and it is free of charge.
Adopt now if you are building agent infrastructure that executes model-generated code. AWS names it as a use case, and a per-session VM boundary is the right shape for code nobody reviewed.
Evaluate carefully if your isolation requirement includes availability between tenants. The shared network stack means one sandbox can deny network to its neighbours, and you will need to cap that yourself.
Wait if you need GPU passthrough, if you are outside US commercial Regions for the EKS path, or if your clusters are below Kubernetes 1.36.
Key takeaways
The isolation claim is strong and precisely bounded. Compute and memory are isolated from the parent, from other sandboxes and from AWS operators, each sandbox has its own kernel, and in confidential mode the parent cannot read the memory. That is a VM boundary at container density for no extra charge.
The two edges to carry away are in the documentation rather than the announcement. The parent's network stack is shared, and one sandbox can exhaust it to the detriment of the others, with the capping left to you. And confidential mode's attestation is recorded but unverified until you add a KMS key policy condition that checks it.
Plus the scope: all commercial regions worldwide is the EC2 primitive. The EKS integration is US commercial Regions and Kubernetes 1.36 or later, and GPU passthrough is not there yet.
Official AWS references
- Introducing AWS Nitro Sandboxes on Amazon EKS, ECS and EC2 — the announcement: hardware-isolated pods, tasks and VMs, availability on most Nitro-based EC2 instances in all commercial Regions, and no additional charge
- Isolate workloads with AWS Nitro Sandboxes — the definition and isolation boundary, confidential and direct modes and their trust models, the shared parent network stack and the conntrack and DNS exhaustion paths, the five-times-vCPU budget with the 4-vCPU worked example, non-overcommitted memory, the shared device limit, the Nitro Enclaves instance-type gate, fixed sizing, and the unavailability of GPU passthrough
- Sandboxing on Amazon EKS with isolated and confidential pods — the shared-kernel problem it addresses, the
runtimeClassNameopt-in, US commercial Regions and Kubernetes 1.36 availability, isolation as a security boundary rather than a performance reservation with time-shared vCPUs, the warning that attestation is recorded but unverified without a KMS PCR condition, that network isolation is not absolute because of vsock, the probe and port-forward limitations, and the shared responsibility split - Isolated and confidential tasks on Amazon ECS — the ECS side of the managed integration; no claims in this post are drawn from it
- AWS Nitro Enclaves — the foundation Nitro Sandboxes build on, and the narrower vsock-only alternative for tightly scoped jobs; no claims in this post are drawn from it
Comments