AWS Nitro Sandboxes เปิดใช้ 9 พ.ย. 2026 ให้พ็อด EKS งาน ECS และ VM บน EC2 รันใน VM แยกด้วย Nitro Hypervisor ไม่คิดเงินเพิ่ม เหมาะกับ AI agent ที่รันโค้ดเอง
โดย กองบรรณาธิการ THAI DATA อ่าน 6 นาที
สรุปประเด็นสำคัญ
- AWS ประกาศเมื่อ 9 พฤศจิกายน 2026 เปิดตัว AWS Nitro Sandboxes VM ขนาดเล็กที่ Nitro Hypervisor ดูแล ใช้แยกพ็อดของ Amazon EKS งานของ Amazon ECS หรือ VM บน EC2 ออกจากกันด้วยฮาร์ดแวร์ โดยไม่คิดค่าบริการเพิ่ม
- บน EKS เปิดใช้ด้วยการเพิ่มบรรทัดเดียว
runtimeClassName: isolated-sandboxหรือconfidential-sandboxในสเปกของพ็อด และต้องใช้ Kubernetes 1.36 ขึ้นไป - โหมด confidential ใช้ cryptographic attestation กับ AWS KMS เพื่อปล่อยกุญแจให้เฉพาะ sandbox ที่รันโค้ดตรงตามที่กำหนด และ AWS ระบุว่าผู้ดูแลคลัสเตอร์อ่านหน่วยความจำของพ็อดไม่ได้
- งบ vCPU รวมของ sandbox ทุกตัวบนอินสแตนซ์ต้องไม่เกิน 5 เท่า ของ vCPU อินสแตนซ์ เช่น อินสแตนซ์ 4 vCPU รัน sandbox ขนาด 1 vCPU ได้สูงสุด 20 ตัว และยังส่ง GPU เข้า sandbox ไม่ได้
- หน้าประกาศของ AWS ระบุว่าใช้ได้ทุกภูมิภาคเชิงพาณิชย์ แต่คู่มือ EKS ระบุว่าพ็อดแบบ isolated และ confidential ใช้ได้ในภูมิภาคเชิงพาณิชย์ของสหรัฐฯ
AWS เปิดตัว AWS Nitro Sandboxes เมื่อวันที่ 9 พฤศจิกายน 2026 ให้พ็อดของ Amazon EKS งาน (task) ของ Amazon ECS และ VM ขนาดเล็กบน EC2 รันอยู่ใน VM แยกของตัวเองที่ Nitro Hypervisor บังคับขอบเขตด้วยฮาร์ดแวร์ โดยไม่คิดค่าบริการเพิ่ม AWS วางให้เป็นที่รันของ AI agent ที่เขียนและรันโค้ดเอง ระบบ SaaS ที่มีลูกค้าหลายรายในคลัสเตอร์เดียว และงานที่อยู่ภายใต้การกำกับ
AWS Nitro Sandboxes แก้ปัญหาอะไร
คอนเทนเนอร์ใน Kubernetes ใช้เคอร์เนลของเครื่องร่วมกัน บล็อกของทีม Amazon EKS อธิบายว่าช่องโหว่ในคอนเทนเนอร์หนึ่งจึงลามไปถึงคอนเทนเนอร์อื่นบนเครื่องเดียวกันได้ ทางออกเดิมคือแยกงานสำคัญไปไว้คนละเครื่อง ซึ่งแพงเพราะเครื่องส่วนใหญ่ว่าง AWS ยกเหตุผล 4 ข้อที่ทำให้ทางออกนี้ไปต่อไม่ได้
- AI agent เขียนและรันโค้ดเอง โดยไม่มีคนตรวจก่อน ถ้าโค้ดหลุดออกจากคอนเทนเนอร์ prompt ที่เป็นอันตรายเพียงครั้งเดียวอาจลามไปทั้งเครื่อง
- SaaS มีลูกค้าหลายร้อยรายในคลัสเตอร์เดียว การให้ EC2 แยกต่อลูกค้าแพงเกินไป
- อุตสาหกรรมที่ถูกกำกับต้องการหลักฐาน ผู้ตรวจสอบตามกรอบอย่าง HIPAA, PCI DSS และ FedRAMP เริ่มขอ cryptographic attestation แทนรายการตรวจการตั้งค่า
- งาน CI/CD และการ build คอนเทนเนอร์ มักต้องใช้สิทธิ์สูงบนเครื่อง
AWS Nitro Sandboxes ให้พ็อดหนึ่งตัวมี VM ของตัวเอง
พ็อดที่เปิดใช้ AWS Nitro Sandboxes จะได้ VM ขนาดเล็กพร้อมระบบปฏิบัติการของตัวเอง แยกจากเครื่องโฮสต์และพ็อดข้างเคียง โดย Nitro Hypervisor แบ่ง CPU และหน่วยความจำให้แต่ละ sandbox ในระดับฮาร์ดแวร์ ส่วนทรัพยากรที่ยังใช้ร่วมกันบนเครื่อง เช่น แบนด์วิดท์เครือข่าย ดิสก์ คำขอ DNS และตาราง conntrack มีการจำกัดอัตราเปิดไว้เป็นค่าเริ่มต้น
การเปิดใช้ AWS Nitro Sandboxes บน EKS Auto Mode คือแก้สเปกของพ็อดบรรทัดเดียว คือ runtimeClassName: isolated-sandbox โดยไม่ต้องแก้อิมเมจหรือ Helm chart ตัวพ็อดยังใช้ EKS Pod Identity, EBS, EFS, CloudWatch และ VPC CNI ได้ตามเดิม และคำสั่ง kubectl exec, logs และ port-forward ทำงานเหมือนเดิม AWS ระบุว่า Nitro Sandboxes ผ่านชุดทดสอบ conformance ของ Kubernetes ทุกข้อ ส่วน EKS แบบปกติต้องสร้าง AMI สำหรับ sandbox เองตามคู่มือ
โหมด isolated กับ confidential
| Isolated | Confidential | |
|---|---|---|
| ชื่อ RuntimeClass บน EKS | isolated-sandbox |
confidential-sandbox |
| ปกป้องจากอะไร | โฮสต์และพ็อดข้างเคียง | รวมถึงผู้ดูแลเครื่องและผู้ดูแลคลัสเตอร์ |
| การพิสูจน์โค้ดที่รัน | ใช้ Cedar policy ภายใน sandbox | Cedar policy + attestation ผ่าน Nitro Security Module |
| การปล่อยกุญแจ | ตามปกติ | AWS KMS ถอดรหัสเฉพาะ sandbox ที่ attestation ตรงกับที่กำหนด |
ในโหมด confidential บล็อกของ AWS ระบุว่าการออกแบบนี้กันไม่ให้ผู้ดูแลคลัสเตอร์อ่านหน่วยความจำของพ็อดได้ ผู้ให้บริการ SaaS จึงพิสูจน์กับลูกค้าได้ว่าข้อมูลของแต่ละรายถูกปกป้องด้วยฮาร์ดแวร์ ถ้าเพิ่ม annotation sandbox.amazonaws.com/network-isolated: "true" VM จะบูตโดยไม่มีเครือข่ายนอกจาก loopback
สำหรับผู้ที่ใช้ EC2 โดยตรง คู่มือ EC2 เรียกโหมดต่างออกไป คือ confidential (ค่าเริ่มต้น) ที่ย้ายหน่วยความจำของ sandbox ออกจากอินสแตนซ์แม่ และ direct ที่อินสแตนซ์แม่ยังเข้าถึงหน่วยความจำได้ ให้ I/O สูงกว่าแต่ไม่มี attestation ส่วน ECS ใช้ AWS Nitro Sandboxes ในชื่อ isolated and confidential tasks บน Amazon ECS Managed Instances ซึ่งคู่มือ ECS บอกว่าให้การแยกใกล้เคียงกับ AWS Fargate
ตัวอย่าง AI agent ที่รันใน Nitro Sandbox
บล็อกของ AWS สาธิตการรัน Claude Code เป็น coding agent ที่อ่าน issue บน GitHub เขียนแก้ รันเทสต์ และเปิด pull request ภายใน sandbox โดยพ็อดเรียก Amazon Bedrock ได้ผ่าน Pod Identity ที่จำกัดสิทธิ์ไว้ที่ bedrock:InvokeModel* เข้า GitHub ได้ด้วย token ที่จำกัดเฉพาะ repository เดียว และนโยบายเครือข่ายปิดทางออกอื่นทั้งหมด เมื่องานจบ VM จะถูกลบทิ้ง
AWS ระบุว่าใช้ร่วมกับโปรเจกต์ agent-sandbox ของ Kubernetes SIG เพื่อเตรียม VM ไว้ล่วงหน้า (warm pool) ให้หยิบใช้ได้ในราว 2 วินาที AWS ยังบอกว่าทดสอบการใช้ Temporal สั่งงาน sandbox แล้ว สร้างตัวอย่างร่วมกับ GitLab Runner และรัน VS Code บนเบราว์เซอร์ใน sandbox ได้
ข้อจำกัดของ AWS Nitro Sandboxes ที่ต้องรู้ก่อนใช้
คู่มือ EC2 ระบุข้อจำกัดหลักไว้ดังนี้
- ใช้ได้เฉพาะอินสแตนซ์ที่รองรับ AWS Nitro Enclaves บนโปรเซสเซอร์ Intel, AMD และ Graviton โดยแต่ละตระกูลมีขนาดที่ยกเว้น เช่น m5.large และ m5.metal
- vCPU รวมของ sandbox ทุกตัวบนอินสแตนซ์ต้องไม่เกิน 5 เท่าของ vCPU อินสแตนซ์ และหน่วยความจำไม่ถูก overcommit จึงอาจหมดก่อน
- ส่ง GPU เข้า sandbox ไม่ได้ในตอนนี้ และปรับขนาด vCPU หรือหน่วยความจำของ sandbox ที่รันอยู่ไม่ได้
- ทรัพยากรเครือข่ายของอินสแตนซ์แม่ใช้ร่วมกัน sandbox ตัวเดียวอาจใช้ conntrack หรือ DNS จนตัวอื่นติดขัด ผู้ดูแลต้องจำกัดอัตราเอง
| vCPU ต่อ sandbox | จำนวน sandbox สูงสุดบนอินสแตนซ์ 4 vCPU |
|---|---|
| 1 | 20 |
| 2 | 10 |
| 4 | 5 |
AWS Nitro Sandboxes ใช้ได้ภูมิภาคไหน ข้อมูลยังไม่ตรงกัน
หน้าประกาศ What's New ระบุว่า AWS Nitro Sandboxes ใช้ได้บนอินสแตนซ์ EC2 ที่ใช้ Nitro เกือบทุกรุ่น ในทุกภูมิภาคเชิงพาณิชย์ทั่วโลก และบล็อกของทีม EKS เขียนว่าใช้ได้ในทุกภูมิภาคเชิงพาณิชย์ แต่คู่มือ Amazon EKS ที่เราเปิดตรวจเมื่อ 10 พฤศจิกายน 2026 ระบุว่าพ็อดแบบ isolated และ confidential ใช้ได้ "in the US commercial AWS Regions" และต้องใช้คลัสเตอร์ Kubernetes 1.36 ขึ้นไป
ภูมิภาค Asia Pacific (Thailand) หรือ ap-southeast-7 เป็นภูมิภาคที่ต้องเปิดใช้ก่อน (opt-in) มี 3 Availability Zone ตามหน้ารายชื่อภูมิภาคของ AWS ทีมในไทยที่ใช้ EKS ในกรุงเทพจึงควรทดสอบว่า RuntimeClass ทั้งสองแบบมีในคลัสเตอร์หรือไม่ก่อนวางแผน
ทำไมเรื่องนี้สำคัญ
ผู้ให้บริการคลาวด์ทุกรายกำลังแข่งกันทำที่รันโค้ดที่ AI สร้างขึ้นอย่างปลอดภัย AWS เพิ่งเปิด Lambda MicroVMs ในภูมิภาคไทย ส่วน Google มี Agent Compute Engine และประกาศใน release notes วันที่ 9 พฤศจิกายน 2026 ว่า Agent Substrate บน GKE เปิดใช้ทั่วไป ความต่างของ AWS Nitro Sandboxes คือย้ายการแยกระดับ VM เข้ามาในคลัสเตอร์ Kubernetes ที่องค์กรใช้อยู่แล้ว โดยไม่ต้องเปลี่ยนไปใช้บริการ serverless และไม่ต้องจ่ายเพิ่ม
สิ่งที่องค์กรไทยควรทำ
- สำรวจงานที่รันโค้ดที่ไม่น่าไว้ใจ เช่น AI agent, CI/CD ที่ใช้สิทธิ์สูง และระบบที่ลูกค้าอัปโหลดสคริปต์ได้ งานเหล่านี้ควรเป็นกลุ่มแรกที่ย้ายเข้า sandbox
- ทดสอบในภูมิภาคที่ใช้จริง โดยเฉพาะ ap-southeast-7 และตรวจว่าเวอร์ชัน Kubernetes ของคลัสเตอร์ถึง 1.36 แล้วหรือยัง
- วางแผนขนาดอินสแตนซ์ใหม่ คิดงบ vCPU และหน่วยความจำของ sandbox ทุกตัว และเลือกตระกูลอินสแตนซ์ที่รองรับ Nitro Enclaves
- ใช้โหมด confidential กับข้อมูลที่อยู่ภายใต้ PDPA เพื่อผูกการปล่อยกุญแจ KMS กับ attestation และเก็บหลักฐานไว้ให้ผู้ตรวจสอบ
- อย่าปิดการจำกัดเครือข่าย ใส่นโยบาย egress และจำกัด DNS กับ conntrack ต่อ sandbox เพราะส่วนนี้ยังใช้ร่วมกันบนเครื่อง
บริการของ THAI DATA CLOUD ที่เกี่ยวข้อง
AWS Nitro Sandboxes ตอกย้ำว่างานที่รันโค้ดจาก AI ควรถูกแยกออกจากระบบหลัก องค์กรไทยที่ต้องการเครื่องแยกไว้ทดสอบหรือรันงานลักษณะนี้ในประเทศ ใช้ Cloud Linux Server ของ THAI DATA CLOUD ที่เลือก Ubuntu, AlmaLinux หรือ Debian ได้ มี Root Access เต็มรูปแบบ และตั้งอยู่ใน Data Center ไทยและสิงคโปร์ (THAI DATA CLOUD เป็นผู้ดำเนินงานเว็บไซต์นี้)
ติดตามข่าวคลาวด์และผู้ให้บริการรายใหญ่ได้ที่หมวด Cloud
คำถามที่พบบ่อย
AWS Nitro Sandboxes คืออะไร?
AWS Nitro Sandboxes คือ VM ขนาดเล็กที่ Nitro Hypervisor ดูแล ซึ่ง AWS เปิดให้ใช้เมื่อ 9 พฤศจิกายน 2026 ใช้รันพ็อดของ Amazon EKS งานของ Amazon ECS หรือ VM บน EC2 แยกกันในขอบเขตระดับฮาร์ดแวร์ แม้อยู่บนอินสแตนซ์เดียวกัน เหมาะกับ AI agent ที่รันโค้ดที่ยังไม่มีใครตรวจ
AWS Nitro Sandboxes มีค่าใช้จ่ายเท่าไร?
หน้าประกาศของ AWS ระบุว่า AWS Nitro Sandboxes ไม่มีค่าบริการเพิ่ม ผู้ใช้จ่ายเฉพาะอินสแตนซ์ EC2 ที่ sandbox รันอยู่ตามปกติ แต่ต้องเผื่อ vCPU และหน่วยความจำให้ sandbox เพราะหน่วยความจำของแต่ละตัวถูกจองไว้ทั้งก้อน
โหมด isolated กับ confidential ต่างกันอย่างไร?
ใน AWS Nitro Sandboxes โหมด isolated ให้แต่ละพ็อดมี VM ของตัวเองเพื่อกันโฮสต์และพ็อดข้างเคียง ส่วนโหมด confidential ถือว่าแม้ผู้ดูแลเครื่องก็ไว้ใจไม่ได้ ใช้ attestation พิสูจน์โค้ดที่รัน และ AWS KMS จะถอดรหัสกุญแจให้เฉพาะ sandbox ที่ผ่านการตรวจ
ใช้ AWS Nitro Sandboxes ในภูมิภาคไทยได้หรือยัง?
ยังต้องตรวจเอง หน้าประกาศของ AWS ระบุว่าใช้ได้ทุกภูมิภาคเชิงพาณิชย์ แต่คู่มือ Amazon EKS ระบุว่าพ็อดแบบ isolated และ confidential ใช้ได้ในภูมิภาคเชิงพาณิชย์ของสหรัฐฯ ผู้ใช้ภูมิภาค Asia Pacific (Thailand) ควรทดสอบก่อนวางแผน
แหล่งอ้างอิง
- Introducing AWS Nitro Sandboxes on Amazon EKS, ECS and EC2 for hardware isolated pods, tasks and VMs — AWS
- AWS Nitro Sandboxes: Hardware-enforced workload isolation on Amazon EKS — AWS Containers Blog
- Isolate workloads with AWS Nitro Sandboxes — Amazon EC2 User Guide
- Sandboxing on Amazon EKS with isolated and confidential pods — Amazon EKS User Guide
- Isolated and confidential tasks — Amazon ECS Developer Guide
- AWS Regions — AWS Documentation
บุคคล องค์กร และสถานที่ในข่าวนี้
เลือกชื่อเพื่ออ่านข่าวทั้งหมดที่กล่าวถึง ตัวเลขคือจำนวนข่าว
- ประเทศและสถานที่
- สหรัฐอเมริกา698สิงคโปร์245
- ผลิตภัณฑ์และเทคโนโลยี
- Amazon EKS8Amazon ECS4Kubernetes46Amazon CloudWatch12Firecracker3AWS Fargate4Claude Code32Amazon Bedrock11Visual Studio Code11Linux139Ubuntu81AlmaLinux62Debian71Amazon EC29
- กฎหมายและมาตรฐาน
- PDPA299
พบข้อมูลคลาดเคลื่อน? แจ้งกองบรรณาธิการ