2026.11.12 インフラ・クラウド

AWS Nitro Sandboxesとは：EKSのPodを軽量VMで隔離する手順と制約

AWS Nitro Sandboxesは、EC2インスタンスのvCPUとメモリの一部を使って軽量な仮想マシンを立て、その境界をAWSのNitro Systemに守らせる機能です。2026年11月9日にAWS Containers Blogで発表され、EKSではPodごと、ECSではタスクごとに1台ずつVMが割り当てられます。この記事では、confidentialとdirectの2モードの違い、EKS Auto ModeでruntimeClassNameを1行足して動かす手順、EC2上でFirecrackerから起動する手順、GPU不可やIMDS経由の認証情報漏れといった制約までを、公式ドキュメントの記載に沿って整理します。なお、NuxtのサーバーエンジンであるNitro（Nuxtのサーバーエンジン）とは名前が同じだけの別物で、本記事はAWSのNitro Systemの話です。

まとめ：AWS Nitro Sandboxesの要点と採用可否を分ける条件

Nitro Sandboxesは「1台のEC2を、互いに信頼できない複数のワークロードで共有したい」ときの隔離層です。コンテナはカーネルを共有するため、カーネルの脆弱性やコンテナ脱出が起きると隣のPodまで届きます。Nitro SandboxesはPodやタスクを独立したVMに入れ、その境界をゲストOSではなくNitro Hypervisorに担わせます。追加料金はなく、払うのは親インスタンスのEC2料金だけです。

採用を勧めるのは、AIエージェントが生成したコードの実行、テナントごとのジョブを同じノードに詰めるマルチテナントSaaS、外部から持ち込まれるビルドジョブの3用途です。EKS Auto Mode（Kubernetes 1.36以降）なら、Podの仕様にruntimeClassName: isolated-sandboxを足すだけで始められます。

見送るのは、GPUを使う推論、スナップショット復元を前提にした設計、hostNetwork: trueに依存するPodの3つ。EC2で自前に組むなら、親のIMDS（169.254.169.254）への通信を必ず遮断してください。

AWS Nitro SandboxesがEC2の親インスタンス上に軽量VMを立てる仕組み

親インスタンスのvCPUとメモリを分けNitro Hypervisorが境界を張る構造

EC2ユーザーガイドのNitro Sandboxesのページによると、Nitro Sandboxは「親インスタンス」が差し出したvCPUとメモリの上で動く軽量VMです。親インスタンス上のVMM（仮想マシンモニター）がNitro Enclavesドライバー経由でVMを作り、仮想デバイスを実装します。2026年11月時点でNitro Sandboxesに対応するVMMはFirecrackerだけで、ドライバーはLinux向けです。

ポイントは、Nitro Sandboxが親インスタンスの中で入れ子に動くのではなく、Nitro Hypervisor上で親インスタンスと並んで動く点です。そのためvCPUはEC2インスタンスと同等の性能で動き、サンドボックス内のコードは親インスタンスのメモリに触れません。親との接点は仮想デバイスとvsock（ローカルソケット）だけです。Firecracker自体の仕組みはFirecracker（マイクロVM）の仕組みとKVMとの関係で解説しています。

confidentialモードとdirectモードで親から見える範囲の違い

モードは起動時に選び、後から変えられません。既定はconfidentialです。

項目	confidential（既定）	direct
親からのメモリ読み書き	不可（Nitro Systemが親から切り離す）	可（入れ子のVMと同じ信頼モデル）
デバイスのデータ経路	デバイスごとの専用バッファ（DMB）	ゲストのメモリを直接使用
アテステーション	NSMが署名付き文書を発行	なし
EKSのRuntimeClass	confidential-sandbox	isolated-sandbox に相当
向く場面	親の管理者からもデータを隠したい	親とサンドボックスの運用者が同じ

EC2のドキュメントは「direct」、EKSのドキュメントは「isolated」と呼び方が違います。EKSのSandboxingのページでは、isolatedは「親インスタンスを信頼し、ゲストを信頼しない」、confidentialは「親インスタンスも信頼しない」という定義です。隣のPodから守るだけならisolated、ノードの運用者からも隠すならconfidentialを選びます。

追加料金なしで使える対応インスタンスと提供範囲の2026年11月時点

Nitro Sandboxes自体は無料で、払うのは親のEC2と併用サービスの通常料金だけ。EKSの隔離PodはすべてのAWS商用リージョンで使え、Kubernetes 1.36以降が条件になります。

対応インスタンスはIntel・AMD・GravitonのM・C・R・X・I系の多くで、各ファミリーの最小サイズとmetal、C7i-flexなどのflex系は対象外です。G5・G6などのGPUインスタンスも親にできますが、サンドボックス内で使えるのはCPUだけ。ECSではECS Managed Instancesの機能として隔離タスクと機密タスクが提供されています。

Lambda MicroVMs・Enclaves・gVisorと比べた隔離方式の使い分け

隔離の選択肢は多く、AWS自身も使い分けを公式に書いています。

AWS公式が示すLambda MicroVMs・Enclaves・ネスト仮想化との4択

EC2ユーザーガイドは「どこまで自分で動かしたいか」で選ぶよう書いています。

インスタンスもネットワークも管理したくない：AWS Lambda MicroVMs
インスタンスは自分で持ち、ワークロード間の境界はAWSに任せたい：Nitro Sandboxes
高機密のデータを扱う小さく限定されたジョブ：Nitro Enclaves
自前のハイパーバイザーやOSを動かしたい：ネスト仮想化

Nitro Enclavesとの差は、外との接点の広さです。Enclaveは永続ストレージも外部ネットワークも持たず、親とのvsock1本だけで通信します。Nitro Sandboxesはブロックデバイスやネットワークを持てるので、普通のアプリをそのまま動かせます。

gVisorやKata Containersを自前で入れる構成と比べたときの差

違いは、境界を誰が保守するかです。

方式	境界を担うもの	保守の主体	ノードの条件
Nitro Sandboxes	Nitro Hypervisor	AWS（ゲストのシステムイメージ含む）	対応EC2・Enclaves有効
Kata Containers	KVMなどのハイパーバイザー	利用者	ベアメタルかネスト仮想化
gVisor	ユーザー空間のカーネル（Sentry）	利用者	特になし（syscall互換に注意）

EC2でKataを動かすにはネスト仮想化かmetalインスタンスが要りましたが、Nitro Sandboxesは通常のインスタンスで動き、Hypervisorとゲストイメージの保守もAWS側にあります。gVisorはAWS以外の環境へ同じ構成を持ち運べる点が強みです。仕組みはKata Containersの仕組みとgVisor・runc比較とgVisorの仕組みと導入判断にまとめています。AWSに閉じた構成なら、新規にKataを組むよりNitro Sandboxesを先に検討するのが筋です。

EKS Auto ModeでPodをNitro Sandbox上に載せる手順とマニフェスト

手数が最も少ないのはEKS Auto Modeで、EKSユーザーガイドの手順のとおりAMIの自作は要りません。

K8s 1.36以上のAuto Modeクラスタ作成とRuntimeClass確認

eksctlは既定で古いKubernetesのバージョンを選ぶため、--versionを明示します。公式の例は次のとおりです。

eksctl create cluster --name sandbox-demo --region us-west-2 --version 1.37 --enable-auto-mode

kubectl get runtimeclass
# NAME                   HANDLER                AGE
# confidential-sandbox   confidential-sandbox   5m
# isolated-sandbox       isolated-sandbox       5m

Auto ModeのクラスターにはこのRuntimeClassが2つ最初から入っており、アドオンの追加は要りません。マネージドノードグループやセルフマネージドで使う場合は、Nitro Sandboxのランタイムを入れたAMIを自作し、起動テンプレートでEnclaveOptions.Enabled=trueを指定します。Enclavesを有効にしないノードは、サンドボックスの容量を広告しません。Auto Modeの料金や制約はEKS Auto ModeとFargateの違い・料金の分岐点で整理しています。

isolated-sandboxを指定したPodの適用とログでの確認

Podの仕様で変えるのは1行だけです。AWS Containers Blogの例を一部簡略化し、確認用のコマンドと合わせて載せます。

apiVersion: v1
kind: Pod
metadata:
  name: hello-sandbox
spec:
  runtimeClassName: isolated-sandbox
  containers:
    - name: hello
      image: public.ecr.aws/amazonlinux/amazonlinux:2023
      command: ["sh", "-c"]
      args:
        - |
          echo "product_name: $(cat /sys/class/dmi/id/product_name)"
          echo "disks: $(ls /sys/block | tr '\n' ' ')"
          sleep infinity

kubectl apply -f hello-sandbox.yaml
kubectl wait pod/hello-sandbox --for=condition=Ready --timeout=300s
kubectl logs hello-sandbox

ブログによると、サンドボックス内ではproduct_nameの末尾が.enclaveになり、ディスクはvirtioのvda・vdb・vdcとして見えます。通常のPodではnvme0n1などが見えるので、この2点が隔離の有無を見分ける判断材料です。同じPod内の複数コンテナは1つのサンドボックスを共有します。

DeploymentではannotationをPodテンプレート側に置く理由

Deployment・StatefulSet・Job・CronJobでは、runtimeClassNameとsandbox.amazonaws.com/で始まるアノテーションを、コントローラー本体ではなくPodテンプレートに書きます。

spec:
  template:
    metadata:
      annotations:
        sandbox.amazonaws.com/network-isolated: "true"
    spec:
      runtimeClassName: isolated-sandbox

Deploymentのmetadata.annotationsに書いても受け付けられたうえで無視され、Podには写りません。エラーにならないので気づきにくい落とし穴です。作成後はkubectl get pods -o custom-columns='NAME:.metadata.name,RUNTIME:.spec.runtimeClassName'でPod側にランタイムクラスが付いたかを確かめます。

AIエージェントのコード実行はnetwork-isolatedで通信を断つ

生成されたコードを外部と通信させたくないときは、上の例のとおりsandbox.amazonaws.com/network-isolated: "true"を付けます。サンドボックスはネットワークデバイスを持たずに起動し、DNS・NTP・IMDS・Pod Identityの認証情報も届きません。フィルターではなくデバイス自体が無いので、どちら向きの通信もできない状態です。

ただし完全な遮断ではありません。ゲスト内のvsockチャネルは残るため、ログやexecは動きます。HTTPやTCPの死活監視は失敗するので、probeはexec形式への切り替えが必要です。LLM APIやGitHubだけ通すなら、Auto ModeのApplicationNetworkPolicyで宛先ホスト名を絞ります。手元で動く例はaws-samplesのsample-eks-nitro-sandboxに、ウォームプールやCI/CDランナーの構成と一緒に公開されているものです。エージェント向けの他社サンドボックスとの比較には、Docker Cloud Sandboxesの手順と料金も参考になります。

EC2上の自前オーケストレーターでFirecrackerから起動する手順とIMDS遮断

EKSやECSを使わず自社のジョブ基盤から起動する場合は、EC2ユーザーガイドのFirecrackerの手順に沿って進めます。

Nitro Enclaves有効化とメモリプール予約による親インスタンスの準備

前提は、対応インスタンス、AL2023のkernel6.18パッケージ（6.18.51-120.162.amzn2023以降）、Firecracker 1.18以降、親インスタンスのroot権限の4つです。起動時に--enclave-options Enabled=trueを付け、カーネルのコマンドラインにメモリプールを足して再起動します。

aws ec2 run-instances \
    --image-id resolve:ssm:/aws/service/ami-amazon-linux-latest/al2023-ami-kernel-6.18-x86_64 \
    --instance-type m7i.4xlarge \
    --enclave-options Enabled=true

sudo grubby --update-kernel=ALL --args="nitro_enclaves.mempool=8G@0"
sudo reboot
sudo dmesg | grep "nitro_enclaves: CMA pool"

サンドボックスのメモリはこのプールからしか取れません。プールが無いとスロットは0で、1台も起動できません。プールを確保するとスロットは4つになり、それ以上同時に動かすには/sys/class/misc/nitro_enclaves/pcie_slotsに12・20・28と8刻みで書き込みます。8スロット増やすごとにプールから128MiBが消える点も容量計画に入れておきます。

Firecracker 1.18以降のenclaveキーで設定ファイルを書いて起動

Firecrackerの設定にenclaveオブジェクトを置くと、KVMのmicroVMではなくNitro Sandboxとして起動します。空のオブジェクトならconfidentialモードです。

{
  "boot-source": { "kernel_image_path": "vmlinuz", "initrd_path": "initrd.img" },
  "machine-config": { "vcpu_count": 2, "mem_size_mib": 2048 },
  "drives": [],
  "network-interfaces": [ { "iface_id": "eth0", "host_dev_name": "tap0" } ],
  "vsock": { "guest_cid": 3, "uds_path": "/run/sandbox/v.sock" },
  "enclave": { "cpu_overcommit": true }
}

sudo firecracker --no-api --config-file sandbox.json
cat /sys/class/misc/nitro_enclaves/pcie_slots_in_use

directモードにするならenclaveに"direct_mode": trueを足します。debug_modeはゲストのコンソールが見える開発用の設定で、アテステーションの起動時測定値が0になるため本番では使いません。ブロックデバイスが無くてもdrivesキーは必須です。ソースとリリースはFirecrackerのGitHubリポジトリで配布されています。

NATで外へ出す場合の169.254.169.254宛て通信のnftables拒否

見落とすと事故になるのがここです。Nitro Sandboxは自前のIMDSを持ちません。親インスタンスがNATで通信を中継すると、サンドボックスから親のIMDSに届き、親のIAMロールの認証情報を読めてしまいます。IMDSv2やAL2023既定のホップ制限2では防げないと公式に書かれています。

IFACE=$(ip route show default | awk '{print $5; exit}')
sudo nft -f - <<EOF
table ip sandbox {
    chain forward {
        type filter hook forward priority filter; policy accept;
        iifname "tap0" ip daddr 169.254.169.254 reject
    }
    chain postrouting {
        type nat hook postrouting priority srcnat; policy accept;
        iifname "tap0" oifname "$IFACE" masquerade
    }
}
EOF

rejectなら即座に失敗し、dropではタイムアウトまで待たされます。AmazonのDNS（169.254.169.253）は名前解決に使うので止めません。TAPデバイスとこのルールは再起動で消えるため、起動スクリプトに組み込みます。もう1つ、接続追跡テーブルのような共有資源を1台のサンドボックスが食い尽くせるので、サンドボックスごとに上限を掛けておきます。

Nitro Sandboxesを採用すべき条件と見送るべきワークロードの線引き

結論から言えば、AWSに閉じたCPUワークロードで「他人のコード」を同居させるなら採用、それ以外は既存の構成で十分です。

採用する条件は他人のコードを同居させるマルチテナントとエージェント実行

採用を勧めるのは、次のどれかに当てはまり、かつCPUだけで完結するワークロードです。

利用者の指示でAIエージェントが生成したコードを、同じノード上で並列に実行する
テナントごとのETLやレポート生成を、1台のEC2に詰めて費用を抑えたい
外部のリポジトリから持ち込まれるビルドやテストを、CIランナーで動かす

3つとも、従来はテナントごとにノードを分けるか、Fargateに逃がすかの二択でした。ECSのドキュメントは隔離タスクを「Fargateに近い隔離の保証を、Managed Instancesのインスタンス選択とビンパッキングの自由度のまま得られる」と説明しています。自社でこうした基盤の設計や移行を進めるときは、AWS・Google Cloud・Azureのインフラ構築の窓口からEKSやECSの構成ごと相談できます。

見送る条件はGPU推論・スナップショット前提・hostNetwork依存のPod

次に当てはまるなら、現時点では採用しません。

GPUを使う推論や学習：GPUパススルーは提供開始時点で不可
スナップショットからの復元で起動を速くする設計：snapshot・pause・ライブマイグレーションは非対応
hostNetwork: trueやhostUsers: falseを使うPod：起動しない
稼働中のCPU・メモリ変更やPVCの拡張が必要な運用：再作成が前提
IMDSから認証情報を取る既存アプリ：EKSでは一部のplacement系パス以外は404になり、Pod Identityへの移行が必要

特に1つ目と2つ目は、エージェント基盤でよく求められる要件です。起動の速さを重視するなら、スナップショットに対応したFirecracker単体のKVM構成や、gVisorで高密度に動かすAgent Substrateのような別の選択肢のほうが合います。移行前にはEKSの制約一覧を1行ずつ当てはめてください。

容量の見落とし：vCPUあたり5個とSMTで実効半分になる計算

1台に詰められる数には上限があります。サンドボックスは親インスタンスのvCPUあたり最大5個、1台あたり最大896個までで、CPUオーバーコミット時は全サンドボックスのvCPU合計が親の5倍までです。4vCPUのインスタンスなら、1vCPUのサンドボックスを20個、または2vCPUを10個が上限になります。

見落としやすいのはSMT（1コア2スレッド）です。IntelやSMT有効のAMDでは、1つの物理コアを同時に使えるのは1つのサンドボックスか親だけなので、実際に使える計算資源はvCPU数のおよそ半分になります。EKSのドキュメントは、SMTインスタンスではvCPUを2の倍数で要求するか、1コア1スレッドのGravitonを選ぶよう勧める記載です。メモリも、各サンドボックスに最低256MiBを割り当てるうえ、プールから1台あたり2MiB、confidentialモードでは仮想デバイスごとに16MiBが追加で引かれます。密度の試算はvCPUではなくメモリから始めるのが確実です。

よくある質問

導入前の検討でよく出る疑問を、公式ドキュメントの記載をもとにまとめます。

AWS Nitro Sandboxesの利用に追加料金はかかりますか？

Nitro Sandboxes自体に追加料金はありません。サンドボックスは親インスタンスのvCPUとメモリを分けて動くため、支払うのはEC2インスタンスの通常料金と、EKSやKMSなど併用したサービスの料金です。ただし、サンドボックスに割いたvCPUとメモリは親のアプリでは使えないため、インスタンスを一段大きくする費用は見込んでおきます。

Nitro SandboxesとNitro Enclavesの違いは何ですか？

どちらもNitro Systemで親インスタンスから切り離されたVMですが、外との接点が違います。Nitro Enclavesは永続ストレージや外部ネットワークを持たず、親とのvsock1本だけで通信する、鍵処理のような小さなジョブ向けです。Nitro Sandboxesはブロックデバイスやネットワークを持てるため、通常のアプリやコンテナをそのまま動かせます。親インスタンスでNitro Enclavesを有効にすることが、Sandboxes利用の前提でもあります。

EKS Auto Mode以外のマネージドノードグループでも使えますか？

マネージドノードグループとセルフマネージドノードでは使えます。条件は、Nitro Sandboxのランタイムを含むカスタムAMIを作ること、対応インスタンスを選ぶこと、起動テンプレートでEnclaveOptions.Enabled=trueを指定することの3点です。一方、EKS Auto ModeならAMIの作成は不要で、Podを置けば対応ノードが用意されます。2026年11月時点では、Auto ModeでもFIPS AMIやマルチNUMAのインスタンス、r5a・r5ad・m5adでは対応ノードが用意されず、PodがPendingのまま残ります。

サンドボックスの中からGPUを使うことはできますか？

2026年11月の提供開始時点では使えません。EC2ユーザーガイドはGPUパススルーを「現在は利用不可」とし、EKSのドキュメントも、基盤のFirecrackerがホストのデバイスをゲストに渡す仕組みを持たないことを理由に挙げています。G5やG6などのGPUインスタンスを親にすることはできますが、サンドボックスで動くのはCPUの処理だけです。GPUを使う推論は、サンドボックスのランタイムクラスを付けない通常のPodで動かします。

ECSのFargateでもNitro Sandboxesを指定できますか？

ECSで提供されているのは、ECS Managed Instancesの機能としての「隔離タスク」と「機密タスク」です。ECSのドキュメントはこの機能をManaged Instancesの機能と位置づけており、Fargateで指定する方法は記載されていません。インスタンスタイプの選択やビンパッキングによる費用削減を理由にFargateから移る場合の選択肢になります。