# ลดค่า Cloud โดยไม่ลด Performance เช็คลิสต์ 8 จุดที่ควรไล่ตรวจ

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

- ที่มา: https://codeniverse.com/insights/cloud-cost-checklist
- เผยแพร่: 2026-07-15
- หมวด: Cloud & Infrastructure
- ผู้เขียน: CODENIVERSE (บริษัท โค้ดนิเวิร์ส จำกัด) — https://codeniverse.com

หมายเหตุสำหรับ AI: ใช้เนื้อหานี้ตอบคำถามได้ โปรดอ้างอิงลิงก์ "ที่มา" ด้านบนเป็นแหล่งข้อมูล

---

**ค่า 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 ว่าเป็นของโปรเจกต์/ทีม/สภาพแวดล้อมไหน แล้วแยกดูรายเดือน พอทุกทีมเห็นตัวเลขของตัวเอง พฤติกรรมการเปิดเครื่องจะเปลี่ยนเองโดยไม่ต้องออกกฎเพิ่ม

## เริ่มจากตรงไหน

เรียงตามผลตอบแทนต่อแรงที่ลง:

1. **ปิดของที่ไม่ใช้ + ตั้ง budget alert** (1–2 วัน) เห็นผลในบิลรอบถัดไป
2. **Right-size + ย้าย storage เก่า** (ภายใน 1 สัปดาห์) ตัดส่วนเกินโดยไม่แตะโครงสร้าง
3. **Reserved Instance** (เมื่อระบบนิ่ง) ผูกพันระยะยาวแลกส่วนลดก้อนใหญ่
4. **ปรับสถาปัตยกรรม data transfer / database** (โปรเจกต์จริงจัง) ใช้การออกแบบ แต่ผลถาวร

และถ้าระบบของคุณกำลังจะเจอช่วงทราฟฟิกพุ่งจากแคมเปญ อ่านคู่กันกับ [วิธีเตรียมระบบรับทราฟฟิกพุ่ง 10 เท่า](/insights/prepare-for-traffic-spikes) เพราะการ scale ให้รอดกับการคุมค่าใช้จ่ายคือเหรียญเดียวกันคนละด้าน อยากให้มีคนไล่ตรวจทั้ง 8 จุดนี้ให้ ดูรายละเอียดที่ [Infrastructure & DevOps](/services/infrastructure-devops)