ค่า cloud ที่บานปลายมักไม่ได้มาจากทราฟฟิกที่โต แต่มาจากของที่เปิดทิ้งไว้ ขนาดที่เผื่อเกินจริง และสถาปัตยกรรมที่ไม่เคยถูกรีวิว บทความนี้คือเช็คลิสต์ 8 จุดสำหรับไล่ตรวจอย่างเป็นระบบ แต่ละจุดบอกชัดว่าตรวจอะไร ลงมือยังไง และเงินหายไปทางไหน
1. เครื่องที่เปิดทิ้งไว้ (Idle Resources)
เซิร์ฟเวอร์ dev/test ที่รันทั้งคืนทั้งวันหยุด, IP ที่จองแล้วไม่ได้ผูกกับเครื่องไหน, disk ของเครื่องที่ลบไปแล้ว ของพวกนี้เก็บเงินเงียบๆ ทุกชั่วโมง
ตั้งสคริปต์ปิดเครื่อง dev/test นอกเวลางานอัตโนมัติ เครื่องที่ใช้จริงแค่จันทร์-ศุกร์ 9 โมงถึง 6 โมงเย็น คิดเป็น ~27% ของชั่วโมงทั้งสัปดาห์ ที่เหลือคือจ่ายให้เครื่องนั่งเฉยๆ
2. ขนาดเครื่องที่เผื่อเกินจริง (Over-provisioning)
เครื่องที่ CPU เฉลี่ยใช้ 8% แปลว่าคุณจ่ายเผื่อไว้ 12 เท่า ความ "เผื่อเหนียว" ตอนตั้งระบบวันแรกกลายเป็นค่าเช่าถาวรที่ไม่มีใครกลับมาดู
ดู metric ย้อนหลัง 30 วัน แล้ว right-size ลงทีละขั้น เช่น 8 vCPU เหลือ 4 เฝ้าดู 1 สัปดาห์ ถ้านิ่งค่อยลดต่อ ระบบส่วนใหญ่ลดขนาดได้อย่างน้อยครึ่งหนึ่งโดย response time ไม่เปลี่ยน
3. จ่ายราคาเต็มทั้งที่ใช้ระยะยาว
Workload ที่รันตลอด 24/7 อย่าง production database ไม่มีเหตุผลต้องจ่ายแบบ on-demand ราคาเต็ม
ทำ Reserved Instance หรือ Savings Plan สัญญา 1 หรือ 3 ปี ราคาถูกกว่า on-demand 40–60% ตามราคาที่ผู้ให้บริการประกาศเอง เงื่อนไขเดียวคือทำเฉพาะระบบหลักที่สถาปัตยกรรมนิ่งแล้วและรู้แน่ว่าใช้ต่อ
"บิล cloud ที่ดีไม่ใช่บิลที่ถูกที่สุด แต่คือบิลที่ทุกบาทตอบได้ว่าจ่ายไปเพื่ออะไร"
4. ข้อมูลเก่าใน storage ราคาแพง
Log และ backup อายุเกิน 90 วันแทบไม่มีใครเรียกใช้ แต่หลายระบบยังเก็บไว้ใน storage ชั้น hot ที่แพงที่สุด
ย้ายไป archive tier (เช่นจาก S3 มาตรฐานไป Glacier) ถูกกว่า 5–10 เท่า ตั้ง lifecycle policy ครั้งเดียวให้ระบบย้ายและลบเองตามอายุไฟล์ ไม่ต้องมีใครจำ
5. ค่า data transfer ข้าม zone ที่มองไม่เห็น
Web server อยู่ zone หนึ่ง database อยู่อีก zone ทุก query จ่ายค่าส่งข้อมูลตลอดเวลา จุดนี้เจ็บเพราะมันโผล่ในบิลคนละบรรทัดกับค่าเครื่อง เลยไม่มีใครเชื่อมโยง
จัดระบบที่คุยกันบ่อยให้อยู่ zone เดียวกัน และเปิดบิลดูบรรทัด data transfer ทุกเดือน ถ้ามันโตเร็วกว่าทราฟฟิกผู้ใช้ แปลว่ามีอะไรวางผิดที่
6. Database ที่แก้ทุกปัญหาด้วยการอัปเกรด
พอ database ช้า ทางลัดที่ทุกคนเลือกคืออัปสเปกเครื่อง ซึ่งราคากระโดดเป็นเท่าตัวทุกขั้น ทั้งที่ระบบส่วนใหญ่อ่านข้อมูลมากกว่าเขียนหลายเท่า
แยก read replica รับโหลดฝั่งอ่าน หรือ cache ผล query ที่ถูกถามซ้ำบ่อย สองทางนี้มักถูกกว่าและตรงจุดกว่าการขยายเครื่องหลักไปเรื่อยๆ
7. ไม่มี budget alert
ปล่อยให้ทีมสร้าง resource ได้อิสระโดยไม่มีเพดาน ผลคือรู้ตัวอีกทีตอนบิลมาถึง
ตั้งแจ้งเตือนที่ 50% และ 80% ของงบรายเดือน ส่งเข้าช่องแชทที่ทีมอ่านจริง ใช้เวลาตั้งไม่ถึงชั่วโมง แต่เปลี่ยน "บิลช็อกสิ้นเดือน" เป็น "เห็นล่วงหน้าสองสัปดาห์"
8. ไม่มีเจ้าของค่าใช้จ่าย
บิลก้อนเดียวรวมทุกอย่าง ตอบไม่ได้ว่าโปรเจกต์ไหนเป็นตัวกิน
บังคับติด tag ทุก resource ว่าเป็นของโปรเจกต์/ทีม/สภาพแวดล้อมไหน แล้วแยกดูรายเดือน พอทุกทีมเห็นตัวเลขของตัวเอง พฤติกรรมการเปิดเครื่องจะเปลี่ยนเองโดยไม่ต้องออกกฎเพิ่ม
เริ่มจากตรงไหน
เรียงตามผลตอบแทนต่อแรงที่ลง:
- ปิดของที่ไม่ใช้ + ตั้ง budget alert (1–2 วัน) เห็นผลในบิลรอบถัดไป
- Right-size + ย้าย storage เก่า (ภายใน 1 สัปดาห์) ตัดส่วนเกินโดยไม่แตะโครงสร้าง
- Reserved Instance (เมื่อระบบนิ่ง) ผูกพันระยะยาวแลกส่วนลดก้อนใหญ่
- ปรับสถาปัตยกรรม data transfer / database (โปรเจกต์จริงจัง) ใช้การออกแบบ แต่ผลถาวร
และถ้าระบบของคุณกำลังจะเจอช่วงทราฟฟิกพุ่งจากแคมเปญ อ่านคู่กันกับ วิธีเตรียมระบบรับทราฟฟิกพุ่ง 10 เท่า เพราะการ scale ให้รอดกับการคุมค่าใช้จ่ายคือเหรียญเดียวกันคนละด้าน อยากให้มีคนไล่ตรวจทั้ง 8 จุดนี้ให้ ดูรายละเอียดที่ Infrastructure & DevOps
