On November 9, 2026, Amazon Web Services (AWS) launched Nitro Sandboxes, a feature that lets containers, AI agents, and other workloads run in individual lightweight virtual machines (VMs). While sharing the compute resources of a supported Amazon EC2 instance, Amazon EKS Pods and Amazon ECS tasks can each run in a VM with its own independent kernel. Unlike conventional containers, this places hypervisor-based isolation between workloads. In the default confidential mode, the parent instance's administrators are also prevented from accessing guest memory, but protecting stored data and credentials requires additional measures.
From Shared-Kernel Containers to Individual Lightweight VMs
Normally, Linux containers running on the same node share the host OS kernel. With Nitro Sandboxes, EKS Pods, ECS tasks, AI agents, and similar workloads can each run inside a VM with a dedicated kernel. This strengthens isolation between workloads while still using the same compute resources. A particularly expected use case is running code of differing trust levels on the same server, such as AI-generated code or programs received from outside.
The key to understanding the mechanism is the relationship between the "parent," which manages the sandboxes, and the "guest," which actually runs the workload. The parent EC2 instance provides resources such as virtual CPUs, memory, and I/O, but the guest is not a nested virtual machine running inside the parent. The two run in parallel on the Nitro Hypervisor, and Nitro enforces the isolation. AWS says near-native performance can be achieved. Currently, Firecracker is supported as the virtual machine manager, and the parent side uses a Linux driver.
The difference from the existing AWS Nitro Enclaves lies in I/O flexibility. Nitro Enclaves was designed mainly around limited communication via vsock. Nitro Sandboxes, by contrast, can use virtio-based network connections and block devices, and also supports configurations in which multiple guests share CPU time. This makes it easier to run general-purpose applications, but communication and storage access mediated by the parent instance require appropriate protective measures.
Memory Protected Even from the Parent Instance's Administrators
Nitro Sandboxes offers a default "confidential mode" and a "direct mode." The mode is selected when the sandbox starts and cannot be changed afterward. In confidential mode, the parent instance and its administrators cannot read or write guest memory, and signed attestation documents from the Nitro Security Module (NSM) are available. In direct mode, the parent can read and write guest memory, and neither the NSM nor attestation documents are available. AWS describes direct mode as suited to cases where the same trusted party manages both the parent and the guest.
The attestation document generated in confidential mode includes measurements of the boot image, configuration, and other items, and can be verified through a cryptographic signature. The parent instance's identifier is also measured, and virtual devices attached at startup are generally measured as well. However, if hotplug is enabled, virtual devices are excluded from measurement. Combined with AWS Key Management Service (KMS), this makes it possible to hand encryption keys only to guests that started with the expected image and configuration.
However, the KMS key policy must specify the expected image measurement as a condition. According to AWS, specifying only the parent instance's identifier would allow a guest started in debug mode to pass authentication as well. Also, an attestation document certifies information measured at startup; it does not guarantee the safety of the code running inside the guest or the correctness of its results.
Even in confidential mode, the parent instance mediates communication for the virtual devices attached to the guest and can control which image is used and when it runs. In other words, even though direct memory access by the parent's administrators is blocked, storage and communication paths are not automatically protected. Depending on the scope of protection needed, encryption and access controls must be combined.
Memory Isolation Alone Does Not Protect Stored Data and Credentials
The AWS official EC2 guide defines different protection conditions for memory, storage, and credentials in Nitro Sandboxes' confidential mode. The following summarizes points to watch for in self-managed EC2, based on the documentation as of November 12, 2026. Note that managed environments such as EKS and ECS do not necessarily require all of these settings in the same form.
| Protected item | Protection scope and caveats in Nitro Sandboxes | Required measures |
|---|---|---|
| Guest memory | In confidential mode, reads and writes from the parent are prohibited. In direct mode, the parent can access it | Choose the mode at startup according to how much you trust the parent instance |
| Stored data on block devices | The parent can read data on block devices presented to the guest. EBS encryption or SSE-KMS alone does not hide it from the parent | Encrypt data inside the guest, and have KMS release keys only to guests that meet the verification conditions |
| Parent's IAM role credentials | The guest has no instance metadata service (IMDS) of its own, but it may reach the parent's IMDS via the parent's NAT or similar | Block traffic to the IMDS on the parent side. Do not rely solely on IMDSv2 and a hop limit of 2 |
To protect confidential information from the parent instance's administrators, stored data must be encrypted inside the guest in addition to the memory protection provided by confidential mode. EBS encryption and SSE-KMS are not mechanisms for hiding data from paths the parent can access. By encrypting inside the guest and having KMS release keys based on verification results such as the boot image, protection against access from the parent can be strengthened.
On the other hand, when running untrusted code inside the guest, measures to protect the parent instance's credentials become important. Although the guest itself has no IMDS, if the parent relays traffic via NAT or similar, the guest may be able to reach the parent's IMDS. As a result, temporary credentials for the IAM role assigned to the parent could be read.
AWS explains that even with IMDSv2 enabled and the hop limit set to 2 on Amazon Linux 2023, this path cannot be completely blocked. For self-managed EC2, it recommends that the parent reject traffic to the IMDS link-local address "169.254.169.254." Appropriate per-guest limits should also be set for shared resources such as connection tracking tables. Even if memory is isolated, performance degradation or service outages caused by exhaustion of shared resources are not prevented.
In this way, protecting guest memory from the parent, encrypting stored data, and blocking access to the parent's credentials are separate measures. To use Nitro Sandboxes safely, you must clarify which information you want to protect and which threats you assume, then combine the necessary settings.
EKS and ECS Integration, and the Constraints of Packing Up to 896 Sandboxes
Nitro Sandboxes can be used from Amazon EKS, Amazon ECS, and self-managed EC2. In EKS Auto Mode, you specify confidential-sandbox or isolated-sandbox as the Pod's runtimeClassName. The former is a configuration that prioritizes confidentiality, while the latter is for use cases where the node administrator is trusted. In ECS, you configure an ECS Managed Instances capacity provider and a task definition, and use sandboxes on a per-task basis. For self-managed EC2, you need to prepare Firecracker, the Linux driver, and other components, and enable Nitro Enclaves when launching the parent instance.
To use compute resources efficiently, Nitro Sandboxes also supports CPU overcommitment. Multiple guests share the execution time of physical CPUs, allowing more virtual CPUs to be assigned than the parent instance's vCPU count. The total assignable vCPUs is up to five times that of the parent.
For example, if the parent instance has 4 vCPUs, the total vCPUs that can be assigned to guests is up to 20. Assigning 1 vCPU to each guest allows 20 sandboxes by vCPU allocation, 2 vCPUs allows 10, and 4 vCPUs allows 5. However, this is an upper limit on virtual CPU allocation, not a fivefold increase in processing performance. Because of constraints on memory, I/O, and other resources, the calculated number of sandboxes cannot always be accommodated.
The number of sandboxes itself is supported up to 896 per parent instance. However, guest memory must be allocated from a dedicated pool reserved when the parent starts. Each guest requires 2 MiB of management memory in addition to its configured memory capacity, and in confidential mode, each virtual device consumes a further 16 MiB. Adding slots also requires memory, so the actual packing density depends not only on CPU but also on memory capacity and virtual device configuration.
There are also functional limitations. Currently, GPU passthrough is not supported, and the number of running vCPUs and memory capacity cannot be changed. Restoring from snapshots and live migration are also unsupported. Additionally, if the parent instance is stopped, rebooted, or terminated, the guests belonging to it also stop. Even though each guest has isolated memory and kernel, they share the impact of the parent instance stopping.
Nitro Sandboxes is available in all AWS commercial Regions. It targets supported Nitro-based EC2 instances with Intel, AMD, and AWS Graviton processors, but it cannot be used on every instance type, and some, such as the flex family, are excluded. You should confirm supported instance types before use. There is no additional charge for Nitro Sandboxes itself or related integration features, but in addition to EC2 usage charges, the usual management fees apply when using EKS Auto Mode or ECS Managed Instances.
With Nitro Sandboxes, isolation through independent VMs is now possible without preparing a dedicated EC2 instance for each workload. For consolidating workloads of differing trust levels onto the same server, such as running AI agents or external code, it could be a strong option. However, memory isolation alone does not protect all confidential information, and trust in the parent instance, encryption key management, and communication path control must each be considered separately. When adopting it, it is important to evaluate the packing density and I/O performance achievable with your actual workloads, as well as how far the impact extends when the parent stops.