
บทนำ
AWS Lambda เป็นบริการยอดนิยมของ AWS สำหรับสร้างระบบแบบ Serverless ที่ไม่ต้องดูแลเซิร์ฟเวอร์เอง และสามารถขยายระบบได้อัตโนมัติ (Auto Scale) แต่เมื่อระบบเติบโตขึ้น นักพัฒนาหลายคนมักพบปัญหาที่เรียกว่า Cold Start — ซึ่งส่งผลต่อความเร็วและประสิทธิภาพของแอปโดยตรง
ในบทความนี้ เราจะอธิบายวิธีแก้ปัญหา Cold Start และการใช้ Provisioned Concurrency เพื่อ Optimize การทำงานของ Lambda ให้พร้อมรองรับโหลดระดับ Production ได้อย่างราบรื่น

Cold Start คืออะไร?
Cold Start คือช่วงเวลาที่ Lambda ต้อง “เริ่มต้นใหม่” ก่อนจะรันโค้ดครั้งแรก เช่น เมื่อมีการเรียกใช้งานครั้งแรกหลังจากไม่มีการใช้งานมาระยะหนึ่ง AWS จะต้องทำขั้นตอนเหล่านี้:
- ⚙️ สร้าง Environment ใหม่ (Container)
- 📦 โหลดโค้ดและ Dependency
- 🚀 Initialize Runtime (Node.js, Python, Java, ฯลฯ)
ขั้นตอนเหล่านี้ใช้เวลาไม่กี่ร้อยมิลลิวินาทีถึงหลายวินาที ขึ้นอยู่กับภาษาและขนาดของโค้ด

Cold Start vs Warm Start
| ประเภท | คำอธิบาย | เวลาตอบสนอง |
|---|---|---|
| Cold Start | Container ใหม่ต้องถูกสร้างและโหลดโค้ดใหม่ทั้งหมด | ช้ากว่า (500ms – 3s) |
| Warm Start | ใช้ Container เดิมที่ยังอยู่ใน Memory | เร็วมาก (น้อยกว่า 100ms) |
ปัจจัยที่ทำให้เกิด Cold Start
- 🧩 ใช้ Runtime ที่มี Overhead สูง (เช่น Java, .NET)
- 📦 Dependency ขนาดใหญ่ (npm, pip package)
- 🕒 Lambda ว่างนานจน Container ถูกล้าง
- 🧠 Memory หรือ Timeout สูงเกินจำเป็น
- 🌍 เรียก Lambda จาก Region ที่ไม่เหมาะสม
วิธีลดปัญหา Cold Start
- เลือก Runtime ที่เบา เช่น Node.js, Python
- ใช้ Lambda Layer เพื่อแยก Dependency
- ใช้ Provisioned Concurrency เพื่อ Pre-warm Function
- ลดขนาดโค้ด (Zip file) ให้เล็กที่สุด
- เปิดใช้ VPC อย่างระมัดระวัง (เพราะเพิ่ม Latency)
Provisioned Concurrency คืออะไร?
Provisioned Concurrency คือฟีเจอร์ของ AWS Lambda ที่ช่วยให้ระบบเตรียม Environment ของ Function ล่วงหน้าไว้เสมอ ทำให้ไม่เกิด Cold Start แม้มีการเรียกใช้งานครั้งแรก
กล่าวง่าย ๆ คือ AWS จะ “เปิดเครื่อง Lambda” ค้างไว้ตามจำนวนที่เรากำหนด เพื่อให้พร้อมตอบสนองทันทีทุกเวลา
ตั้งค่า Provisioned Concurrency ด้วย AWS Console
- ไปที่ AWS Lambda Console
- เลือก Function ที่ต้องการ
- คลิกแท็บ “Configuration” → “Concurrency”
- เปิด “Provisioned Concurrency” และกำหนดค่า เช่น 10
ตั้งค่า Provisioned Concurrency ด้วย CLI
aws lambda put-provisioned-concurrency-config \
--function-name myLambdaFunction \
--qualifier 1 \
--provisioned-concurrent-executions 10
ตัวอย่างการ Optimize Lambda (Node.js)
// index.mjs
import AWS from 'aws-sdk';
const dynamo = new AWS.DynamoDB.DocumentClient();
export const handler = async (event) => {
const start = Date.now();
const result = await dynamo.scan({ TableName: 'Users' }).promise();
const end = Date.now();
console.log(`Execution time: ${end - start}ms`);
return {
statusCode: 200,
body: JSON.stringify({ count: result.Items.length })
};
};
การ Optimize แบบนี้จะเน้นให้ Lambda ทำงานเร็วขึ้น และลดโอกาสที่ระบบต้องสร้าง Container ใหม่บ่อย ๆ
การวัดผลการ Optimize Lambda
หลังจากเปิด Provisioned Concurrency แล้ว ควรวัดผลโดยใช้ CloudWatch Metrics เช่น:
- 🕒 Duration – เวลาในการรัน Lambda
- ⚡ Invocations – จำนวนครั้งที่ถูกเรียก
- 🔥 ConcurrentExecutions – จำนวน Execution พร้อมกัน
- ❄️ ColdStartCount – จำนวนครั้งที่เกิด Cold Start
สรุปข้อดีของ Provisioned Concurrency
- ✅ ลดเวลาตอบสนองครั้งแรก (Cold Start = 0)
- ✅ ควบคุมประสิทธิภาพของระบบให้คงที่
- ✅ เหมาะกับ API หรือระบบเรียลไทม์
- ✅ รองรับระบบที่ต้องการ Latency ต่ำ
ข้อควรระวัง
- 💰 มีค่าใช้จ่ายเพิ่มขึ้นตามจำนวน Provisioned Concurrency
- ⚙️ ต้องวางแผนกำหนดค่าให้เหมาะกับปริมาณ Request
- 📈 ควร Monitor การใช้งานผ่าน CloudWatch เพื่อปรับค่าตามจริง
สรุป
ปัญหา Cold Start เป็นสิ่งที่หลีกเลี่ยงได้ยากในการใช้ AWS Lambda แต่สามารถจัดการได้ด้วยการ Optimize โค้ด, แยก Dependency, และใช้ Provisioned Concurrency เพื่อเตรียม Environment ล่วงหน้า ช่วยให้ระบบของคุณตอบสนองได้รวดเร็ว และพร้อมรองรับผู้ใช้จำนวนมากในระดับ Production
หากคุณกำลังสร้างระบบแบบ Serverless ที่ต้องการความเร็วสูง — การเข้าใจและปรับแต่ง Lambda ให้เหมาะสมคือกุญแจสำคัญที่จะทำให้ระบบคุณ “เร็ว แรง และเสถียร”
📘 บทความโดย King Pool
ภาพประกอบ: Lambda Cold Start, Provisioned Concurrency, CloudWatch Metrics
อ่านต่อ: การออกแบบ Serverless Architecture ที่รองรับ Scale หลักล้าน Request