Cloud Run เปิด Budget Spend Caps แบบ GA เต็มวงเงินแล้วหยุด Workload
Cloud Run รองรับเพดานค่าใช้จ่ายที่หยุด service, job และ worker pool เมื่อถึงวงเงิน ผู้ดูแลต้องวางแผนผลต่อ uptime
Google Cloud แจ้งใน release notes วันที่ 12 ตุลาคม 2026 ว่า Cloud Run รองรับ Budget spend caps สำหรับหยุด workload เมื่อถึงวงเงินแบบ GA แล้ว ความสามารถนี้ช่วยทีมควบคุมค่าใช้จ่ายจาก service, job และ worker pool แต่เป็นการแลกกับความพร้อมใช้งานโดยตรง เมื่อถึงเพดาน service ที่รันอยู่จะตอบ 5xx งานใหม่จะเริ่มไม่ได้ งานที่กำลังทำอาจไม่เสร็จ และ worker pool จะหยุดประมวลผล จึงต้องกำหนดวงเงินด้วยความเข้าใจผลทางธุรกิจ ไม่ใช่ตั้งต่ำเพื่อความสบายใจอย่างเดียว
ต่างจากการแจ้งเตือนงบประมาณ
Budget alert ปกติเตือนว่าใช้เงินใกล้ถึงระดับที่กำหนด แต่ไม่ได้หยุดทรัพยากรจริง Spend cap เป็นขอบเขตที่ระบบบังคับ โดย Google ระบุว่า cap ที่ตั้งใน Cloud Billing console หรือผ่าน Budget API จะมีผลกับ Cloud Run ทุกชนิดใน project ผู้ดูแลดูความคืบหน้าของ cap ได้จากหน้า overview ของ Cloud Run และจะได้รับ alert กับ banner เมื่อมีการบังคับใช้ จุดที่ต้องตรวจคือ scope ของ project: หากหลายบริการสำคัญแชร์ project เดียว cap ที่ตั้งให้บริการทดลองอาจหยุดบริการ production ไปพร้อมกัน
เมื่อเกิน cap ระบบจะปลดบล็อกเมื่อเริ่มรอบ billing ถัดไปในวันแรกของเดือน พร้อมรีเซ็ตยอด หรือผู้ดูแลปรับ/ยกเลิก cap ก่อนรอบนั้นเพื่อกลับมาทำงาน หาก service ขององค์กรต้องพร้อมตลอดเวลา ควรมี runbook ว่าใครได้รับ alert ใครมีสิทธิ์ปรับ cap และต้องประเมินอะไรบ้างก่อนเปิดกลับ อย่าให้ระบบหยุดแล้วไม่มีคนรู้เพราะ alert ส่งไปอีเมลที่ไม่มีผู้ดูแล
ค่าใช้จ่ายที่ cap ไม่ครอบคลุม
เอกสาร Cloud Run ระบุว่า VM ของ VPC connector ถูกคิดเงินผ่าน Compute Engine จึงไม่ถูกนับใน Cloud Run spend cap หากต้องการให้ cap ครอบคลุม egress network ได้ครบกว่า Google แนะนำ Direct VPC egress รายละเอียดนี้สำคัญเพราะคำว่า “หยุดค่าใช้จ่าย” อาจทำให้คนคิดว่าค่า cloud project ทั้งหมดจะหยุดทันที แต่บริการอื่น เช่นฐานข้อมูล storage หรือ network component ยังอาจมีค่าใช้จ่ายต่อ ทีม FinOps ต้องแยก cap ของ Cloud Run ออกจาก budget ของทั้ง project
วิธีใช้ให้เหมาะกับแต่ละงาน
สำหรับ sandbox หรือ dev environment การหยุดทันทีเมื่อใช้เกิน cap อาจยอมรับได้ และช่วยป้องกัน loop ที่สร้างทราฟฟิกไม่รู้จบ แต่สำหรับ API ที่ลูกค้าใช้งาน การตอบ 5xx คือ incident จริง ควรตั้ง cap สูงกว่าค่าใช้จ่ายปกติที่คาดในเดือน พร้อม alert หลายระดับก่อนถึงเพดาน และทดสอบว่าระบบ upstream จัดการ failure อย่างไร งานแบบ job ต้องคิดกรณีงานทำไปครึ่งหนึ่งแล้วหยุด: rerun ต้องไม่สร้างข้อมูลซ้ำหรือส่งอีเมลซ้ำ
ก่อนเปิด production ให้จำลองสภาพการถูกหยุดใน environment ทดสอบ ตรวจ error ของ caller, retry policy, dead-letter queue, dashboard และขั้นตอนกลับมาทำงาน ทบทวนว่า service, job และ worker pool ไหนอยู่ project เดียวกัน หลังเปิด ให้ดูแนวโน้มรายวันและคาดการณ์ว่าจะถึง cap ก่อนสิ้นเดือนหรือไม่ การตั้งค่าที่ดีทำให้วงเงินเป็นเบรกฉุกเฉินของค่าใช้จ่าย ไม่ใช่กลไกที่ทำให้ระบบล่มทุกปลายเดือน
อ่าน release notes ต้นทางวันที่ 12 ตุลาคม 2026: Google Cloud release notes และ เอกสาร Cloud Run เรื่อง Budget spend caps