AWS เพิ่มฟีเจอร์ Session Endpoints ให้กับ Bedrock AgentCore Runtime เพื่อพรีวิวแอปสดระหว่างพัฒนา
AWS เปิดตัว Session endpoints ใน Amazon Bedrock AgentCore runtime ช่วยให้นักพัฒนาสามารถพรีวิวเว็บแอปในเบราว์เซอร์ได้ ขณะที่ coding agent กำลังสร้างแอปนั้นอยู่
คำตอบโดยย่อ
AWS ประกาศฟีเจอร์ใดสำหรับการพรีวิวผลงานของ coding agent บน Amazon Bedrock AgentCore?
AWS ระบุว่า Amazon Bedrock AgentCore runtime รองรับ Session endpoints แล้ว ซึ่งเป็น URL ที่ผ่านการยืนยันตัวตนและช่วยให้นักพัฒนาเปิดเว็บแอปที่ coding agent กำลังสร้างอยู่ภายใน session ที่แยกตัวออกมาได้โดยตรงในเบราว์เซอร์ของตนเอง endpoint เหล่านี้จะส่งต่อทราฟฟิก HTTP และ WebSocket ไปยังพอร์ตที่นักพัฒนาอนุญาตไว้ ทำให้การเปลี่ยนแปลงปรากฏขึ้นโดยไม่ต้องผ่านขั้นตอนการ deploy แยกต่างหาก
ประเด็นสำคัญ
- AWS เปิดตัว Session endpoints ซึ่งเป็นความสามารถใหม่ของ Amazon Bedrock AgentCore runtime ที่ช่วยให้นักพัฒนาเปิดเว็บแอปที่รันอยู่ภายใน session ของ agent ได้โดยตรงในเบราว์เซอร์ของตนเอง
- agent session แต่ละตัวรันอยู่ในไมโครวีเอ็มที่แยกออกจากกัน และนักพัฒนาเลือกได้ว่า Session endpoint จะเข้าถึงพอร์ตใดได้บ้าง ระหว่างหนึ่งถึงห้ารายการภายในช่วง 8000-12000 โดยตั้งค่าพารามิเตอร์ allowedPorts เมื่อเรียกใช้ CreateAgentRuntime
- AWS ระบุว่าทุกคำขอที่ผ่าน Session endpoint จะต้องผ่านการยืนยันตัวตน โดยใช้ลายเซ็น SigV4 สำหรับ runtime ที่พึ่งพา IAM หรือ bearer token สำหรับ runtime ที่ใช้ตัวยืนยันสิทธิ์แบบ JWT
- AWS เผยแพร่ตัวอย่างไว้ใน repository agentcore-samples บน GitHub ซึ่งแสดงให้เห็น coding agent ที่รักษาเว็บไซต์ Vite ให้ทำงานอยู่ภายใน session ของตน เพื่อให้การเปลี่ยนแปลงปรากฏในเบราว์เซอร์ทันทีที่ agent แก้ไขไฟล์
- AWS ระบุว่า Session endpoint จำกัดขอบเขตอยู่เพียง session เดียว และมีไว้สำหรับการสร้าง ทดสอบ และตรวจสอบผลงานของ agent เท่านั้น ไม่ใช่สำหรับให้บริการแอปแก่ผู้ใช้ทั่วไป ซึ่งต้องอาศัยการ deploy ไปยังบริการโฮสติ้งแยกต่างหากอย่าง AWS Amplify Hosting
สิ่งที่ AWS ประกาศ
Amazon Web Services ระบุว่า Amazon Bedrock AgentCore runtime รองรับฟีเจอร์ใหม่ที่เรียกว่า Session endpoints แล้ว ซึ่งช่วยให้นักพัฒนาสามารถเปิดและโต้ตอบกับเว็บแอปที่ coding agent กำลังสร้างอยู่ได้โดยตรงในเบราว์เซอร์ของตนเอง ขณะที่ agent ยังทำงานอยู่
AWS ระบุว่า AgentCore runtime รัน agent session แต่ละตัวในไมโครวีเอ็ม (microVM) ที่แยกออกจากกันอยู่แล้ว Session endpoints เพิ่มความสามารถในการสร้าง URL ที่ผ่านการยืนยันตัวตนสำหรับ session นั้น โดยจะส่งต่อ HTTP method, path, query string และ body ของแต่ละคำขอ รวมถึงการเชื่อมต่อ WebSocket ไปยังพอร์ตที่นักพัฒนาอนุญาตไว้ AWS กล่าวว่าวิธีนี้ช่วยให้นักพัฒนาเห็นหน้าเว็บอัปเดตทันทีที่ agent บันทึกไฟล์แต่ละไฟล์ โดยไม่ต้องรอให้แอปถูกคัดลอกออกไป deploy ที่อื่นก่อนตรวจสอบแต่ละครั้ง
วิธีการทำงานของ Session Endpoints
AWS อธิบายรายละเอียด 6 ประการที่กำหนดการทำงานของ Session endpoints ไว้ดังนี้
- การเลือกพอร์ต: นักพัฒนาต้องตั้งค่าพารามิเตอร์
allowedPortsเมื่อเรียกใช้CreateAgentRuntimeโดยระบุได้ตั้งแต่หนึ่งถึงห้ารายการ แต่ละรายการเป็นพอร์ตเดียวหรือช่วงพอร์ตภายในขอบเขต 8000-12000 ไม่รวมพอร์ตที่แพลตฟอร์มสงวนไว้ AWS ระบุว่าการอนุญาตพอร์ตไม่ได้หมายความว่าจะเริ่มเซิร์ฟเวอร์โดยอัตโนมัติ แอปพลิเคชันต้อง listen บนพอร์ตนั้นเอง โดยผูกกับ0.0.0.0 - การส่ง URL: การตอบกลับของ
InvokeAgentRuntimeจะพก URL ของ endpoint มาในส่วนหัวX-Amzn-Bedrock-AgentCore-Runtime-Session-Endpoint-Urlซึ่ง SDK ที่รองรับจะแสดงค่านี้ในชื่อsessionEndpointUrl - การยืนยันตัวตน: สำหรับ runtime ที่ใช้ AWS IAM AWS ระบุว่าคำขอ HTTP, สตรีม HTTP/2 และการทำ handshake ของ WebSocket แต่ละครั้งจะพกลายเซ็น Signature Version 4 มาด้วย และผู้เรียกใช้ต้องมีสิทธิ์
bedrock-agentcore:InvokeAgentRuntimeProxyส่วน runtime ที่ใช้ตัวยืนยันสิทธิ์แบบ JWT คำขอแต่ละครั้งจะพก bearer token มาแทน - การกำหนดเส้นทางพอร์ตผ่านชื่อโฮสต์: AWS ระบุว่าไคลเอนต์จะเชื่อมต่อผ่านพอร์ต 443 เสมอ และคำนำหน้าในชื่อโฮสต์จะเป็นตัวเลือกพอร์ตปลายทางภายใน session
- โปรโตคอลที่รองรับ: AWS ระบุว่า endpoint รองรับทราฟฟิก HTTP/1.1, HTTP/2 (รวมถึง server-sent events และ gRPC) และ WebSocket
- ขอบเขตของ Session: AWS ระบุว่า URL นี้ต้องใช้ข้อมูลยืนยันตัวตนในทุกคำขอ และใช้งานได้เพียงช่วงเวลาที่ session ยังดำเนินอยู่เท่านั้น โดยมีไว้สำหรับการสร้าง ทดสอบ และตรวจสอบผลงานของ agent เท่านั้น หากต้องการให้บริการแอปแก่ผู้ใช้ทั่วไป AWS ระบุว่านักพัฒนาควร deploy แอปไปยังบริการโฮสติ้งอย่าง AWS Amplify Hosting
AWS ยังระบุว่าเนื่องจากเบราว์เซอร์ไม่สามารถแนบลายเซ็น SigV4 หรือ bearer token ได้ด้วยตัวเอง ไคลเอนต์ของ Session endpoint ใน SDK ชื่อ bedrock-agentcore จึงสามารถเปิด endpoint ภายในเครื่องของนักพัฒนาได้ ซึ่งจะเพิ่มข้อมูลยืนยันตัวตนให้กับทุกคำขอและการทำ handshake ของ WebSocket ก่อนส่งต่อไปยังเบราว์เซอร์
AWS แยกความแตกต่างระหว่าง Session endpoint กับ runtime endpoint ที่ AgentCore runtime มีให้อยู่แล้ว runtime endpoint เช่น DEFAULT จะควบคุมว่าผู้เรียกใช้เข้าถึง agent เวอร์ชันใด และช่วยให้นักพัฒนาแยกเวอร์ชันสำหรับการพัฒนาและการใช้งานจริงได้ ในขณะที่ Session endpoint จะสะท้อนเวอร์ชันของ agent ที่กำลังทำงานอยู่ใน session นั้นโดยเฉพาะ และจะหยุดทำงานเมื่อ session สิ้นสุดลง
ตัวอย่างการสาธิตการใช้งาน
AWS เผยแพร่ตัวอย่างที่ประกอบด้วย 4 ส่วนหลัก ได้แก่ coding agent ที่รันอยู่บนพอร์ต 8080 ซึ่งแก้ไขไฟล์ของเว็บไซต์โดยใช้เครื่องมือ list, read, write และ edit; เซิร์ฟเวอร์พัฒนา Vite บนพอร์ต 8090 ที่ถูกเริ่มโดย agent ซึ่งให้บริการเว็บไซต์และส่งการเปลี่ยนแปลงที่บันทึกไว้ไปยังเบราว์เซอร์ผ่าน WebSocket แบบ hot-reload; PreviewApp ในเครื่องที่ให้บริการหน้าพรีวิว ส่งพรอมต์ไปยัง InvokeAgentRuntime และเปิด endpoint ภายในเครื่องสำหรับเว็บไซต์; และหน้าพรีวิวเอง ซึ่งโหลดเว็บไซต์ผ่าน endpoint ภายในเครื่องและ Session endpoint พร้อมส่งพรอมต์ไปยัง agent ตัวอย่างฉบับสมบูรณ์ รวมถึงโน้ตบุ๊กที่โพสต์นี้อ้างอิง อยู่ในโฟลเดอร์ 14-remote-access ของ repository agentcore-samples บน GitHub
ที่มา: AWS Machine Learning Blog, "Preview web apps live as your coding agent builds them with Amazon Bedrock AgentCore runtime," เผยแพร่เมื่อวันที่ 30 ตุลาคม 2026
คำถามที่พบบ่อย
- Session endpoint ใน Amazon Bedrock AgentCore runtime คืออะไร?
- AWS อธิบายว่าเป็น URL ที่ผ่านการยืนยันตัวตนและผูกติดกับ agent session เดียว ซึ่งจะส่งต่อคำขอ HTTP และการเชื่อมต่อ WebSocket ไปยังพอร์ตที่นักพัฒนาอนุญาตไว้ ช่วยให้นักพัฒนาเปิดแอปที่ agent กำลังสร้างอยู่ได้ในเบราว์เซอร์ของตนเอง
- AWS รักษาความปลอดภัยทราฟฟิกของ Session endpoint อย่างไร?
- AWS ระบุว่าทุกคำขอต้องผ่านการยืนยันตัวตน โดย runtime ที่ใช้ IAM ต้องมีลายเซ็น SigV4 พร้อมสิทธิ์ bedrock-agentcore:InvokeAgentRuntimeProxy ส่วน runtime ที่ใช้ตัวยืนยันสิทธิ์แบบ JWT ต้องมี bearer token ในทุกคำขอ
- สามารถใช้ Session endpoint เพื่อให้บริการแอปแก่ผู้ใช้ทั่วไปได้หรือไม่?
- ไม่ได้ AWS ระบุว่า URL ของ Session endpoint จะใช้งานได้เพียงช่วงเวลาที่ session ยังดำเนินอยู่เท่านั้น และมีไว้สำหรับการสร้าง ทดสอบ และตรวจสอบผลงานของ agent การให้บริการแอปแก่ผู้ใช้จำเป็นต้อง deploy ไปยังบริการโฮสติ้งแยกต่างหากอย่าง AWS Amplify Hosting
- นักพัฒนาสามารถหาโค้ดตัวอย่างสำหรับฟีเจอร์นี้ได้ที่ไหน?
- AWS ชี้ไปที่โฟลเดอร์ 14-remote-access ของ repository agentcore-samples บน GitHub ซึ่งมีโน้ตบุ๊กสาธิตการใช้งาน coding agent ที่รักษาเว็บไซต์ Vite ให้ทำงานอยู่ภายใน session เพื่อการพรีวิวแบบสด