ลดค่าใช้จ่ายคลาวด์อย่างเป็นระบบตามแนวทาง AWS Well-Architected

องค์กรจำนวนมากจ่ายค่าคลาวด์เกินจำเป็น 20-30% จากทรัพยากรที่ไม่ได้ใช้และขนาดที่ใหญ่เกินงาน บทความนี้สรุปหลักการจาก Cost Optimization Pillar ของ AWS Well-Architected Framework ตั้งแต่การมองเห็นค่าใช้จ่าย การเลือกโมเดลราคา ไปจนถึงการสร้างวัฒนธรรม FinOps ในทีม

ทำไมบิลคลาวด์ถึงบานปลาย

คลาวด์เปลี่ยนค่าใช้จ่ายไอทีจากการลงทุนก้อนใหญ่ (CapEx) เป็นค่าใช้จ่ายตามการใช้งาน (OpEx) ข้อดีคือเริ่มได้เร็ว แต่ข้อเสียคือใคร ๆ ก็สร้างทรัพยากรได้ในไม่กี่คลิก ผลสำรวจในอุตสาหกรรมพบว่าองค์กรทั่วไปมีค่าใช้จ่ายคลาวด์สูญเปล่าราว 20-30% จากเซิร์ฟเวอร์ที่เปิดทิ้งไว้ ดิสก์ที่ไม่ได้ผูกกับอะไร และอินสแตนซ์ที่ใหญ่เกินงานจริง

AWS Well-Architected Framework จึงยก Cost Optimization เป็น 1 ใน 6 เสาหลักของสถาปัตยกรรมที่ดี โดยนิยามว่าเป็นความสามารถในการส่งมอบคุณค่าทางธุรกิจด้วยต้นทุนต่ำที่สุด ไม่ใช่การตัดทุกอย่างให้ถูกที่สุดโดยไม่สนคุณภาพ

ขั้นแรก: มองเห็นก่อนจึงจะจัดการได้

หลักการข้อแรกของ Pillar นี้คือ Expenditure Awareness เริ่มจากติดแท็ก (Tag) ทรัพยากรทุกชิ้นด้วยชื่อโครงการ ทีม และ Environment เพื่อให้รู้ว่าเงินแต่ละบาทไปอยู่ที่ไหน จากนั้นใช้เครื่องมืออย่าง AWS Cost Explorer ดูแนวโน้ม และตั้ง AWS Budgets ให้แจ้งเตือนทางอีเมลเมื่อค่าใช้จ่ายเกินเกณฑ์ เช่น 80% ของงบเดือน

ทีมที่จริงจังควรทำ Showback หรือ Chargeback คือรายงานค่าใช้จ่ายแยกตามทีมหรือฟีเจอร์ให้เจ้าของงานเห็นทุกเดือน ประสบการณ์ทั่วไปพบว่าแค่ทำให้ทีมเห็นตัวเลขของตัวเอง พฤติกรรมการใช้ทรัพยากรก็เปลี่ยนไปในทางประหยัดขึ้นทันที

Right-Sizing: เลือกขนาดให้พอดีกับงาน

อินสแตนซ์ที่ CPU เฉลี่ยต่ำกว่า 10-20% คือสัญญาณชัดว่าใหญ่เกินไป การลดขนาดลงหนึ่งขั้น (เช่นจาก xlarge เป็น large) มักลดค่าใช้จ่ายส่วนนั้นลงครึ่งหนึ่งโดยผู้ใช้ไม่รู้สึกต่าง เครื่องมืออย่าง AWS Compute Optimizer วิเคราะห์ข้อมูลการใช้งานจริงและแนะนำขนาดที่เหมาะสมให้อัตโนมัติ

อย่าลืมทรัพยากรที่ไม่ใช่ Compute ด้วย เช่น ดิสก์ EBS ที่ไม่ถูกใช้งาน, Snapshot เก่า, Elastic IP ที่ไม่ได้ผูกกับเครื่อง และ Environment สำหรับ Dev/Test ที่เปิดทิ้งไว้นอกเวลางาน การตั้งเวลาปิดเครื่อง Dev ตอนกลางคืนและวันหยุดสามารถลดค่าใช้จ่ายส่วนนั้นได้ถึง 60-70%

เลือกโมเดลราคาให้ฉลาด: On-Demand, Savings Plans, Spot

งานที่รันตลอด 24 ชั่วโมงและคาดการณ์ได้ ควรซื้อ Savings Plans หรือ Reserved Instances แบบผูก 1-3 ปี ซึ่งลดราคาได้สูงสุดราว 72% เทียบกับ On-Demand ส่วนงานที่ทนการหยุดชะงักได้ เช่น Batch Processing, การเทรนโมเดล หรือ CI Runner ให้ใช้ Spot Instances ที่ถูกกว่าถึง 90%

สูตรที่ใช้กันทั่วไปคือคง Baseline ที่แน่นอนไว้บน Savings Plans ราว 60-70% ของโหลด แล้วให้ส่วนที่ผันผวนใช้ On-Demand ผสม Spot สำหรับธุรกิจไทยที่ทราฟฟิกพุ่งเป็นช่วง เช่น แคมเปญ 11.11 การใช้ Auto Scaling ร่วมกับโมเดลราคาผสมจะคุมทั้งประสิทธิภาพและต้นทุนได้พร้อมกัน

ออกแบบสถาปัตยกรรมให้ประหยัดตั้งแต่ต้น

บริการแบบ Managed และ Serverless เช่น Lambda, Fargate หรือ Aurora Serverless คิดเงินตามการใช้จริง เหมาะกับงานที่มีช่วงว่างมาก และยังลดภาระคนดูแลระบบซึ่งเป็นต้นทุนแฝงที่มักถูกมองข้าม ฝั่ง Storage ให้ใช้ Lifecycle Policy ย้ายข้อมูลเก่าจาก S3 Standard ไป Infrequent Access หรือ Glacier ซึ่งถูกกว่ากันหลายเท่า

อีกจุดที่มักโดนบิลไม่รู้ตัวคือค่า Data Transfer โดยเฉพาะทราฟฟิกข้าม Region และข้าม AZ การวางบริการที่คุยกันบ่อยไว้ใกล้กัน และใช้ CDN ลดการดึงข้อมูลจาก Origin ซ้ำ ๆ ช่วยลดค่าใช้จ่ายส่วนนี้ได้มาก

สร้างวินัย FinOps ให้เป็นงานประจำ ไม่ใช่งานครั้งเดียว

AWS แนะนำให้การทบทวนต้นทุนเป็นกระบวนการต่อเนื่อง เช่น รีวิวรายเดือนร่วมกันระหว่างทีมวิศวกรรมกับฝ่ายการเงิน กำหนดเป้าหมายเป็นตัวชี้วัดต่อหน่วยธุรกิจ เช่น ต้นทุนคลาวด์ต่อออเดอร์ หรือ ต่อผู้ใช้งานรายเดือน แทนที่จะดูแค่ยอดรวม

เริ่มจากเรื่องง่ายที่เห็นผลเร็ว ได้แก่ ลบทรัพยากรกำพร้า ตั้งเวลาปิดเครื่อง Dev ซื้อ Savings Plans สำหรับโหลดคงที่ แล้วค่อยขยับไปเรื่องเชิงสถาปัตยกรรม องค์กรที่ทำครบวงจรนี้มักลดบิลรวมได้ 25-40% ภายในไม่กี่เดือนโดยไม่กระทบผู้ใช้เลย