AWS เปิด Lambda Web Functions ให้รันเว็บเซิร์ฟเวอร์ HTTP โดยตรง

AWS ประกาศ Lambda Web Functions เมื่อ 12 ตุลาคม 2026 โดยขยาย Lambda ให้รับแอป HTTP ที่เปิดพอร์ตตามปกติได้โดยตรง ตัวอย่างในประกาศใช้ Express แต่ AWS ระบุว่าแนวทางเดียวกันใช้กับ Hono, Fastify, Next.js และเฟรมเวิร์ก Node.js อื่นได้ จุดสำคัญคือทีมไม่ต้องแปลงทุก route ให้เป็น event handler แบบ Lambda เดิมก่อน deploy อย่างไรก็ดี นี่เป็นรูปแบบการทำงานใหม่ของ Lambda ไม่ใช่การเปลี่ยนพฤติกรรมของ Event Functions ที่มีอยู่

สามรูปแบบของ Lambda ต่างกันอย่างไร

AWS เรียก Lambda แบบเดิมว่า Event Functions ซึ่งรับ event หนึ่งครั้ง ประมวลผล แล้วตอบกลับ เหมาะกับงาน queue, trigger และงานเบื้องหลัง ส่วน Web Functions ให้โปรเซสเว็บเซิร์ฟเวอร์ฟัง HTTP endpoint แล้วรับหลายคำขอพร้อมกันได้ สูงสุด 128 concurrent requests ต่อ execution environment ตามข้อมูลเปิดตัว รูปแบบที่สามคือ Lambda MicroVMs สำหรับ sandbox ที่แยกและมีวงจรชีวิตที่ผู้ใช้จัดการเอง งานเว็บทั่วไปจึงไม่จำเป็นต้องเลือก MicroVM เพียงเพราะต้องการ HTTP server

ความต่างเรื่องคิดค่าบริการก็ควรอ่านให้ชัด Event Functions คิดตาม wall-clock ในขณะที่ Web Functions คิดเวลาที่ CPU ทำงานจริง และคิดหน่วยความจำตลอดเวลาที่ execution environment ยังอยู่ การรอฐานข้อมูลหรือ API ภายนอกจึงอาจกิน CPU น้อย แต่ไม่ได้แปลว่าค่าใช้จ่ายทั้งหมดเป็นศูนย์ระหว่างรอ ทีมควรทดสอบด้วยรูปแบบทราฟฟิกจริง ทั้งช่วงเงียบ ช่วง burst และช่วงที่ response stream นาน แล้วเทียบกับทางเลือกเดิมก่อนตัดสินใจย้าย

จากแอปเดิมสู่ endpoint

โค้ดตัวอย่างของ AWS อ่าน AWS_LAMBDA_HTTP_ENDPOINT เพื่อทราบ host และ port ที่ต้อง listen จากนั้นสั่ง aws lambda-web deploy --name my-web-app --code ./my-app CLI จะรวม source สร้าง Web Function สร้าง revision แรก และผูก endpoint ให้ คำว่า revision หมายถึง snapshot ของโค้ดที่เปลี่ยนไม่ได้ ส่วน endpoint ชี้ไป revision ที่ต้องรับทราฟฟิก ความแยกนี้ช่วยให้การปล่อยรุ่นใหม่มีขอบเขตชัดเจนกว่าแก้ process ที่รันอยู่โดยตรง

การกระจายหลาย region ใช้ตัวเลือก --regions เช่น us-east-1,eu-west-1,ap-northeast-1 AWS ระบุว่าจะทำสำเนาโค้ดและตั้ง latency-based routing ให้ผ่าน global URL เดียว โดยเลือก region ที่มี latency ต่ำสุดแบบ best effort คำว่า best effort สำคัญมาก: ทีมที่มีข้อกำหนดว่าข้อมูลต้องอยู่ภูมิภาคเดียว ไม่ควรตีความว่าเส้นทางนี้รับประกัน residency หรือ session affinity โดยอัตโนมัติ ต้องตรวจทั้งที่เก็บข้อมูล คุกกี้ การยืนยันตัวตน และปลายทางที่ถูกเรียกจากแต่ละ region

ปล่อยรุ่นและวัดผลอย่างไร

AWS แสดงตัวอย่างการแบ่ง traffic ระหว่าง revision เดิม 90% กับ revision ใหม่ 10% ผ่านการตั้งค่าน้ำหนักที่ endpoint จึงทำ canary rollout ได้โดยไม่ต้องจัด load balancer เพิ่มเอง แต่การแบ่งทราฟฟิกจะมีประโยชน์ก็ต่อเมื่อทีมกำหนดเกณฑ์วัดและ rollback ไว้ก่อน เช่น error rate, p95 latency, อัตรา timeout, การเชื่อมต่อฐานข้อมูล และการใช้หน่วยความจำ ตรวจว่าคำขอที่สร้าง session หรือเขียนข้อมูลจะทำงานร่วมกันได้ระหว่าง revision สองรุ่นด้วย

สำหรับเว็บที่มีทั้ง static และ dynamic AWS เสนอให้ใช้ CloudFront เป็นหน้าบ้าน cache ไฟล์ static แล้วส่ง dynamic requests ไป Web Function endpoint อีกทั้งรองรับ CloudFront origin access control เพื่อให้ CloudFront ลงชื่อคำขอไปยัง origin และจำกัดการเรียก endpoint ไว้เฉพาะ distribution ที่กำหนด นี่เป็นคนละประเด็นกับการให้สิทธิ์ผู้ใช้ในแอป: OAC ปิดทางเข้าตรงของ origin แต่แอปยังต้องตรวจสิทธิ์ของผู้ใช้แต่ละคำขอตามปกติ

ขอบเขตวันเปิดตัว

วันที่ประกาศ AWS ระบุว่า Web Functions ใช้ Node.js 24 บน Arm64 และเปิดใน US East (N. Virginia), US East (Ohio), US West (Oregon), Asia Pacific (Tokyo) และ Europe (Ireland) พร้อมการเชื่อมต่อ VPC การมี global URL จึงไม่ได้หมายความว่ารันได้ทุก region ในวันแรก หากฐานข้อมูลอยู่ภูมิภาคอื่น ให้ประเมินระยะทางเครือข่ายและค่าใช้จ่าย cross-region ก่อน การย้ายแอปควรเริ่มจากบริการทดลองที่ไม่มี state ในเครื่อง ทดสอบ HTTP headers, streaming, timeout, cold start และการเชื่อมต่อ VPC ด้วยข้อมูลจริง แล้วค่อยขยายไป production

อ่านประกาศต้นทางวันที่ 12 ตุลาคม 2026: AWS News Blog — Announcing AWS Lambda Web Functions