Amazon Web Services（AWS）は2026年11月9日、コンテナやAIエージェントなどを個別の軽量仮想マシン（VM）で実行できる「Nitro Sandboxes」の提供を開始した。対応するAmazon EC2インスタンスの計算資源を共有しながら、Amazon EKSのPodやAmazon ECSのタスクを、それぞれ独立したカーネルを持つVMで動かせる。従来のコンテナとは異なり、ワークロード間にハイパーバイザーによる隔離を設けられることが特徴だ。既定の機密モードでは親インスタンスの管理者によるゲストメモリへのアクセスも防げるが、保存データや認証情報を保護するには別途対策が必要となる。

AD

カーネルを共有するコンテナから、個別の軽量VMへ

通常、同じノード上で動作するLinuxコンテナは、ホストOSのカーネルを共有している。Nitro Sandboxesでは、EKSのPodやECSのタスク、AIエージェントなどを、それぞれ専用のカーネルを持つVM内で実行できる。これにより、同じ計算資源を利用しながら、ワークロード間の隔離を強化できる。特に、AIが生成したコードや外部から受け取ったプログラムなど、信頼性の異なるコードを同じサーバー上で実行する用途が想定される。

仕組みを理解するうえで重要なのが、サンドボックスを管理する「親」と、実際に処理を実行する「ゲスト」の関係だ。親となるEC2インスタンスは仮想CPU、メモリ、I/Oなどの資源を提供するが、ゲストは親の内部で動作する入れ子構造の仮想マシンではない。両者はNitro Hypervisor上で並列に動作し、Nitroが隔離を強制する。AWSはネイティブ環境に近い性能を得られるとしており、現時点では仮想マシンマネージャーとしてFirecrackerをサポートし、親側ではLinuxドライバーを使用する。

既存のAWS Nitro Enclavesとの違いは、入出力の柔軟性にある。Nitro Enclavesは、主にvsockを介した限定的な通信を前提としていた。一方、Nitro Sandboxesではvirtioを利用したネットワーク接続やブロックデバイスを使用でき、複数のゲストでCPU時間を共有する構成にも対応する。一般的なアプリケーションを動かしやすくなった反面、親インスタンスが仲介する通信やストレージへのアクセスについては、適切な保護策を講じる必要がある。

親インスタンスの管理者からもメモリを保護できる

Nitro Sandboxesには、既定の「機密モード」と「directモード」がある。モードはサンドボックスの起動時に選択し、起動後には変更できない。機密モードでは、親インスタンスやその管理者がゲストのメモリを読み書きすることはできず、Nitro Security Module（NSM）による署名付きの検証書も利用できる。一方、directモードでは親からゲストメモリへの読み書きが可能で、NSMや検証書は利用できない。AWSはdirectモードを、親とゲストを同じ信頼できる主体が管理する場合に適した構成としている。

機密モードで生成される検証書には、起動イメージや設定などの測定値が含まれ、暗号学的な署名によって検証できる。親インスタンスの識別子も測定対象となり、起動時に接続された仮想デバイスも原則として測定される。ただし、ホットプラグを有効にした場合、仮想デバイスは測定対象から除外される。この仕組みをAWS Key Management Service（KMS）と組み合わせれば、想定したイメージや設定で起動したゲストにだけ暗号鍵を渡す構成を取れる。

ただし、KMSのキーポリシーには、期待するイメージの測定値を条件として指定する必要がある。AWSによると、親インスタンスの識別子だけを条件にすると、デバッグモードで起動したゲストも認証を通過してしまうためだ。また、検証書が証明するのは起動時に測定された情報であり、ゲスト内で実行されるコードの安全性や、処理結果の正しさまで保証するものではない。

機密モードでも、親インスタンスはゲストに接続する仮想デバイスの通信を仲介し、使用するイメージや実行タイミングを制御できる。つまり、親の管理者によるメモリへの直接アクセスを防げても、ストレージや通信経路まで自動的に保護されるわけではない。必要な保護の範囲に応じて、暗号化やアクセス制御を組み合わせる必要がある。

AD

メモリの隔離だけでは保存データと認証情報を守れない

AWSのEC2公式ガイドでは、Nitro Sandboxesの機密モードについて、メモリ、ストレージ、認証情報それぞれに異なる保護条件を定めている。2026年11月12日時点のドキュメントを基に、自己管理EC2で注意すべき点を整理した。なお、EKSやECSのマネージド環境に、これらの設定がすべて同じ形で必要になるわけではない。

保護対象 Nitro Sandboxesの保護範囲と注意点 必要な対策
ゲストメモリ 機密モードでは親からの読み書きを禁止。directモードでは親からアクセス可能 親インスタンスへの信頼水準に応じて、起動時にモードを選択する
ブロックデバイス上の保存データ 親はゲストに提示したブロックデバイスのデータを読み取れる。EBS暗号化やSSE-KMSだけでは親からの秘匿はできない ゲスト内でデータを暗号化し、検証条件を満たしたゲストにのみKMSから鍵を渡す
親のIAMロール認証情報 ゲストには独自のインスタンスメタデータサービス（IMDS）がないが、親のNATなどを経由して親のIMDSに到達する可能性がある 親側でIMDS宛の通信を遮断する。IMDSv2とhop limit 2だけに依存しない

親インスタンスの管理者から機密情報を守りたい場合、機密モードによるメモリ保護に加え、保存データをゲスト内部で暗号化する必要がある。EBSの暗号化やSSE-KMSは、親がアクセスできる経路からデータを隠す仕組みではないためだ。ゲスト内で暗号化を行い、起動イメージなどの検証結果に基づいてKMSが鍵を渡す構成にすることで、親からのアクセスに対する保護を強化できる。

一方、信頼できないコードをゲスト内で実行する場合は、親インスタンスの認証情報を守る対策が重要になる。ゲスト自身にはIMDSが存在しないものの、親がNATなどを介して通信を中継すると、ゲストから親のIMDSにアクセスできる場合がある。その結果、親に割り当てられたIAMロールの一時的な認証情報が読み取られる恐れがある。

AWSは、IMDSv2を有効にし、Amazon Linux 2023でホップ制限（hop limit）を2に設定していても、この経路を完全には防げないと説明している。自己管理EC2では、親側でIMDSのリンクローカルアドレス「169.254.169.254」宛の通信を拒否するよう推奨している。また、接続追跡テーブルなどの共有資源についても、ゲストごとに適切な制限を設ける必要がある。メモリが分離されていても、共有資源の枯渇による性能低下やサービス停止まで防げるわけではない。

このように、ゲストのメモリを親から保護すること、保存データを暗号化すること、親の認証情報へのアクセスを遮断することは、それぞれ異なる対策だ。Nitro Sandboxesを安全に利用するには、保護したい情報と想定する脅威を明確にし、必要な設定を組み合わせなければならない。

EKS・ECSとの統合と、最大896個の集約に伴う制約

Nitro Sandboxesは、Amazon EKS、Amazon ECS、自己管理EC2から利用できる。EKS Auto Modeでは、PodのruntimeClassNameにconfidential-sandboxまたはisolated-sandboxを指定する。前者は機密性を重視する構成で、後者はノード管理者を信頼する用途に対応する。ECSではECS Managed Instancesの容量プロバイダーとタスク定義を設定し、タスク単位でサンドボックスを利用する。自己管理EC2の場合は、FirecrackerやLinuxドライバーなどを用意し、親インスタンスの起動時にNitro Enclavesを有効化する必要がある。

計算資源を効率的に使うため、Nitro SandboxesはCPUのオーバーコミットにも対応している。複数のゲストで物理CPUの実行時間を共有し、親インスタンスのvCPU数を超える仮想CPUを割り当てられる仕組みだ。割り当て可能なvCPUの合計は親の5倍までとなる。

例えば、親インスタンスが4 vCPUの場合、ゲストに割り当てられるvCPUの合計は最大20となる。各ゲストに1 vCPUを割り当てればCPUの割り当て上は20個、2 vCPUなら10個、4 vCPUなら5個のサンドボックスを構成できる。ただし、これは仮想CPUの割り当て上限であり、処理性能が5倍になるわけではない。メモリやI/Oなどの制約もあるため、計算上の個数を必ず収容できるとは限らない。

サンドボックスの個数自体は、親インスタンス1台につき最大896個まで対応する。ただし、ゲストのメモリは親の起動時に予約した専用プールから割り当てる必要がある。各ゲストには設定したメモリ容量に加えて2 MiBの管理用メモリが必要となり、機密モードでは仮想デバイス1個につき、さらに16 MiBを消費する。スロットの追加にもメモリが必要なため、実際の集約数はCPUだけでなく、メモリ容量や仮想デバイスの構成にも左右される。

機能面にも制約がある。現時点ではGPUのパススルーに対応しておらず、稼働中のvCPU数やメモリ容量の変更もできない。スナップショットからの復元やライブマイグレーションも非対応だ。また、親インスタンスを停止、再起動、終了すると、そこに属するゲストも停止する。個々のゲストはメモリやカーネルが分離されていても、親インスタンスの停止による影響は共有することになる。

Nitro Sandboxesは、AWSの全商用リージョンで提供される。対象はIntel、AMD、AWS Gravitonを搭載した対応NitroベースEC2インスタンスだが、すべてのインスタンスタイプで利用できるわけではなく、flex系など一部は対象外となる。利用前には対応インスタンスタイプの確認が必要だ。Nitro Sandboxes自体と関連する統合機能に追加料金は発生しないものの、EC2の利用料金に加え、EKS Auto ModeやECS Managed Instancesを利用する場合は、それぞれ通常の管理料金がかかる。

Nitro Sandboxesの登場により、ワークロードごとに専用のEC2インスタンスを用意しなくても、独立したVMによる隔離を確保できるようになった。AIエージェントや外部コードの実行など、異なる信頼水準の処理を同じサーバーに集約する用途では、有力な選択肢となり得る。ただし、メモリの隔離だけですべての機密情報が保護されるわけではなく、親インスタンスへの信頼、暗号鍵の管理、通信経路の制御を個別に検討する必要がある。導入にあたっては、実際のワークロードで達成できる集約密度やI/O性能に加え、親の停止時にどこまで影響が及ぶかも評価することが重要だ。