--- title: "AWS Nitro Sandboxesとは：EKSのPodを軽量VMで隔離する手順と制約" url: "https://www.issoh.co.jp/tech/details/19655/" published: 2026-11-12 updated: 2026-11-12 categories: ["インフラ・クラウド"] publisher: "株式会社一創" --- # AWS Nitro Sandboxesとは：EKSのPodを軽量VMで隔離する手順と制約 AWS Nitro Sandboxesは、EC2インスタンスのvCPUとメモリの一部を使って軽量な仮想マシンを立て、その境界をAWSのNitro Systemに守らせる機能です。2026年11月9日に[AWS Containers Blogで発表](https://aws.amazon.com/blogs/containers/aws-nitro-sandboxes-hardware-enforced-workload-isolation-on-amazon-eks/)され、EKSではPodごと、ECSではタスクごとに1台ずつVMが割り当てられます。この記事では、confidentialとdirectの2モードの違い、EKS Auto Modeで`runtimeClassName`を1行足して動かす手順、EC2上でFirecrackerから起動する手順、GPU不可やIMDS経由の認証情報漏れといった制約までを、公式ドキュメントの記載に沿って整理します。なお、Nuxtのサーバーエンジンである[Nitro（Nuxtのサーバーエンジン）](https://www.issoh.co.jp/tech/details/16483/)とは名前が同じだけの別物で、本記事は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のページ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/amazon-ec2-nitro-sandboxes.html)によると、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との関係](https://www.issoh.co.jp/tech/details/15691/)で解説しています。 ### confidentialモードとdirectモードで親から見える範囲の違い モードは起動時に選び、後から変えられません。既定はconfidentialです。 | 項目 | confidential（既定） | direct | | ---------------- | ------------------------ | -------------------- | | 親からのメモリ読み書き | 不可（Nitro Systemが親から切り離す） | 可（入れ子のVMと同じ信頼モデル） | | デバイスのデータ経路 | デバイスごとの専用バッファ（DMB） | ゲストのメモリを直接使用 | | アテステーション | NSMが署名付き文書を発行 | なし | | EKSのRuntimeClass | confidential-sandbox | isolated-sandbox に相当 | | 向く場面 | 親の管理者からもデータを隠したい | 親とサンドボックスの運用者が同じ | EC2のドキュメントは「direct」、EKSのドキュメントは「isolated」と呼び方が違います。[EKSのSandboxingのページ](https://docs.aws.amazon.com/eks/latest/userguide/sandboxing.html)では、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の機能として隔離タスクと機密タスク](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/isolated-confidential-tasks.html)が提供されています。 ## Lambda MicroVMs・Enclaves・gVisorと比べた隔離方式の使い分け 隔離の選択肢は多く、AWS自身も使い分けを公式に書いています。 ### AWS公式が示すLambda MicroVMs・Enclaves・ネスト仮想化との4択 EC2ユーザーガイドは「どこまで自分で動かしたいか」で選ぶよう書いています。 1. インスタンスもネットワークも管理したくない：AWS Lambda MicroVMs 2. インスタンスは自分で持ち、ワークロード間の境界はAWSに任せたい：Nitro Sandboxes 3. 高機密のデータを扱う小さく限定されたジョブ：[Nitro Enclaves](https://docs.aws.amazon.com/enclaves/latest/user/nitro-enclave.html) 4. 自前のハイパーバイザーや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比較](https://www.issoh.co.jp/tech/details/15693/)と[gVisorの仕組みと導入判断](https://www.issoh.co.jp/tech/details/15689/)にまとめています。AWSに閉じた構成なら、新規にKataを組むよりNitro Sandboxesを先に検討するのが筋です。 ## EKS Auto ModeでPodをNitro Sandbox上に載せる手順とマニフェスト 手数が最も少ないのはEKS Auto Modeで、[EKSユーザーガイドの手順](https://docs.aws.amazon.com/eks/latest/userguide/sandboxing-isolated-setup.html)のとおり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の違い・料金の分岐点](https://www.issoh.co.jp/tech/details/4524/)で整理しています。 ### 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](https://github.com/aws-samples/sample-eks-nitro-sandbox)に、ウォームプールやCI/CDランナーの構成と一緒に公開されているものです。エージェント向けの他社サンドボックスとの比較には、[Docker Cloud Sandboxesの手順と料金](https://www.issoh.co.jp/tech/details/18257/)も参考になります。 ## EC2上の自前オーケストレーターでFirecrackerから起動する手順とIMDS遮断 EKSやECSを使わず自社のジョブ基盤から起動する場合は、[EC2ユーザーガイドのFirecrackerの手順](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/nitro-sandboxes-run-firecracker.html)に沿って進めます。 ### 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リポジトリ](https://github.com/firecracker-microvm/firecracker)で配布されています。 ### 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 - <)（株式会社一創）