本文へスキップ
AWS DAILY
重要度:通常新サービス対応不要

AWS Nitro Sandboxesが一般提供開始 — Amazon EKS・ECS・EC2でハードウェア分離されたポッド・タスク・VMを実現

公開
更新

概要

AWS Nitro Sandboxesが、Amazon EKS・ECS・EC2上でハードウェア分離された軽量VMとして利用可能になりました。Nitro Hypervisorが管理する各サンドボックスは、単一インスタンス上で信頼できないワークロードやマルチテナント・規制対象ワークロードを安全に実行できます。

変更内容

  • AWS Nitro SandboxesがNitro Hypervisorで管理される軽量VMとして一般提供を開始しました。
  • Amazon EKSのポッドおよびAmazon ECSのタスクをそれぞれ独立したハードウェア分離VMで実行できるようになりました。
  • EKSまたはECSでNitro Sandboxesを有効化するには1行の設定変更のみで済みます。
  • 暗号証明によるワークロードの検証が可能で、整合性が証明されたNitro Sandboxesにのみシークレットを渡せます。
  • LLMが生成したコードを分離環境で安全に実行できるため、AIエージェントのワークロードに対応します。
  • Amazon LinuxとFirecrackerがネイティブサポートされ、その他のオプション向けパッチも提供されています。
  • Pod Identity・VPC CNI・EBS/EFS/S3ストレージ・CloudWatchがそのまま動作します。
  • 追加料金なしで、ほとんどのNitroベースのEC2インスタンス上、全商用リージョンで利用できます。

公式発表で確認できる事実

  • AWS Nitro SandboxesはNitro Hypervisorが管理する軽量VMとして提供されます。
  • Amazon EKSのポッド、Amazon ECSのタスク、またはスタンドアロンの軽量VMとして利用できます。
  • AIエージェントを含む各ワークロードは、AWS Nitro Systemによるハードウェア分離された独自のVMで動作します。
  • EC2インスタンス上でネイティブに近いパフォーマンスで動作し、Nitro Hypervisorの分離を継承します。
  • 暗号証明によりワークロードの整合性を検証でき、整合性が証明されたNitro Sandboxesにのみシークレットを渡せます。
  • 信頼できないワークロード、マルチテナントワークロード、規制対象ワークロードを単一インスタンス内で安全に実行できます。
  • LLMが生成したコードを分離環境で実行しながら、単一のEC2インスタンスを複数のエージェントワークロードで安全に共有できます。
  • EKSまたはECSでの有効化は1行の変更のみで、Pod Identity・VPC CNI・EBS/EFS/S3ストレージ・CloudWatchはそのまま動作します。
  • EC2上で直接利用する場合は、独自のAMI・オーケストレーション・VMM(仮想マシンモニター)を使ったフル制御が可能です。
  • Amazon LinuxとFirecrackerがネイティブサポートされ、その他のオプション向けパッチも提供されています。
  • ほとんどのNitroベースのEC2インスタンスで利用可能で、全商用リージョンで追加料金なしで提供されます。
  • 詳細はEKS User Guide、ECS User Guide、またはEC2 User Guide内のNitro Sandboxesドキュメントを参照できます。

当サイトの考察

Nitro Sandboxesは、コンテナよりも強い分離を必要とするユースケース、特にAIエージェントがLLMの出力コードを動的に実行するシナリオで有力な選択肢になります。EKSやECSとの統合が1行の設定変更で済む点は、既存のワークロードへの導入障壁を大きく下げています。追加料金なしという点も、まず試してみる動機になるでしょう。

確認できていない事項

  • 東京リージョン(ap-northeast-1)や大阪リージョン(ap-northeast-3)での提供については資料に明記されていません(「全商用リージョン」とのみ記載)。
  • 具体的な対応EC2インスタンスタイプの一覧は資料に記載されていません。
  • 一般提供開始の正確な日付は資料から確認できません。
  • 東京(ap-northeast-1)と大阪(ap-northeast-3)での提供は、公式記事からは確認できていません。

この記事は、AWS 公式の発表をもとに AI が作成し、自動で公開しています。

既存環境への影響

単一のEC2インスタンス上で複数のワークロードをハードウェアレベルで分離して実行できるため、セキュリティを維持しながらインスタンスの利用率を高めてコストを削減できます。EKSやECSを利用している場合は既存の設定をほぼ変えずに導入できます。AIエージェントやLLM生成コードの実行環境として、信頼できないコードを安全に隔離する手段が得られます。

対応の必要性

対応不要

既存環境への強制的な変更はなく、利用は任意です。EKSまたはECSで利用する場合は1行の設定変更で有効化できます。

利用可能リージョン

東京(ap-northeast-1)
未確認
大阪(ap-northeast-3)
未確認

公式記事に東京(ap-northeast-1)と大阪(ap-northeast-3)の記載がないため、未確認としています。

AWS 公式情報

当サイトの記事は公式情報をもとに編集したものです。正確な内容は必ず AWS 公式情報をご確認ください。

重要度:通常新機能

Amazon EKS Auto ModeとKarpenterがDynamic Resource Allocation(DRA)をサポート、NVIDIA GPUとEFAデバイスの柔軟な割り当てが可能に

Amazon EKS Auto ModeおよびKarpenterがDynamic Resource Allocation(DRA)に対応し、NVIDIA GPUとElastic Fabric Adapter(EFA)ネットワークデバイスをKubernetesワークロードへ柔軟に割り当てられるようになりました。GPUのPod間共有やトポロジー整合デバイス割り当てが可能になります。