AWS Nitro Sandboxes on EKS vs. Daytona, E2B and Modal: Which Agent Sandbox to Pick

Key points:

• AWS Nitro Sandboxes launched on 9 November 2026. Each EKS pod, ECS task or EC2 workload that opts in gets its own lightweight VM with its own kernel, isolated by the Nitro hypervisor. On EKS you opt in with one line, runtimeClassName: isolated-sandbox. It costs nothing beyond the EC2 instance and is available in all commercial regions (AWS What's New).
• It is a building block, not a sandbox product. You get the isolation boundary. You still own the cluster, the nodes, the API your agents call, warm pools, idle timeouts and cleanup. Daytona, E2B, Modal and Vercel sell all of that as an SDK call.
• The strongest reason to pick it is where the code runs. The sandbox lives in your VPC, under your IAM, next to your data, billed on instances you may already have committed spend on. Among hosted vendors, only E2B (Enterprise), Daytona (Enterprise), Northflank and Runloop (Enterprise) offer anything similar.
• Day-one gaps: Kubernetes 1.36 or later, no GPU passthrough, no snapshot or live migration, no published cold-start numbers, and outside EKS Auto Mode you need a sandbox-enabled node AMI.
• Pick a hosted sandbox for sub-second creation, pause and resume with memory, GPUs or a small team with no platform engineer. Pick Nitro Sandboxes when compliance, data residency or AWS spend commitments decide, and you already run EKS.

Until this week, if you wanted VM-grade isolation for untrusted code on EKS, you had three options. You could run Kata Containers with nested virtualization on the few instance families that allow it, run gVisor and accept its syscall compatibility gaps, or send the code to a hosted sandbox like E2B or Daytona outside your account. AWS just added a fourth, and it is the first one built into the platform.

I run Qovery, which deploys workloads on EKS clusters in our customers' own AWS accounts, so the question "can the sandbox live in our cluster now?" landed on my desk the morning after the launch. This post is my launch-week read of the AWS docs, compared side by side with the sandbox vendors our customers actually use. All facts were checked on 10 November 2026. No independent benchmarks exist yet, so I mark every number that comes from a vendor.

What did AWS launch on 9 November 2026?

AWS Nitro Sandboxes are lightweight VMs that run next to your workload on an EC2 instance. AWS describes each one as "a lightweight virtual machine, or child VM, that you can run alongside your workload on almost any Amazon EC2 instance" (EC2 User Guide). The parent instance donates vCPU and memory, and the Nitro hypervisor, the same one that separates EC2 instances from each other, enforces the boundary.

Three surfaces use it:

On EKS and ECS, the sandbox is a Firecracker microVM that runs on Nitro instead of KVM. Inside it, an agent runs its own containerd and starts your containers. kubelet, logs, exec and metrics keep working through a shim on the node (EKS User Guide).

How does a Nitro Sandbox work on EKS?

You pick one of two modes per pod.

Isolated mode (isolated-sandbox) trusts the node and distrusts the pod. It protects the node and the other pods from a container that has been compromised. That is the mode for agent-generated code, CI jobs and multi-tenant workloads. exec, logs and stats stay available, and no policy is required: "Without one, the sandbox applies a permissive built-in default that allows all containers and operations" (EKS docs).

Confidential mode (confidential-sandbox) distrusts the node. Memory is moved out of the parent's reach, exec and stdin are denied, and the sandbox produces a signed attestation of the code and policy it runs. You gate AWS KMS keys on those measurements, so secrets only reach a pod running the exact image and policy you approved. Confidential pods need a Cedar policy, generated with eks-nitro-sandbox-genpolicy in your CI and attached as a pod annotation.

The isolated pod from the docs is the whole integration:

apiVersion: v1
kind: Pod
metadata:
  name: my-app
spec:
  runtimeClassName: isolated-sandbox
  containers:
  - name: main
    image: public.ecr.aws/amazonlinux/amazonlinux:2023
    command: ["sleep", "3600"]
    resources:
      limits:
        cpu: "1"
        memory: 512Mi

For code that should never touch the network, add the annotation sandbox.amazonaws.com/network-isolated: "true". The VM then boots with no network device at all: no DNS, no IMDS and no Pod Identity credentials. AWS warns that a vsock channel remains, so "this is not absolute isolation" (network isolation docs).

Every sandbox also gets per-pod throttles by default: 100 Mbit/s and 1,500 packets per second each way, 100 DNS packets per second and a 4,096-entry conntrack limit. Those defaults exist because the node's network stack is shared, and one noisy sandbox could otherwise starve its neighbours. You raise them with sandbox.amazonaws.com/ annotations (resource isolation docs).

What does it not do yet?

The launch is solid but young. These are the limits that matter for an agent platform, all from the EKS considerations page unless noted:

• Kubernetes 1.36 or later. Many production clusters are not there yet.
• Node setup outside Auto Mode. On EKS Auto Mode, the runtime classes ship with every cluster and nodes are provisioned on demand. With managed node groups or Karpenter, you need nodes with Nitro Enclaves enabled and an AMI that carries the sandbox runtime (AL2023 with kernel 6.18.51 or later, the shim, Firecracker 1.18 and a guest image).
• No GPU passthrough. "GPU passthrough into a Nitro Sandbox is currently unavailable" (EC2 docs).
• No pause and resume with memory, no snapshot, no live migration, no in-place resize. A sandbox lives and dies with its pod.
• Memory is dedicated. Each pod reserves 256 MiB of overhead in isolated mode (512 MiB in confidential mode), and sandbox memory is never overcommitted. AWS says "Memory limits are typically the binding constraint" on density. vCPUs can be oversubscribed up to 5x the node's count.
• Intel and AMD halve the CPU you think you have. On SMT instances, core scheduling bounds a sandbox to physical cores, "roughly half the advertised vCPUs". AWS recommends requesting CPU in multiples of 2. Graviton is not affected.
• Instance types. Only instances that support Nitro Enclaves, which excludes the smallest size (.large or .medium) and the .metal size of most families.
• No published cold start. The AWS launch blog says a warm pool built on the Kubernetes agent-sandbox project "keeps pre-booted VMs ready to claim in about two seconds" (AWS blog). A test log in the AWS sample repository shows a warm claim ready in 0.967 seconds against 5 to 6 seconds cold (aws-samples). Treat both as observations, not a service level.
• Isolation does not shrink IAM. A sandboxed pod that runs with a broad Pod Identity role still holds that role. Give each sandbox a role scoped to what its code needs, or none at all.

How does it compare with Daytona, E2B and the other sandboxes?

The hosted products sell a finished sandbox: an SDK call creates one, and the vendor runs the fleet. Nitro Sandboxes give you the isolation primitive inside your own cluster. That framing explains most of the table.

Sources: Daytona, E2B, Modal, Vercel, Cloudflare, Northflank, Lambda MicroVMs, GKE.

A few things changed in 2026 that older comparisons miss:

• Daytona is no longer open source. It announced the move in June 2026, and its GitHub repository was archived on 3 October 2026. Self-hosting now means BYOC runners under Daytona's control plane (GitHub).
• E2B is the open-source option. Its runtime is Apache-2.0. The free self-hosted edition is single-node; multi-node BYOC on AWS, GCP and Azure is Enterprise only (E2B).
• AWS now has two sandbox products. Lambda MicroVMs (June 2026) is the serverless one: AWS runs the fleet, you call an API. Nitro Sandboxes is the one you schedule yourself. AWS's own docs point teams that "don't want to manage servers or networking" to Lambda MicroVMs.

What does a sandbox cost on each?

The pricing models differ, so here is one workload priced everywhere: a 2 vCPU / 4 GiB sandbox busy for one hour, at list prices on 10 November 2026.

The Nitro figure is the cheapest by a wide margin, and it is also the one with the most conditions attached. It assumes your nodes stay full. An idle node is yours to pay for, and the hosted vendors absorb that cost for you. It excludes the EKS control plane ($0.10 per hour per cluster) and, on Auto Mode, a management fee per instance (EKS pricing). It also excludes the engineering time to run the API, warm pools and cleanup that the vendors include. The math tips toward Nitro Sandboxes at steady, high volume, or when the spend counts against an AWS commitment you already signed.

When should you choose Nitro Sandboxes over a hosted sandbox?

Choose Nitro Sandboxes on EKS when:

• The code touches data that must not leave your AWS account: customer repositories, regulated records, internal systems behind your VPC.
• Security review would block a new vendor in the data path, and "it is an AWS feature on our existing EKS cluster" passes.
• You need attestation. Confidential mode can prove to KMS which image and policy a pod runs before it gets a secret. No hosted sandbox in this comparison offers that.
• You run enough sandboxes to keep nodes busy, or you have committed AWS spend to burn down.
• You already operate EKS and have someone who owns it.

Choose a hosted sandbox when:

• You need creation in milliseconds, or pause and resume with memory, today.
• The agent needs a GPU.
• You run a few hundred sandboxes a day and nobody on the team wants to own node pools, AMIs and warm pools.
• You are not on AWS.

Many teams will end up with both: a hosted sandbox for the agent's fast inner loop, and Nitro Sandboxes for the jobs that touch private data. The two answer different security questions.

Can you run Nitro Sandboxes on a cluster that Qovery manages?

Not yet, and here is exactly why. Qovery runs EKS clusters in your own AWS account, with Karpenter for node provisioning. Two things stand in the way today:

• Kubernetes version. Nitro Sandboxes need Kubernetes 1.36 or later, and Qovery-managed EKS clusters run up to 1.35.
• Node provisioning. Qovery-managed clusters do not use EKS Auto Mode, so the zero-setup path does not apply. The self-managed path needs nodes with Nitro Enclaves turned on, and Karpenter only exposes that setting (enclaveOptions on EC2NodeClass) since version 1.14 (PR #9272). Those nodes also need the sandbox runtime, which AWS does not ship in its published EKS AMIs (amazon-eks-ami).

If you want sandboxes now, run them on an EKS cluster that already meets the requirements, such as an EKS Auto Mode cluster on 1.36. Qovery can deploy your services onto an existing cluster through Bring Your Own Kubernetes.

Who creates the sandboxes. Your application does, at runtime. An agent platform creates one sandbox per session, so the right owner is your code calling the Kubernetes API (a pod with runtimeClassName, or a SandboxClaim from the agent-sandbox project for warm pools). That needs a ServiceAccount with permission to create pods in one namespace, which Qovery services can use through the security.service_account_name advanced setting. Qovery deploys the platform that creates sandboxes. It does not create each sandbox.

What we are working on. Support for sandbox node pools on Qovery-managed clusters. If your team needs it, tell us on Slack or by email; real workloads decide what we build first.