คำตอบสั้น: Cloudflare Workers คิดเงินตาม CPU time ส่วน AWS Lambda คิดตาม wall-clock duration ทั้งก้อน ถ้า API ของคุณใช้เวลาส่วนใหญ่ไปกับการรอฐานข้อมูลหรือ API ภายนอก Workers จะถูกกว่าอย่างชัดเจน แต่ถ้างานของคุณกินซีพียูจริงจังและปริมาณไม่สูงมาก Lambda อาจถูกกว่าเพราะ free tier 400,000 GB-second ต่อเดือน และ Workers ยังติดเพดานหน่วยความจำ 128 MB ที่ปรับเพิ่มไม่ได้ (ราคา ณ กรกฎาคม 2026)
คำถามที่ทีมวิศวกรรมถามบ่อยที่สุดเวลาเทียบสองแพลตฟอร์มนี้คือ “อันไหนถูกกว่า” ซึ่งเป็นคำถามที่ตอบไม่ได้ถ้าไม่รู้ก่อนว่าโค้ดของคุณใช้เวลาไปกับอะไร เพราะโมเดลการคิดเงินของสองเจ้านี้ต่างกันในระดับรากฐาน ไม่ใช่แค่ตัวเลขต่างกัน
บทความนี้ใช้ตัวเลขจากเอกสารทางการของ Cloudflare และ AWS ณ กรกฎาคม 2026 เท่านั้น ไม่มีตัวเลขที่เดาเอง และคำนวณให้ดูทีละขั้นสามสถานการณ์ ซึ่งได้ผู้ชนะไม่เหมือนกันทั้งสามครั้ง
ความต่างที่สำคัญที่สุด: CPU time ไม่ใช่ wall-clock time
AWS Lambda คิดเงินจาก duration คือเวลาที่ฟังก์ชันทำงานตั้งแต่เริ่มจนจบ วัดเป็น GB-second โดยคูณหน่วยความจำที่คุณตั้งไว้กับเวลาที่ผ่านไปจริง ถ้าฟังก์ชันของคุณยิง query ไป RDS แล้วรอผลลัพธ์อยู่ 180 มิลลิวินาที เวลา 180 มิลลิวินาทีนั้นถูกคิดเงินเต็ม ๆ ทั้งที่ซีพียูไม่ได้ทำอะไรเลย และ cold start ก็นับรวมอยู่ใน duration ที่คิดเงินด้วย
Cloudflare Workers ไม่ทำแบบนั้น เอกสารของ Cloudflare ระบุตรง ๆ ว่า CPU time วัดเฉพาะเวลาที่ซีพียูประมวลผลโค้ดของคุณ และการรอ network request เช่น fetch() การอ่าน KV หรือ query ฐานข้อมูล ไม่ถูกนับเป็น CPU time แผน Workers Paid ระบุชัดว่า “no charge or limit for duration” แปลว่าคุณจ่ายเฉพาะเวลาที่โค้ดทำงานจริง
ผลลัพธ์ในทางปฏิบัติคือ Worker ที่รอ API ภายนอก 2 วินาทีแต่ประมวลผลจริง 5 มิลลิวินาที จ่ายเท่ากับ Worker ที่ตอบทันทีใน 5 มิลลิวินาที ในขณะที่ Lambda ตัวเดียวกันจะโดนคิดเงิน 2 วินาทีเต็ม นี่คือจุดที่ส่วนต่างราคาเกิดขึ้น และเป็นเหตุผลเดียวที่ทำให้ตัวเลขในตารางข้างล่างออกมาแบบนั้น
Cloudflare ยังระบุด้วยว่า Worker โดยเฉลี่ยใช้ CPU time ประมาณ 2.2 มิลลิวินาทีต่อ request ส่วนงานที่หนักขึ้น เช่น การทำ authentication การ render ฝั่งเซิร์ฟเวอร์ หรือการ parse payload ขนาดใหญ่ มักอยู่ที่ 10–20 มิลลิวินาที ตัวเลขนี้มีประโยชน์มากตอนประมาณการ เพราะคนส่วนใหญ่ประเมิน CPU time ของตัวเองสูงเกินจริง
ราคาจริง ณ กรกฎาคม 2026
| รายการ | Cloudflare Workers | AWS Lambda |
|---|---|---|
| ค่าบริการรายเดือนขั้นต่ำ | $5 (Workers Paid) | ไม่มี จ่ายตามใช้จริง |
| Request ที่รวมมาแล้ว | 10 ล้าน/เดือน | 1 ล้าน/เดือน (free tier) |
| Request ส่วนเกิน | $0.30 ต่อล้าน | $0.20 ต่อล้าน |
| หน่วยที่ใช้คิดค่าประมวลผล | CPU-millisecond | GB-second (wall-clock) |
| ค่าประมวลผลที่รวมมาแล้ว | 30 ล้าน CPU-ms/เดือน | 400,000 GB-s/เดือน (free tier) |
| ค่าประมวลผลส่วนเกิน | $0.02 ต่อล้าน CPU-ms | $0.0000166667 ต่อ GB-s (x86) $0.0000133334 ต่อ GB-s (Arm) |
| คิดเงินตอนรอ I/O | ไม่คิด | คิดเต็ม รวม cold start |
| หน่วยความจำ | 128 MB คงที่ ปรับไม่ได้ | 128 MB – 10,240 MB ปรับได้ |
ข้อสังเกตที่คนมองข้าม: ราคา request ของ Workers ($0.30 ต่อล้าน) แพงกว่า Lambda ($0.20 ต่อล้าน) อยู่ 50% ดังนั้นถ้าฟังก์ชันของคุณเบามากและปริมาณสูงมาก ฝั่ง request อย่างเดียว Lambda จะถูกกว่า ส่วนต่างจะไปพลิกกลับก็ต่อเมื่อ duration ของ Lambda สูงพอ
คำนวณจริงสามสถานการณ์
สมมติฐานเดียวกันทุกกรณี: Lambda ใช้ x86 หน่วยความจำ 128 MB ราคา us-east-1 และหักกับ free tier ให้แล้ว ส่วน Workers อยู่บนแผน Paid ที่รวม $5 ต่อเดือนแล้ว ตัวเลขทั้งหมดคือราคา ณ กรกฎาคม 2026 และปัดทศนิยมสองตำแหน่ง
สถานการณ์ A: API ปกติ 50 ล้าน request/เดือน, 200 ms wall-clock, 8 ms CPU
ฝั่ง Lambda: ค่า request คือ (50,000,000 − 1,000,000) / 1,000,000 × $0.20 = $9.80 ส่วนค่าประมวลผลคือ 50,000,000 × 0.2 วินาที = 10,000,000 วินาที คูณด้วย 128/1024 = 0.125 GB ได้ 1,250,000 GB-s หัก free tier 400,000 เหลือ 850,000 GB-s × $0.0000166667 = $14.17 รวม $23.97 ต่อเดือน
ฝั่ง Workers: ค่าสมัคร $5.00 ค่า request คือ (50,000,000 − 10,000,000) / 1,000,000 × $0.30 = $12.00 ส่วน CPU time คือ 50,000,000 × 8 ms = 400,000,000 CPU-ms หักที่รวมมาแล้ว 30,000,000 เหลือ 370,000,000 หารล้านคูณ $0.02 = $7.40 รวม $24.40 ต่อเดือน
ผลคือเสมอกันแทบสนิท ต่างกัน 43 เซนต์ ถ้าใครบอกคุณว่า Workers ถูกกว่า Lambda เสมอ ให้ดูตัวเลขนี้
สถานการณ์ B: API ที่รอ I/O นาน 50 ล้าน request/เดือน, 800 ms wall-clock, 8 ms CPU
โค้ดเหมือนเดิมทุกอย่าง แค่ปลายทางช้าลง เช่น ต้องเรียก payment gateway หรือ ERP ที่ตอบช้า ซีพียูยังทำงาน 8 มิลลิวินาทีเท่าเดิม
| รายการ | AWS Lambda | Cloudflare Workers |
|---|---|---|
| ค่าสมัครรายเดือน | $0.00 | $5.00 |
| ค่า request | $9.80 | $12.00 |
| ค่าประมวลผล | $76.67 | $7.40 |
| รวมต่อเดือน | $86.47 | $24.40 |
ที่มาของ $76.67 คือ 50,000,000 × 0.8 วินาที = 40,000,000 วินาที × 0.125 GB = 5,000,000 GB-s หัก free tier 400,000 เหลือ 4,600,000 × $0.0000166667 ส่วนฝั่ง Workers ไม่ขยับเลยแม้แต่เซนต์เดียว เพราะเวลาที่รอไม่ถูกคิดเงิน ผลคือ Lambda แพงกว่า 3.5 เท่า ทั้งที่โค้ดชิ้นเดียวกัน
นี่คือรูปแบบงานที่พบบ่อยที่สุดในระบบธุรกิจไทย เช่น API gateway ที่คุยกับระบบหลังบ้านเดิม, webhook handler ที่รอ third-party, BFF ที่รวมผลจากหลาย service ถ้าระบบของคุณหน้าตาแบบนี้ ส่วนต่างจะไปโผล่ในบิลจริง
สถานการณ์ C: งานกินซีพียู 5 ล้าน request/เดือน, 120 ms wall-clock, 100 ms CPU
คราวนี้กลับด้าน โค้ดคำนวณหนัก เช่น การเข้ารหัส การแปลงข้อมูลก้อนใหญ่ หรือการทำ template rendering ที่ซับซ้อน ซีพียูทำงานเกือบตลอดเวลา
ฝั่ง Lambda: ค่า request คือ (5,000,000 − 1,000,000) / 1,000,000 × $0.20 = $0.80 ค่าประมวลผลคือ 5,000,000 × 0.12 วินาที = 600,000 วินาที × 0.125 GB = 75,000 GB-s ซึ่งยังไม่ถึง free tier 400,000 GB-s ด้วยซ้ำ จึงเป็น $0.00 รวมทั้งหมด $0.80 ต่อเดือน
ฝั่ง Workers: ค่าสมัคร $5.00 ค่า request $0.00 เพราะ 5 ล้านยังไม่เกิน 10 ล้านที่รวมมา แต่ CPU time คือ 5,000,000 × 100 ms = 500,000,000 CPU-ms หัก 30,000,000 เหลือ 470,000,000 หารล้านคูณ $0.02 = $9.40 รวม $14.40 ต่อเดือน
Lambda ถูกกว่า 18 เท่า ตัวเลขนี้ไม่ใช่ความผิดพลาด free tier 400,000 GB-second ต่อเดือนของ Lambda กว้างมากสำหรับปริมาณระดับนี้ ในขณะที่ Workers เริ่มเก็บค่า CPU ทันทีที่เกิน 30 ล้าน CPU-ms และงานที่กินซีพียู 100 มิลลิวินาทีต่อ request ก็ทะลุเพดานนั้นตั้งแต่ request ที่ 300,000
ข้อจำกัดที่ต้องรู้ก่อนตัดสินใจ
ราคาเป็นแค่ครึ่งเดียวของการตัดสินใจ อีกครึ่งคือข้อจำกัดที่ทำให้ย้ายไม่ได้เลยตั้งแต่แรก
| ข้อจำกัด | Workers Free | Workers Paid | AWS Lambda |
|---|---|---|---|
| หน่วยความจำ | 128 MB | 128 MB (เพิ่มไม่ได้) | 128 MB – 10,240 MB |
| CPU time ต่อ request | 10 ms | สูงสุด 5 นาที (ค่าเริ่มต้น 30 วินาที) | คิดเป็น wall-clock, สูงสุด 15 นาที |
| Request cap | ~100,000/วัน | ไม่มีเพดานรายวัน | ไม่มีเพดาน (มี concurrency limit) |
| Subrequest ต่อ request | 50 | 10,000 | ไม่จำกัดโดยตรง |
| Connection ขาออกพร้อมกัน | 6 | 6 | ไม่จำกัดโดยตรง |
| ขนาด bundle (gzip) | 3 MB | 10 MB | 50 MB zip / 10 GB container image |
| Filesystem | ไม่มี | ไม่มี | มี /tmp (ตั้งได้ถึง 10,240 MB) |
| Cron / Queue consumer | – | เพดาน 15 นาที | เพดาน 15 นาที |
ตัวที่ฆ่าโปรเจกต์บ่อยที่สุดคือ 128 MB มันเท่ากันทั้งแผนฟรีและแผนเสียเงิน และ Cloudflare ไม่มีปุ่มให้เพิ่ม ถ้าคุณต้องโหลดโมเดล ML ประมวลผลภาพความละเอียดสูง หรือ buffer ไฟล์ทั้งก้อนไว้ในหน่วยความจำ Workers จบตั้งแต่ต้น ในขณะที่ Lambda ปรับได้ถึง 10,240 MB
อีกตัวคือเพดาน 15 นาทีของ Cron Triggers, Queue Consumers และ Durable Object Alarms ซึ่งบังเอิญตรงกับเพดาน 15 นาทีของ Lambda พอดี ทั้งสองเจ้าจึงไม่เหมาะกับงาน batch ที่ยาวกว่านั้นเท่ากัน เราเขียนถึงกรณีเหล่านี้ละเอียดกว่าไว้ในบทความ งานแบบไหนที่ไม่ควรใช้ Cloudflare Workers
เมื่อไหร่ที่ AWS Lambda คือคำตอบที่ถูกต้อง
มีหลายกรณีที่ Lambda ชนะขาด และการทำเป็นไม่เห็นก็ไม่ช่วยใคร
งานที่ต้องการหน่วยความจำเกิน 128 MB นี่ไม่ใช่เรื่องราคา แต่เป็นเรื่องรันได้หรือรันไม่ได้ ประมวลผลวิดีโอ สร้าง PDF ขนาดใหญ่ โหลดโมเดล inference หรือ in-memory join ของข้อมูลก้อนใหญ่ ต้องอยู่บน Lambda (หรือ Fargate) เท่านั้น
งานที่กินซีพียูจริงและปริมาณไม่สูง อย่างที่เห็นในสถานการณ์ C free tier 400,000 GB-second ของ Lambda ทำให้งาน CPU-bound ระดับไม่กี่ล้าน request แทบไม่เสียเงินเลย ในขณะที่ Workers มีค่าแรกเข้า $5 และคิดค่า CPU ตั้งแต่เกิน 30 ล้าน CPU-ms
งานที่ต้องเข้าถึงทรัพยากรใน VPC ถ้าฟังก์ชันต้องคุยกับ RDS, ElastiCache หรือ service ภายในที่ไม่เปิดออกสู่อินเทอร์เน็ต Lambda เสียบเข้า VPC ได้ตรง ๆ ส่วน Workers ต้องพึ่ง Hyperdrive หรือ Cloudflare Tunnel ซึ่งเพิ่มชิ้นส่วนและความซับซ้อน
งานที่ผูกกับ event source ของ AWS S3 event, DynamoDB Streams, Kinesis, SQS, EventBridge, Step Functions ทั้งหมดนี้ต่อกับ Lambda ได้ในบรรทัดเดียว ถ้าสถาปัตยกรรมของคุณสร้างอยู่บนสิ่งเหล่านี้ การย้ายไป Workers แปลว่าต้องเขียน integration layer ใหม่ทั้งหมด
งานที่ต้องใช้ native binary หรือ runtime ที่ไม่ใช่ JavaScript Workers รันบน V8 isolate ไม่มี filesystem และไม่มี process ส่วน Lambda รองรับ container image ขนาดถึง 10 GB และรันอะไรก็ได้ที่คุณใส่เข้าไป
ข้อกำหนดเรื่อง data residency AWS เปิด Asia Pacific (Thailand) Region รหัส ap-southeast-7 แบบ generally available เมื่อวันที่ 7 มกราคม 2025 มีสาม Availability Zone ถ้าองค์กรของคุณมีเงื่อนไขว่าข้อมูลต้องอยู่ในประเทศไทย นี่เป็นเหตุผลที่หนักแน่นพอจะจบการถกเถียงเรื่องราคาได้เลย
สรุปว่าควรเลือกอะไร
วิธีตัดสินใจที่เร็วที่สุดคือหาอัตราส่วนระหว่าง CPU time กับ wall-clock time ของงานคุณ ถ้าโค้ดใช้ซีพียูจริงน้อยกว่า 20% ของเวลาที่ผ่านไปทั้งหมด แปลว่าคุณกำลังจ่ายค่าเวลารอให้ AWS อยู่ และ Workers จะประหยัดกว่าอย่างมีนัยสำคัญ แต่ถ้าอัตราส่วนใกล้ 100% หรือคุณต้องการหน่วยความจำเกิน 128 MB Lambda คือคำตอบ
อย่าเชื่อการประมาณด้วยความรู้สึก ให้เปิด CloudWatch ดู duration percentile ของฟังก์ชันจริง แล้วเทียบกับเวลาที่ซีพียูทำงานจริง ตัวเลขสองตัวนี้มักห่างกันมากกว่าที่ทีมคิดไว้เสมอ
Cipher ออกแบบและพัฒนาระบบบน Cloudflare Developer Platform ให้ธุรกิจในประเทศไทย และช่วยประเมินได้ว่าเวิร์กโหลดของคุณควรย้ายหรือไม่ควรย้าย
คำถามที่พบบ่อย
Cloudflare Workers ถูกกว่า AWS Lambda เสมอหรือไม่
ไม่เสมอไป ถ้างานของคุณกินซีพียูจริงและมีปริมาณ request ไม่สูงมาก Lambda มักถูกกว่าเพราะ free tier 400,000 GB-second ต่อเดือน ส่วน Workers จะถูกกว่าชัดเจนเมื่อโค้ดใช้เวลาส่วนใหญ่รอฐานข้อมูลหรือ API ภายนอก เพราะ Workers ไม่คิดเงินช่วงที่รอ (ราคา ณ กรกฎาคม 2026)
ทำไม Workers ถึงไม่คิดเงินตอนที่โค้ดรอ API ตอบกลับ
เพราะ Workers คิดเงินตาม CPU time ไม่ใช่ wall-clock time เอกสารของ Cloudflare ระบุว่าการรอ network request เช่น fetch() การอ่าน KV หรือ query ฐานข้อมูล ไม่ถูกนับเป็น CPU time ส่วน AWS Lambda คิดเงินตาม duration ทั้งก้อนรวมช่วงที่รอและรวม cold start ด้วย
Workers เพิ่มหน่วยความจำเกิน 128 MB ได้ไหม
ไม่ได้ ขีดจำกัด 128 MB ต่อ isolate เท่ากันทั้งแผน Free และแผน Paid และไม่มีตัวเลือกให้ปรับเพิ่ม ถ้าเวิร์กโหลดของคุณต้องการหน่วยความจำมากกว่านี้ AWS Lambda ปรับได้ตั้งแต่ 128 MB ถึง 10,240 MB ซึ่งเป็นทางเลือกที่เหมาะสมกว่า
Workers มีเพดานเวลาทำงานต่อ request เท่าไร
แผน Workers Paid ให้ CPU time สูงสุด 5 นาทีต่อ request โดยค่าเริ่มต้นตั้งไว้ที่ 30 วินาที ส่วนแผน Free จำกัดที่ 10 มิลลิวินาที สำหรับ Cron Triggers, Queue Consumers และ Durable Object Alarms เพดานอยู่ที่ 15 นาที ซึ่งเท่ากับเพดาน 15 นาทีของ AWS Lambda พอดี
ถ้าฟังก์ชันต้องคุยกับฐานข้อมูลใน VPC ควรใช้อะไร
AWS Lambda เหมาะกว่า เพราะเสียบเข้า VPC ได้โดยตรงและเข้าถึง RDS หรือ ElastiCache ที่ไม่เปิดสู่อินเทอร์เน็ตได้ทันที ส่วน Cloudflare Workers ต้องใช้ Hyperdrive หรือ Cloudflare Tunnel เป็นตัวกลาง ซึ่งเพิ่มชิ้นส่วนที่ต้องดูแลและอาจไม่คุ้มถ้าระบบหลังบ้านทั้งหมดยังอยู่บน AWS
