AWS Lambda หรือ Cloudflare Workers: งานรอ I/O คิดเงินคนละนาฬิกา

API ที่รอฐานข้อมูลนานแต่ใช้ CPU น้อยมักได้เปรียบด้านค่ารันบน Cloudflare Workers เพราะเวลารอเครือข่ายไม่เพิ่มเวลา CPU ที่นำไปคิดราคา ส่วน AWS Lambda Functions คิดระยะเวลาที่ฟังก์ชันทำงานร่วมกับหน่วยความจำที่จัดสรร งานคำนวณหนักหรือ API ขนาดเล็กจึงอาจให้ผลด้านต้นทุนกลับกันได้

ถ้าผู้ใช้เรียก API จากไทยและหลายภูมิภาค ค่ารันอย่างเดียวก็ยังตัดสินเรื่องความเร็วไม่ได้ ต้องดูว่าคำขอใช้ CPU เท่าไร รอ I/O นานเท่าไร และฐานข้อมูลอยู่ที่ใด ฟังก์ชันที่อยู่ใกล้ผู้ใช้อาจต้องเดินทางไกลเพื่ออ่านข้อมูล ขณะที่ฟังก์ชันใกล้ฐานข้อมูลอาจเพิ่มระยะทางช่วงแรกของคำขอ

ราคานับเวลา CPU หรือเวลาที่ฟังก์ชันยังทำงาน

ตารางราคา Lambda Functions ของ AWS คิดค่าคำขอและระยะเวลารันในหน่วย GB-second โดยให้โควตาฟรีรายเดือน 1 ล้านคำขอและ 400,000 GB-second ตัวอย่างราคา x86 ในภูมิภาค US East (N. Virginia) คิด 0.20 ดอลลาร์ต่อคำขออีก 1 ล้านครั้ง และ 0.0000166667 ดอลลาร์ต่อ GB-second เมื่อใช้เกินโควตา

หน่วย GB-second ทำให้เวลารันเท่ากันมีราคาไม่เท่ากันเมื่อจัดสรรหน่วยความจำต่างกัน หากฟังก์ชันยังรอคำตอบฐานข้อมูลอยู่ภายในระยะเวลารัน ช่วงรอนั้นก็เพิ่ม GB-second แม้โค้ดไม่ได้ใช้ CPU ตลอดเวลา ในทางกลับกัน การเพิ่มหน่วยความจำอาจทำให้ได้ทรัพยากรประมวลผลมากขึ้น จึงต้องดูทั้งระยะเวลาที่เปลี่ยนไปและหน่วยความจำที่เพิ่มขึ้น

ตารางราคา Workers ของ Cloudflare ซึ่งปรับปรุงเมื่อ 2 ตุลาคม 2026 ระบุว่าแผนจ่ายเงินมีค่าขั้นต่ำ 5 ดอลลาร์ต่อเดือน และแบบคิดราคา Standard รวม 10 ล้านคำขอกับ 30 ล้าน CPU-milliseconds ต่อเดือน ส่วนที่เกินคิด 0.30 ดอลลาร์ต่อคำขอ 1 ล้านครั้ง และ 0.02 ดอลลาร์ต่อ CPU-milliseconds 1 ล้านหน่วย โดยไม่คิดค่าระยะเวลารันทั้งหมดหรือค่า egress เพิ่มสำหรับ Workers

ความต่างอยู่ที่คำว่า “เวลา” ของแต่ละบิล ใน Workers การรอผลจากเครือข่ายไม่สะสมเวลา CPU แบบเดียวกับช่วงที่โค้ดกำลังประมวลผล แต่คำขอที่ส่งเข้ามายังคงนับเป็นคำขอ แผนจ่ายเงินยังมีค่าขั้นต่ำแม้การใช้ CPU ต่ำมาก จึงไม่ควรดูเฉพาะราคาต่อหน่วยที่เกินโควตา

แบบจำลองต่อไปนี้เป็น ตัวอย่างสมมติ ไม่ใช่ผลทดสอบ กำหนดให้แต่ละกรณีมี 10 ล้านคำขอต่อเดือน ใช้ราคา Lambda x86 ของภูมิภาคดังกล่าว และสมมติว่าโควตารายเดือนของทั้งสองระบบยังไม่ถูกงานอื่นใช้ ตัวเลขรวมเฉพาะค่าคำขอและค่าประมวลผลของฟังก์ชัน ไม่รวมภาษี ฐานข้อมูล บริการรับคำขอ และค่าเครือข่ายที่สถาปัตยกรรมจริงอาจต้องจ่าย

งาน CPU หนัก: เวลาคำนวณเป็นตัวขับราคา

สมมติฟังก์ชันประมวลผลข้อมูล 10 ล้านครั้งต่อเดือน แต่ละครั้งใช้ CPU 500 มิลลิวินาที และแทบไม่รอ I/O หาก Lambda จัดสรรหน่วยความจำ 1 GB และระยะเวลารันเฉลี่ยเท่ากับ 0.5 วินาที ปริมาณงานจะเป็น 5 ล้าน GB-second เมื่อตัดโควตาฟรี ค่าประมวลผลอยู่ราว 76.67 ดอลลาร์ บวกค่าคำขอ 1.80 ดอลลาร์ รวมประมาณ 78.47 ดอลลาร์ต่อเดือน

หาก Workers ใช้ CPU เฉลี่ย 500 มิลลิวินาทีต่อคำขอเช่นกัน งานทั้งหมดจะใช้ 5,000 ล้าน CPU-milliseconds เมื่อหักส่วนที่รวมในแผน ค่าประมวลผลที่เพิ่มขึ้นเท่ากับ 99.40 ดอลลาร์ รวมค่าขั้นต่ำแล้วเป็น 104.40 ดอลลาร์ต่อเดือน ในเงื่อนไขสมมตินี้ Lambda จึงมีค่าฟังก์ชันต่ำกว่า แต่ผลดังกล่าวขึ้นอยู่กับเวลาที่กำหนดให้แต่ละระบบ

การตั้ง Lambda ที่ 1 GB ไม่ได้หมายความว่ากำลังประมวลผลจะเท่ากับ Workers และโค้ดเดียวกันก็ไม่จำเป็นต้องใช้ CPU เท่ากันในสอง runtime หากงานมีการแปลงข้อมูล ถอดรหัส หรือคำนวณอย่างต่อเนื่อง ความต่างของเวลา CPU ที่วัดได้จริงอาจเปลี่ยนลำดับต้นทุน จึงต้องแทนเวลาของแต่ละระบบลงในสูตรของระบบนั้น

ต้นทุนยังไม่ใช่ข้อจำกัดเดียวของงานคำนวณ ข้อจำกัด Workers ของ Cloudflare ระบุหน่วยความจำ 128 MB ต่อ isolate และเพดาน CPU สำหรับคำขอ HTTP บนแผนจ่ายเงินที่ตั้งต้น 30 วินาที โดยปรับได้สูงสุด 5 นาที งานที่ต้องถือข้อมูลก้อนใหญ่ในหน่วยความจำหรือคำนวณนานต่อคำขอจึงต้องผ่านข้อจำกัดเหล่านี้ก่อนนำราคาไปเทียบ

หน่วยความจำ 128 MB เป็นขีดจำกัดต่อ isolate ไม่ใช่โควตาที่เพิ่มตามจำนวนคำขอที่เข้ามาพร้อมกัน การออกแบบให้สตรีมข้อมูลแทนการเก็บทั้งก้อนอาจช่วยงานบางประเภทได้ แต่เป็นการเปลี่ยนวิธีเขียนโปรแกรม ไม่ใช่การเพิ่มหน่วยความจำของ Worker ส่วน Lambda ให้เลือกหน่วยความจำสำหรับฟังก์ชันได้กว้างกว่า โดยราคาจะผูกกับค่าที่เลือก

งานรอฐานข้อมูล: ระยะเวลารวมอาจห่างจากเวลา CPU มาก

สมมติ API เรียกฐานข้อมูลทุกครั้ง ใช้ CPU เพียง 20 มิลลิวินาที แต่รอผลจนระยะเวลารวมเป็น 0.5 วินาที หาก Lambda จัดสรร 512 MB การรัน 10 ล้านครั้งจะใช้ 2.5 ล้าน GB-second หลังหักโควตาฟรี ค่าประมวลผลประมาณ 35 ดอลลาร์ บวกค่าคำขอ 1.80 ดอลลาร์ รวม 36.80 ดอลลาร์ต่อเดือน

Workers ในเงื่อนไขเดียวกันใช้ CPU รวม 200 ล้านมิลลิวินาที เมื่อหัก 30 ล้านมิลลิวินาทีที่รวมในแผน จะมีค่า CPU เพิ่ม 3.40 ดอลลาร์ รวมค่าขั้นต่ำเป็น 8.40 ดอลลาร์ต่อเดือน ส่วนต่างของตัวอย่างนี้มาจากเวลารอที่ยาวกว่าเวลาคำนวณมาก ไม่ได้หมายความว่าฐานข้อมูลหรือการส่งข้อมูลของทั้งสองสถาปัตยกรรมมีราคาเท่ากัน

แบบจำลองยังบอกได้ว่าตัวแปรใดทำให้บิลเปลี่ยน ภายใต้ปริมาณคำขอและหน่วยความจำที่สมมติไว้ หากเวลา Lambda เพิ่มอีก 0.1 วินาทีต่อคำขอ จะเพิ่มการใช้ 500,000 GB-second หรือราว 8.33 ดอลลาร์เมื่อส่วนนี้อยู่เหนือโควตาฟรี หาก Workers ใช้ CPU เพิ่ม 10 มิลลิวินาทีต่อคำขอ จะเพิ่ม 100 ล้าน CPU-milliseconds หรือ 2 ดอลลาร์เมื่ออยู่เหนือส่วนที่รวมในแผน

การลดเวลารอฐานข้อมูลจึงช่วยต้นทุน Lambda ตามระยะเวลาที่ลดได้ และช่วยเวลาตอบสนองของผู้ใช้ทั้งสองระบบ ส่วนการลดงานคำนวณช่วย Workers ตาม CPU ที่ลดลงโดยตรง ความสัมพันธ์นี้ทำให้ API ที่รอฐานข้อมูล กับ API ที่แปลงข้อมูลหนัก แม้มีจำนวนคำขอเท่ากัน ก็อาจเหมาะกับคนละทางเลือก

ต้องนับจำนวนครั้งที่ API ติดต่อฐานข้อมูลด้วย หากคำสั่งถัดไปเริ่มได้หลังคำสั่งก่อนหน้าตอบกลับ ระยะทางระหว่างฟังก์ชันกับฐานข้อมูลจะสะสมหลายรอบ การย้ายฟังก์ชันเข้าใกล้ผู้ใช้อาจลดเวลาช่วงรับคำขอ แต่เพิ่มเวลาช่วงอ่านข้อมูลจนผลรวมช้าลงได้

API หลายภูมิภาค: จุดรันใกล้ผู้ใช้อาจไกลจากข้อมูล

กรณีที่สามเป็น API สมมติซึ่งตรวจคำขอแล้วส่งคำตอบสั้น ๆ โดยไม่อ่านฐานข้อมูล ให้ Workers ใช้ CPU 10 มิลลิวินาทีต่อคำขอ และ Lambda ที่จัดสรร 512 MB มีระยะเวลารัน 50 มิลลิวินาที สำหรับ 10 ล้านคำขอต่อเดือน ค่า Lambda อยู่ที่ 1.80 ดอลลาร์ เพราะปริมาณ GB-second ยังอยู่ในโควตาฟรี ส่วน Workers อยู่ที่ 6.40 ดอลลาร์ เมื่อรวมค่าขั้นต่ำและ CPU ส่วนเกิน

ตัวเลขนี้แสดงผลของค่าขั้นต่ำและโควตาฟรีเมื่องานต่อคำขอสั้น ไม่ได้บอกว่าคำตอบจาก Lambda จะถึงผู้ใช้ไทยเร็วกว่า Workers หากฟังก์ชันต้องทำงานเพิ่ม หรือจำนวนคำขอเปลี่ยน จุดที่เริ่มจ่ายค่าประมวลผลก็เปลี่ยนด้วย การเทียบความเร็วต้องนับการเดินทางของคำขอตั้งแต่ผู้ใช้จนได้รับคำตอบ

เอกสาร Placement ของ Cloudflare ระบุว่า Workers โดยปกติรันใกล้จุดรับคำขอ แต่ Smart Placement อาจส่งงานไปยังตำแหน่งที่ให้ระยะเวลารวมดีกว่าเมื่อมีบริการปลายทาง ส่วน Placement Hints ใช้กำหนดตำแหน่งใกล้ภูมิภาคคลาวด์หรือโฮสต์ที่ทราบ Workers ยังรันบนเครือข่าย Cloudflare ไม่ได้ย้ายเข้าไปอยู่ภายในภูมิภาคของผู้ให้บริการคลาวด์นั้น

สำหรับ API ที่ต้องอ่านฐานข้อมูลหลายรอบ การวาง Worker ใกล้ฐานข้อมูลอาจลดเวลารอสะสม แม้ต้องส่งคำขอจากผู้ใช้ไปไกลขึ้นก่อนเริ่มประมวลผล แต่ถ้า API ตอบได้โดยไม่แตะข้อมูลส่วนกลาง ตำแหน่งใกล้ผู้ใช้มักมีเหตุผลกว่า ผลที่ดีที่สุดจึงขึ้นกับจำนวนรอบการติดต่อระบบปลายทาง ไม่ใช่ระยะทางจากผู้ใช้ถึงฟังก์ชันเพียงช่วงเดียว

Lambda Functions รันในภูมิภาคที่เลือก หากฐานข้อมูลและบริการ AWS ที่เรียกอยู่ในภูมิภาคเดียวกัน เส้นทางไปหาข้อมูลอาจสั้นลงสำหรับฟังก์ชันนั้น ขณะเดียวกันผู้ใช้จากภูมิภาคอื่นยังต้องส่งคำขอมาถึงภูมิภาคดังกล่าว การวาง Lambda หลายภูมิภาคเพิ่มทางเลือกเรื่องตำแหน่ง แต่ยังต้องจัดการการส่งคำขอและตำแหน่งของข้อมูลที่แต่ละฟังก์ชันอ่าน

เรื่อง egress ต้องแยกจากค่าฟังก์ชันด้วย ราคา Workers Paid ไม่คิดค่า egress เพิ่มสำหรับตัว Worker ส่วนข้อมูลที่ออกจากภูมิภาคของ Lambda อาจมีค่าโอนข้อมูลตามเงื่อนไข AWS และการอ่านฐานข้อมูลหรือพื้นที่เก็บข้อมูลก็มีค่าบริการของตนเอง หาก API ส่งข้อมูลจำนวนมาก ส่วนนี้อาจมีน้ำหนักกว่าส่วนต่างค่าประมวลผลในตัวอย่างสมมติ

ผลวัดฟังก์ชันขั้นต่ำไม่ใช่เวลา cold start ของ API จริง

งานวิจัย EuroSys 2026 วัดระยะเวลาที่ผู้ให้บริการรายงานสำหรับฟังก์ชันขั้นต่ำซึ่งคืนสตริงว่างและรหัสสถานะ โดยพบค่าเฉลี่ยราว 1.17 มิลลิวินาทีสำหรับ AWS Lambda แบบ long polling ขณะที่ค่าของ Cloudflare Workers แบบ code/binary execution ต่ำกว่าความละเอียด 0.01 มิลลิวินาทีของค่าที่ Cloudflare รายงาน

สิ่งที่วัดคือระยะเวลาของการให้บริการฟังก์ชันขั้นต่ำภายใต้วิธีรายงานของแต่ละแพลตฟอร์ม ตัวเลขนี้ไม่รวมเส้นทางทั้งหมดจากผู้ใช้ไทยไปยัง API และฐานข้อมูล อีกทั้งไม่ใช่ค่า cold start ทั้งหมดของแอปพลิเคชันที่ต้องโหลดไลบรารีหรือสร้างการเชื่อมต่อ จึงใช้ประกาศผู้ชนะด้าน latency ของ API จริงไม่ได้

สำหรับ API จริง เวลาตอบสนองมีหลายช่วงที่ส่งผลต่างกัน ได้แก่ การเดินทางผ่านเครือข่าย การเริ่มสภาพแวดล้อมเมื่อจำเป็น การทำงานของโค้ด และการรอระบบปลายทาง ฟังก์ชันที่มีงานคำนวณน้อยอาจได้รับผลจากช่วงเริ่มรันเด่นชัดกว่า ส่วนคำขอที่อ่านฐานข้อมูลหลายรอบอาจถูกครอบงำด้วยระยะทางไปหาข้อมูล

หากต้องตัดสินด้านความเร็ว ควรใช้โค้ดและข้อมูลที่เป็นตัวแทนงานจริง แล้วแยกคำขอที่เริ่มสภาพแวดล้อมใหม่จากคำขอที่ใช้สภาพแวดล้อมเดิม วัดจากตำแหน่งผู้ใช้ในไทยและภูมิภาคอื่น พร้อมบันทึกเวลา CPU ระยะเวลารวม และตำแหน่งฐานข้อมูล วิธีนี้ทำให้เห็นว่าความต่างเกิดในฟังก์ชันหรือระหว่างฟังก์ชันกับข้อมูล

เลือกให้เข้ากับระบบที่ต้องเชื่อมต่อ

ถ้างานใช้บริการ AWS และฐานข้อมูลในภูมิภาคเดียวกันอยู่แล้ว Lambda อาจทำให้เส้นทางการเชื่อมต่อและการจัดการสิทธิ์ตรงกับสถาปัตยกรรมเดิมมากกว่า การย้ายเฉพาะฟังก์ชันไป Workers แต่คงฐานข้อมูลไว้ที่เดิมอาจเปลี่ยนทั้งระยะทางเครือข่ายและวิธีเข้าถึงบริการ ต้องนำผลของการเปลี่ยนเหล่านั้นมารวมกับส่วนต่างค่ารัน

Workers เหมาะกับงานที่ประมวลผลสั้นและรอ I/O มากเมื่อโค้ดรันภายใต้ข้อจำกัดทรัพยากรได้ งานรับคำขอ ตรวจข้อมูลเบื้องต้น หรือเรียก API ปลายทางเป็นตัวอย่างที่ควรพิจารณา ตำแหน่งรันยังควรสัมพันธ์กับจุดที่ข้อมูลอยู่ โดยเฉพาะคำขอที่ต้องติดต่อฐานข้อมูลหลายครั้ง

สำหรับงานคำนวณหนัก ให้เริ่มจากหน่วยความจำที่ต้องใช้และเวลา CPU ที่เกิดขึ้นจริงในแต่ละ runtime สำหรับงานฐานข้อมูล ให้แยกเวลา CPU ออกจากเวลารอและนับรอบการติดต่อข้อมูล ส่วน API ที่มีผู้ใช้หลายภูมิภาค ให้คิดค่าฟังก์ชันพร้อมเส้นทางเครือข่ายและค่าโอนข้อมูล จึงจะเห็นว่าทางเลือกที่จ่ายค่ารันต่ำกว่านั้นตอบผู้ใช้ได้เร็วพอหรือไม่

อ่านเพิ่มเติม:

• Cloudflare Workers หรือ Vercel Functions: cold start ไม่ใช่ต้นทุนเดียว
• Postman หรือ Insomnia: ทีมใหญ่แลก RAM กับระบบกำกับ API
• Cloudflare R2 หรือ Amazon S3: egress ฟรีแลกกับอัปโหลดที่ช้ากว่า