Back home

AWS Nitro Sandboxes

x+web 0.92
Visit source

Intro

AWS Nitro Sandboxes is a new isolation feature Amazon Web Services posted on 9 November 2026 in AWS What's New. Each sandbox is a lightweight virtual machine managed by the Nitro Hypervisor. You can run an Amazon EKS pod, an Amazon ECS task, or a lightweight VM on Amazon EC2 — including AI agents inside those workloads — in its own hardware-isolated virtual machine built on the AWS Nitro System.

AWS's pitch is that untrusted, multi-tenant, or regulated work, and LLM-generated code, can share one EC2 instance while still getting the isolation boundary of a Nitro VM. The What's New post says sandboxes run on your existing instances with near-native EC2 performance, inherit Nitro-hypervisor isolation, and can use cryptographic attestation so secrets are released only to sandboxes that have proven their integrity. On EKS or ECS, enabling the feature is described as a one-line change; each pod or task gets its own VM, and AWS says workloads stay native: Pod Identity, VPC CNI, EBS/EFS/S3 storage, and CloudWatch work as before. For full control, you can run Nitro Sandboxes directly on EC2 with your own AMI, orchestration, and virtual machine monitors. Amazon Linux and Firecracker are listed as natively supported, with patches for other options available.

The same day's Containers blog walks through the EKS path in more detail. Documentation lives in the EC2 user guide. AWS says the feature is available today on most Nitro-based EC2 instances, in all commercial Regions, at no additional charge.

Highlights:

Explain

Why it matters

Agent platforms and multi-tenant SaaS often buy isolation by giving each workload a whole machine, which wastes capacity. Nitro Sandboxes try to offer the same hardware boundary AWS already uses between EC2 instances, at pod or task scale, billed only as the instance you already run. If you already operate EKS or ECS and need to run model-generated code or untrusted plugins, a one-line opt-in with attestation is a concrete, official path inside AWS rather than a third-party sandbox SaaS.

Limits

Availability, "most Nitro-based instances," "all commercial Regions," and "no additional charge" are AWS's statements. You still operate the cluster or instance, the IAM boundary, and the lifecycle of the sandboxes; this is an isolation primitive, not a hosted agent-sandbox product with pause/resume and an SDK. Confirm current instance-family support, Kubernetes version requirements, and any GPU or snapshot limits in the official user guides before planning a rollout — those details can differ by surface (EKS Auto Mode vs standard EKS vs ECS vs raw EC2) and are not fully spelled out in the What's New post. This page does not substitute for the AWS documentation or pricing calculator.

Usage

  1. Read https://aws.amazon.com/about-aws/whats-new/2026/11/nitro-sandboxes-eks-ecs-ec2/ and the EKS blog https://aws.amazon.com/blogs/containers/aws-nitro-sandboxes-hardware-enforced-workload-isolation-on-amazon-eks/ ;
  2. For implementation, use the EC2 guide https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/amazon-ec2-nitro-sandboxes.html and the current EKS or ECS user guide linked from the What's New post;
  3. On EKS or ECS, start with the official one-line enablement on a non-production workload and confirm Pod Identity, networking, storage, and logs still behave as documented;
  4. If you need attestation before releasing secrets, follow the official attestation steps rather than assuming every sandbox is attested by default.

Advertisement