Azure Container Apps Sandboxes

Sirasit Boonklang

เผยแพร่เมื่อ 6 สิงหาคม 2026

7 การเข้าชม

ให้ AI Agent รันโค้ดที่มันเขียนเอง… บนเครื่องเรา จะปลอดภัยจริงเหรอ?

มีใครเคยลองจะทำ AI Agent เพื่อมาใช้งาน แต่ก็ต้องมานั่งคิดว่า AI Agent เราเขียนโค้ดได้ รันโค้ดได้ แล้วมันจะไปลบไฟล์อะไรของเราหรือป่าว แอบเอา credential เราไปใช้มั้ย เราก็เลยต้องเปิด VM หรือ Container เพื่อแยกเอาไว้ แต่ประเด็นคืองั้นเราก็ต้องเปิดทิ้งไว้ ถ้าเช่าคลาวด์ก็ต้องเปิดรอไว้เสียค่าคลาวด์ทั้งเดือนแบบ 24/7

Azure Container Apps Sandboxes คืออะไร?

เมื่อ 2 มิถุนายน 2026 Microsoft ได้เปิดบริการใหม่ที่น่าจะแก้ปัญหาด้านบนได้ วันนี้แอดพาทุกคนมาลองไปพร้อมกัน มันชื่อว่า Azure Container Apps Sandboxes แอดลองใช้มาแล้วคิดว่ามันเหมือนเป็น sandbox ที่มี AI อยู่ข้างใน เปิดปิดได้ไว เมื่อเราไม่ใช้มันก็ไม่เสียเงิน โดยตัว Sandbox แต่ละตัวจะรันอยู่ใน microVM ของตัวเอง

microVM คืออะไร? เราต้องเข้าใจก่อนว่าปกติปกติแล้วตอนที่เรารัน Container หลาย ๆ ตัว ตัวบนเครื่องเดียวกัน มันจะแชร์ Kernel ของ OS ร่วมกัน ซึ่งถ้ามีช่องโหว่ก็อาจหลุดข้ามไปหากันได้ ส่วน microVM คือ Virtual Machine ขนาดจิ๋วที่มี Kernel เป็นของตัวเอง แยกกันในระดับ Hardware แต่ยังบูตเร็วเหมือน Container เลยได้ทั้งความเร็วและความปลอดภัย

เราแค่ชี้ไปที่ OCI Image ที่เราอยากใช้ ที่เหลือ Azure จัดการให้หมด

OCI Image คืออะไร? OCI (Open Container Initiative) คือมาตรฐานกลางของ Container Image ถ้าใครเคยเขียน Dockerfile แล้ว build เป็น image ก็คืออันนี้แหละครับ ไม่ต้องเรียนรู้ format ใหม่เลย

จุดที่น่าสนใจคือ Sandboxes ไม่ใช่ของที่ Microsoft เพิ่งทำเสร็จแล้วโยนมาให้เราลอง จริง ๆ แล้วข้างใน Cloud Sandboxes จะมี GitHub Copilot, Foundry Hosted Agents และ Azure Container Apps Express ที่ก่อนหน้านี้ทีม Microsoft เค้าก็ใช้กันเองข้างใน แต่ตอนนี้เปิดมาให้พวกเราใช้กันได้

ดียังไง? ทำอะไรได้บ้าง?

1. เปิดเร็วระดับ Sub-second และไม่ใช้ไม่จ่าย

Sandbox บูตจาก pool ที่ warm ไว้อยู่แล้ว เลยเปิดได้ในเวลาไม่ถึงวินาที และ scale ไปถึงหลักพันตัวได้ ที่สำคัญคือคิดเงินแบบ per-second ตาม vCPU/Memory ที่ใช้จริง ตอนไม่มีงาน = ไม่มีค่าใช้จ่าย

2. Snapshot หยุดงานค้างไว้ได้ แล้วกลับมาต่อจากจุดเดิมเป๊ะ ๆ

อันนี้คือพระเอกของงานนี้เลยครับ Snapshot จะเก็บสถานะทั้งหมดของ Sandbox ไว้ ทั้ง Memory, Disk และ Process ที่กำลังรันอยู่ พอเรา resume กลับมา ทุก process ทุกไฟล์ที่เปิดค้าง ทุกตัวแปรใน memory จะกลับมาเหมือนเดิมทั้งหมด

เอาไปใช้อะไรได้บ้าง

Checkpoint กลางทาง — Agent ที่ทำงานยาว ๆ ข้ามวัน หยุดแล้วมาต่อได้ตรงจุดเดิม
Clone environment ที่ warm แล้ว — ลง dependency ครบ, cache เต็ม, service รันอยู่ แล้ว copy ไปใช้ต่อได้เลย
แจก state สำเร็จรูป — resume ในเสี้ยววินาที แทนที่จะรอ cold boot ใหม่ทุกครั้ง

ช่วง Preview นี้ Snapshot ฟรี ครับ หลังจากนั้นจะคิดตามเรตของ Azure Blob Storage ปกติ

3. Lifecycle Policy ตั้งให้มันดูแลตัวเอง

อันนี้คือเราไม่ต้องเขียนโค้ดยิงมาเช็คว่า sandbox นี้ไม่ได้ใช้แล้วหรือป่าว เราสามารถตั้งค่าให้ระบบพักไปเองได้ เช่น ตั้ง Auto-Suspend ให้ idle timeout ได้ตั้งแต่ 1, 2, 5, 10, 30 ถึง 60 นาทีได้ พอครบเวลาแล้วไม่มีคนใช้ ระบบก็จะพักให้เอง โดยเราเลือกได้ทั้ง 2 โหมด

Disk + Memory — อันนี้จะเป็นค่าเริ่มต้น มันจะเก็บไว้ให้ครบเลยทั้ง memory และ process เรากด resume มามันก็จะกลับมาทั้งหมด ต่อได้ทันที
Disk — อันนี้จะเก็บแค่ไฟล์ พอเรา resume แล้ว VM ก็จะเริ่มใหม่ เหมือนปิดเครื่องแล้วเปิดใหม่ ไฟล์ยังอยู่ แบบนี้จะเหมาะกับงานที่ไม่ต้องการ process ต่อเนื่อง

💡 ลองนึกภาพ platform ที่มีลูกค้าหลักพันคน ตั้ง idle timeout ไว้ 1 นาทีพร้อมโหมด Memory พอลูกค้าหยุดใช้ปุ๊บ มิเตอร์หยุดหมุนแทบจะทันที แต่พอกลับมาก็ resume ต่อได้ในเสี้ยววินาที นี่คือเหตุผลที่มันคุ้มค่าในสเกลใหญ่

4. Network Egress Policy คุมว่าให้ยิงเน็ตออกไปไหนได้บ้าง

อันนี้จะเหมาะกับงานที่เราต้องรันโค้ดที่เราไม่ไว้ใจ เช่น โค้ดที่ LLM เขียนขึ้นมาเอง หรือโค้ดที่ user ส่งเข้ามาตั้งได้แบบ per-sandbox เลย

Default action — จะ Allow หรือ Deny traffic ขาออกทั้งหมดไว้ก่อน
Host rules — ระบุ domain pattern ได้ เช่น github.com แบบ wildcard แล้ว Allow
Custom CIDR rules — คุมระดับ IP range เช่น 10.0.0.0/8 แล้ว Deny
Skip egress proxy — ข้าม proxy ไปเลย ถ้าเราจัดการ routing เองใน VNet อยู่แล้ว

ทำให้เราตั้งท่า deny-by-default ได้ คือปิดทางออกทั้งหมดก่อน แล้วค่อยเปิดเฉพาะที่จำเป็น เช่น API server ของเรากับ package registry โดยไม่ต้องไปตั้ง NSG หรือซื้อ firewall appliance มาเพิ่ม

5. Volume เก็บข้อมูลถาวรได้

ประเภท	เบื้องหลังคือ	เหมาะกับ
Managed Azure Blob	Azure Blob Storage	แชร์ข้อมูลข้าม sandbox, อัปโหลด/ดาวน์โหลดไฟล์, เก็บ artifact
Managed Data Disk	Azure Disk Storage	งานที่ต้องการความเร็วสูง เช่น database, build cache (ใช้ได้ทีละ 1 sandbox เท่านั้น)

6. Secrets และ Managed Identity

Sandbox Group เก็บ secret แบบ key-value ได้ และที่ฉลาดคือ secret พวกนี้เอาไปใช้ใน egress policy เพื่อแทรก header หรือ transform request ได้ โดยที่โค้ดที่รันอยู่ข้างใน sandbox มองไม่เห็นค่า secret เลย

ส่วน Managed Identity รองรับทั้ง system-assigned และ user-assigned พร้อม RBAC ครบ

📌 Managed Identity คืออะไร? คือการให้ Azure ออก “บัตรประจำตัว” ให้ resource ของเราโดยตรง เวลาจะต่อ Key Vault, Storage หรือ Cosmos DB ก็ใช้บัตรนี้ยืนยันตัวตนได้เลย ไม่ต้องเอา username/password หรือ connection string ไปฝังในโค้ด

7. MCP Connectors และ Triggers

Sandboxes ต่อกับ external API ผ่าน MCP (Model Context Protocol) ได้ ครอบคลุม Microsoft 365, Salesforce, ServiceNow, GitHub และระบบอื่นอีกกว่า 1,400 ระบบ โดยไม่ต้องจัดการ credential เอง แค่แนบ Connector Gateway เข้ากับ Sandbox Group ทุก sandbox ในกลุ่มก็เรียกใช้ได้หมด

พอจับคู่กับ Trigger ก็ทำ event-driven automation ได้เลย เช่น มีเมลเข้า Outlook → ส่งเข้า sandbox ให้ AI Agent คัดแยกให้ หรือมีไฟล์อัปขึ้น SharePoint → sandbox ดึงข้อมูลออกมาประมวลผลต่อ โดย trigger สั่งได้ทั้งการรัน shell command ข้างใน sandbox หรือยิงไปที่ HTTP endpoint ที่ sandbox เปิดไว้

เอาไปใช้ทำอะไรได้จริงบ้าง?

ระบบ Build & Test ของตัวเอง — เสียบเข้า CI/CD flow ให้ build บนคลาวด์ ส่วนโน้ตบุ๊กเราเย็น ๆ ไป
Agent ที่รันอะไรก็ได้อย่างปลอดภัย — Agent เปิด sandbox ขึ้นมา สั่งงาน แล้วเอาผลลัพธ์กลับมา โดยไม่ต้องให้สิทธิ์อะไรกับเครื่อง host เลย
Agent Swarm — แตกคำถามวิจัยเป็นชิ้นย่อย ปั้ม sandbox ขึ้นมา N ตัวพร้อมกัน แต่ละตัวใช้ image และ egress policy ของตัวเอง แล้วค่อยรวมผลลัพธ์

เริ่มใช้ยังไง? มาลองทำ Step by Step กัน

วิธีที่ 1: ผ่าน Azure Portal (แนะนำสำหรับมือใหม่)

Step 1 — เข้าหน้า Portal ใหม่
เปิด sandboxes.azure.com ตัวนี้เป็น Azure Container Apps Portal โฉมใหม่ที่ให้ประสบการณ์เหมือนใช้ IDE เลย (Sandboxes มีให้ใช้เฉพาะใน portal ตัวใหม่นี้เท่านั้นนะครับ)

Step 2 — สร้าง Sandbox Group ก่อน
เลือก Subscription, Resource Group และ Region จากนั้นตั้งค่าเพิ่มเติมได้ตามนี้

Sandbox defaults (ไม่ใส่ก็ได้) — CPU, memory, disk, จำนวน sandbox สูงสุด, idle timeout เริ่มต้น
Networking — จะ deploy ลง custom VNet พร้อม subnet เฉพาะก็ได้ ถ้าอยากได้ private networking
Identity — เลือก system-assigned หรือ user-assigned Entra identity

Step 3 — สร้าง Sandbox ข้างใน Group
Portal มีทางเลือกให้ 3 แบบ

แบบ	เหมาะกับ
Standard Sandbox	คุมได้ครบทุกอย่าง ทั้ง source, resource, lifecycle, networking, volume
GitHub Copilot Sandbox	preset สำเร็จรูป มี Copilot CLI พร้อมใช้ ใส่ GitHub credential ผ่าน Access Token ได้ตั้งแต่ก่อนสร้าง
Claude Sandbox	ลง Claude CLI มาให้แล้ว พร้อมทำ agentic coding ข้างใน sandbox ได้เลย

Step 4 — เลือก Resource Tier

Tier	CPU	Memory	Disk
XS	0.25 vCPU	0.5 GB	5 GB
S	0.5 vCPU	1 GB	10 GB
M (default)	1 vCPU	2 GB	20 GB
L	2 vCPU	4 GB	40 GB
XL	4 vCPU	8 GB	80 GB

⚠️ ข้อควรระวัง: ถ้าสร้าง sandbox จาก snapshot tier จะถูกสืบทอดมาจาก snapshot นั้นและ เปลี่ยนไม่ได้ เพราะระบบต้องการให้สภาพแวดล้อมที่ restore กลับมามี resource เท่ากับตอนที่ snapshot ไว้เป๊ะ ๆ

Step 5 — เลือก Disk Image
Sandbox บูตจาก Disk Image ซึ่งก็คือ OCI Image ที่ถูกแปลงเป็น root filesystem แบบ optimize มาแล้ว เราเลือกได้ว่าจะใช้

Image สำเร็จรูปที่ platform เตรียมไว้ให้ เช่น Ubuntu base image
Image ส่วนตัวจาก private registry — ยืนยันตัวตนด้วย username/token หรือใช้ user-assigned managed identity กับ Azure Container Registry (ACR) ก็ได้

Step 6 — เข้าไปเล่นในหน้า Sandbox Detail
พอสร้างเสร็จ หน้ารายละเอียดจะมี terminal ให้เข้าไปสั่งงานได้ทันที พร้อมแท็บอื่น ๆ อีกเพียบ

Network Audit — log traffic ขาออกแบบ real-time เห็นเลยว่าอันไหนผ่าน อันไหนโดนบล็อก
Monitor — กราฟ CPU, memory, disk, network แบบสด ๆ
Connectors / Volumes — ดูและเพิ่ม connection กับ volume
Log Stream — log ของ container แบบ streaming
Processes — ดู process ที่รันอยู่ข้างใน
Files — file explorer ไว้ browse ไฟล์ใน sandbox

Step 7 — จัดการสถานะและ policy
ที่ toolbar จะมีปุ่ม Resume กับ Stop ส่วนใน เมนู ⁝ (Ellipsis) จะมีของสำคัญซ่อนอยู่

Egress Policy — ตั้งกฎเน็ตขาออก
Add port — เปิด ingress
Snapshot — เซฟสถานะปัจจุบันทั้งหมด
Commit — เซฟ disk state เป็น disk image ตัวใหม่
Lifecycle Policy — ตั้ง auto-suspend / auto-delete
Delete — ลบถาวร

วิธีที่ 2: ผ่าน CLI

⚠️ จุดที่ต้องจำ: ทุกคำสั่งที่เกี่ยวกับ sandbox ใช้ aca CLI ทั้งหมด ไม่มี คำสั่ง az containerapp sandbox นะครับ ส่วน az ใช้แค่ az login, az account show และจัดการ resource group เท่านั้น

Step 1 — ติดตั้ง aca CLI

## Mac, Linux
curl -fsSL https://aka.ms/aca-cli-install | sh
## Windows
irm https://aka.ms/aca-cli-install-ps | iex

Step 2 — Login และดูคำสั่งที่มี

az login
az account show
aca --help

Step 3 — ถ้าอยากใช้ Python SDK ก็ลงเพิ่ม

pip install azure-containerapps-sandbox

รายละเอียด quick start และตัวอย่างเต็ม ๆ ของทั้ง CLI และ Python SDK ดูได้ที่ sandboxes.azure.com

วิธีที่ 3: สั่งผ่าน Coding Agent (สายขี้เกียจจำคำสั่ง)

ถ้าใครใช้ Copilot CLI หรือ Claude Code อยู่แล้ว ไม่ต้องไปนั่งท่อง CLI ใหม่เลยครับ ลง skill ตัวนี้ครั้งเดียวจบ

## GitHub Copilot CLI
## เพิ่ม plugin marketplace
/plugin marketplace add microsoft/azure-container-apps
## ติดตั้ง skill ทั้งหมด
/plugin install sandboxes@Azure-Container-Apps

## Claude Code
claude plugin add microsoft/azure-container-apps

Skill ตัวนี้จะเช็ค prerequisite ให้เงียบ ๆ เอง (az –version, az account show, node –version, aca –version) ถ้าขาดอะไรค่อยเด้งมาถาม แล้วมันจะแปลงภาษาคนที่เราพิมพ์ไปเป็นคำสั่ง aca ที่ถูกต้องให้ พร้อม runbook สำเร็จรูปทั้งเรื่อง Copilot CLI BYOK (เอา Azure OpenAI key ของตัวเองมาใช้), การ deploy web app และการ setup shell

แล้วถ้าเคยใช้ Dynamic Sessions อยู่ล่ะ?

ใครที่ใช้ Azure Container Apps Dynamic Sessions อยู่ ให้มอง Sandboxes เป็น รุ่นต่อไปของมัน ครับ อะไรที่ Sessions ทำได้ Sandboxes ทำได้หมด และทำได้มากกว่าเยอะ

ความสามารถ	Dynamic Sessions	Sandboxes
Startup ระดับ sub-second	✓	✓
Isolation ที่แข็งแรง	✓	✓
Custom container image	✓	✓
Custom VNet integration	✓ (บางส่วน)	✓
Suspend/Resume ด้วย Memory + Disk snapshot	–	✓
Lifecycle policy (auto-suspend, auto-delete)	–	✓
Network egress policy รายตัว	–	✓
Persistent managed volume (Blob, Data Disk)	–	✓
Managed identity (system + user-assigned)	–	✓
Secrets management	–	✓
ปรับ resource tier ได้	–	✓
เข้าถึง sandbox ตรง ๆ ผ่าน Portal	–	✓

Microsoft ยืนยันว่ายังซัพพอร์ต Dynamic Sessions ต่อ แต่ การลงทุนพัฒนาใหม่ทั้งหมดจะไปที่ Sandboxes ดังนั้นถ้ากำลังจะเริ่มโปรเจกต์ใหม่บน ephemeral compute ก็เริ่มที่ Sandboxes ได้เลย

สรุปสั้น ๆ และข้อควรรู้

Azure Container Apps Sandboxes คือ compute แบบใช้แล้วทิ้งที่ปลอดภัย เปิดเร็วระดับ sub-second และไม่เสียเงินตอน idle รันอยู่ใน microVM แยก hardware กันชัดเจน

จุดขายหลักคือ Snapshot ที่เก็บทั้ง memory, disk และ process ทำให้หยุดงานค้างไว้แล้วกลับมาต่อจุดเดิมได้จริง เหมาะกับ Agent ที่ทำงานยาวข้ามวัน

มี Egress Policy รายตัว ทำให้ตั้ง deny-by-default แล้วเปิดเฉพาะปลายทางที่จำเป็นได้ โดยไม่ต้องยุ่งกับ NSG หรือ firewall

โครงสร้างมีแค่ 2 ชั้นคือ Sandbox Group (กล่องใหญ่คุม config ร่วม) และ Sandbox (ตัวลูกที่ปรับแต่งเองได้)

⚠️ ตอนนี้ยังเป็น Public Preview ควรลองใน environment ที่ไม่ใช่ production ไปก่อน
⚠️ Snapshot ฟรีเฉพาะช่วง Preview หลังจากนั้นคิดตามเรต Azure Blob Storage — ตั้ง Auto-Delete ไว้ด้วยจะดีมาก ไม่งั้นของเก่าค้างกินเงินไม่รู้ตัว
⚠️ ทุกคำสั่งใช้ aca ไม่ใช่ az containerapp sandbox จำผิดคือหาไม่เจอแน่นอน
⚠️ สร้าง sandbox จาก snapshot แล้ว เปลี่ยน resource tier ไม่ได้

ใครที่กำลังทำ AI Agent แล้วติดปัญหาว่าจะให้มันลงมือทำจริงยังไงให้ปลอดภัย อันนี้คือของที่ควรลองครับ 🚀

Reference
Introducing Azure Container Apps Sandboxes: Secure Infrastructure for Agentic Workloads | Microsoft Community Hub
Azure Container Apps Sandboxes Portal