AWS 推出 Nitro Sandboxes：每個容器各配一台硬體隔離小 VM，改一行設定、不另收費

一句話看懂：AWS 讓每個容器都能住進自己一間「硬體隔離的小房間」，AI 產生的程式碼就算出事也關得住，而且不加價。

先用白話講：Nitro Sandbox 是什麼？

想像一棟分租公寓。一般的容器就像同一層樓用隔板隔出來的雅房：大家共用同一套水電管線（Linux 核心），只要有一間把管線弄壞，整層樓都可能遭殃。

Nitro Sandbox 則是把每間雅房換成獨立的小套房，牆是鋼筋水泥，水電也各自一套。牆由 AWS 的 Nitro（AWS 自己的虛擬化硬體與軟體）負責蓋，裡面的人再怎麼折騰都碰不到隔壁。

這對現在的 AI Agent 特別重要：Agent 常常會自己寫程式、自己執行，你沒辦法事先保證那段程式是安全的。

發生什麼事

AWS 在 11 月 9 日宣布推出 AWS Nitro Sandboxes：

• 可以用在 Amazon EKS 的 Pod、Amazon ECS 的任務，或直接在 EC2 上跑輕量 VM
• 每個工作負載都有自己的 Nitro 隔離虛擬機，效能官方說接近原生 EC2
• EKS、ECS 啟用只需要改一行設定，Pod Identity、VPC CNI、EBS/EFS/S3、CloudWatch 都照常可用
• 多數 Nitro 機型、所有商業區域都能用，不額外收費
• 可做密碼學證明（attestation），確認沙箱沒被動過手腳才發放機密資料

會影響誰？要注意什麼？

幾個 EC2 文件寫明的限制：

• 沙箱的記憶體是整塊獨佔，不能超賣；一台機器能放的數量受記憶體限制
• 所有沙箱加起來的 vCPU 最多是主機 vCPU 的 5 倍（例如 4 vCPU 的主機最多分出 20 個 vCPU）
• 網路堆疊是整台主機共用的，一個沙箱可能把連線追蹤表塞爆、影響其他沙箱，要自己限流

給開發者的技術細節

EKS 上是在 Pod 規格裡指定 runtime class：

apiVersion: v1
kind: Pod
metadata:
  name: agent-runner
spec:
  runtimeClassName: isolated-sandbox   # 或 confidential-sandbox
  containers:
    - name: app
      image: my-agent:latest

• isolated-sandbox：信任主機、不信任容器，保護主機和其他 Pod；仍可 exec、看日誌
• confidential-sandbox：不信任主機，保護容器內的資料；exec 會被拒絕
• 要跑完全不能連網的程式，可在 Pod 加上 sandbox.amazonaws.com/network-isolated: "true"，沙箱開機時根本沒有網卡
• 每個 Pod 都有一份 Cedar 政策，控制能載入哪些映像檔、能不能 exec
• 自己在 EC2 上管理時，官方建議用 Firecracker 啟動沙箱，預設就是機密模式

我的看法

接案做 AI 功能時常遇到的難題，往往不是模型夠不夠聰明，而是「敢不敢讓它自己跑程式」。以前要做到真正隔離，不是一個任務開一台 VM（貴又慢），就是自己架 gVisor、Kata 這類方案（維護成本高）。AWS 把它做成一行設定又不加價，門檻降很多。

不過小團隊要注意兩件事：第一，GPU 進不去，本地模型推論還是要另外處理；第二，它是 EKS/ECS 的功能，如果你的服務只是一台 EC2 跑 Docker Compose，要自己用 Firecracker 管，複雜度不低。還沒上 Kubernetes 的團隊，不必為了這個硬搬。

名詞小辭典

• 容器（Container）：把程式和它需要的環境打包在一起的執行單位，多個容器通常共用同一台機器的作業系統核心。
• Pod：Kubernetes 裡最小的部署單位，可以包含一個或多個容器。
• Nitro：AWS 自家的虛擬化系統，負責把一台實體機器切成彼此隔離的虛擬機。
• Attestation（證明）：用密碼學證明「這台機器跑的就是我預期的程式」，驗過才發金鑰。

資料來源

• AWS What’s New：Introducing AWS Nitro Sandboxes（2026-11-09）
• Amazon EKS 使用指南：Sandboxing with isolated and confidential pods
• Amazon EC2 使用指南：Isolate workloads with AWS Nitro Sandboxes