วิธีใช้ Azure Pricing Calculator (ทีละขั้นตอน)

ค่าใช้จ่ายบนคลาวด์มักถูกประเมินต่ำกว่าความเป็นจริงจนกว่าจะได้รับใบแจ้งหนี้ฉบับแรก โชคดีที่มี Azure Pricing Calculator ซึ่งเป็นเครื่องมือฟรีของ Microsoft ที่ไม่ต้องเข้าสู่ระบบ สำหรับประเมินค่าใช้จ่ายของบริการ Azure ก่อนจะปรับใช้สิ่งใดก็ตาม

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

บทความนี้จะสร้างการประเมินจากศูนย์ เดินผ่านตัวอย่าง Virtual Machine แบบละเอียด และอธิบายข้อผิดพลาดที่มักทำให้การประเมินที่ระมัดระวังพังลงอย่างเงียบๆ

คำตอบแบบรวดเร็ว: วิธีใช้ Azure Pricing Calculator

เปิด Azure Pricing Calculator แล้วทำตาม ขั้นตอนด้านล่าง:

1. ค้นหาในตัวเลือกผลิตภัณฑ์สำหรับบริการ Azure ที่ต้องการคำนวณราคา เช่น Virtual Machines
2. เลือกเพื่อเพิ่มลงในประมาณการด้วยค่าตั้งต้น
3. กำหนดภูมิภาค ระดับ (tier) ขนาด และตัวเลือกเฉพาะบริการอื่นๆ ที่จะใช้
4. ใส่การใช้งานที่คาดไว้ เช่น ชั่วโมงต่อเดือน พื้นที่จัดเก็บ (GB) หรือจำนวนคำขอต่อวินาที ตามหน่วยที่บริการนั้นคิดเงิน
5. เลือกตัวเลือกการกำหนดราคา เช่น Pay-As-You-Go, Reserved Instance หรือ Azure Savings Plan
6. ตรวจสอบค่าใช้จ่ายรายเดือน และถ้ามี ให้ดูค่าใช้จ่ายชำระล่วงหน้าของผลิตภัณฑ์นั้นด้วย
7. ทำซ้ำกับบริการอื่นทุกบริการในสถาปัตยกรรม เช่น ฐานข้อมูล บัญชีเก็บข้อมูล และตัวกระจายโหลด (load balancer)
8. เพิ่มแผนการสนับสนุนบริเวณด้านล่างของหน้า

ยอดรวมจะอัปเดตแบบเรียลไทม์เมื่อเปลี่ยนค่าช่องใดๆ และนี่คือจุดที่ประมาณการส่วนใหญ่ล้มเหลวในสภาพใช้งานจริง: ทีมมักคำนวณราคาเฉพาะบริการที่โฟกัสและลืมบริการที่พึ่งพากัน

การอ่านประมาณการของคุณ

ตัวคำนวณมี 3 ส่วนสำคัญ ควรรู้หน้าที่ของแต่ละส่วนก่อนเริ่มกรอกตัวเลข

• ตัวเลือกผลิตภัณฑ์ (Product picker): คือช่องค้นหาและตัวเรียกดูตามหมวดหมู่ด้านบนของหน้า หมวดหมู่ได้แก่ compute, storage, databases, networking และ AI และ machine learning หากไม่ทราบชื่อผลิตภัณฑ์ที่แน่ชัด การเรียกดูตามหมวดหมู่มักจะเร็วกว่าเดาสำคัญค้นหา
• การกำหนดค่าบริการ (Service configuration): ทุกผลิตภัณฑ์ที่เพิ่มจะมีบล็อกการกำหนดค่าของตนเอง และเนื้อหาภายในบล็อกขึ้นอยู่กับบริการนั้นๆ เช่น VM จะถามถึง OS ขนาด และภูมิภาค ขณะที่บัญชีเก็บข้อมูลจะถามถึงระดับความซ้ำซ้อนและความถี่ในการเข้าถึง ไม่มีฟอร์มสากล ต้องกำหนดค่าบริการแต่ละรายการตามเงื่อนไขของมัน
• การใช้งานโดยประมาณ (Estimated usage): ส่วนนี้จะแปลงปริมาณการใช้ที่คาดการณ์ เช่น ชั่วโมง GB และธุรกรรม ให้เป็นตัวเลขดอลลาร์ และยังเป็นช่องที่มักถูกปล่อยไว้ค่าตั้งต้น ซึ่งเป็นข้อผิดพลาดที่กล่าวถึงภายหลังในบทความ

บางบริการจะแสดงทั้งค่าใช้จ่ายชำระล่วงหน้าและรายเดือน การแยกนี้มักเกิดกับการจอง (reservations) ที่จ่ายบางส่วนตอนนี้เพื่อแลกกับอัตรารายเดือนที่ต่ำลง หากเห็นเพียงตัวเลขรายเดือนโดยไม่มีค่าใช้จ่ายล่วงหน้า โดยทั่วไปหมายถึงอยู่ในแผน Pay-As-You-Go

ตัวอย่างแบบเดินตามขั้นตอน: การคิดราคา Virtual Machine

ลองพิจารณา VM แบบใช้งานทั่วไปสำหรับสภาพแวดล้อม staging 

เริ่มจากค้นหา “Virtual Machine” แล้วเพิ่มลงในประมาณการ ผลิตภัณฑ์จะตั้งค่าขนาดและภูมิภาคมาตรฐานไว้ก่อน เปลี่ยนภูมิภาคก่อนเพราะมีผลกับทุกราคาบนหน้า จากนั้นเลือก OS และขนาด VM โปรดทราบว่า Windows มีค่าลิขสิทธิ์เพิ่มเมื่อเทียบกับ Linux เว้นแต่ว่าจะเปิดใช้ Azure Hybrid Benefit

ต่อไปกำหนดการใช้งานที่คาดไว้ ค่าเริ่มต้นของ Microsoft คือ 730 ชั่วโมงต่อเดือน ซึ่งเป็นจำนวนชั่วโมงเฉลี่ยต่อเดือน กล่าวคือ ตัวคำนวณถือว่า VM ทำงานตลอด 24/7 ซึ่งมักถูกต้องสำหรับเซิร์ฟเวอร์ production แต่ไม่เหมาะกับเครื่อง staging ที่ต้องเปิดเฉพาะเวลาทำการ

ลดชั่วโมงจาก 730 เหลือสัก 200 แล้วประมาณการจะอัปเดตทันที การเปลี่ยนแปลงมักไม่เป็นสัดส่วน เพราะบางระดับราคามีขั้นต่ำหรือเป็นแบบขั้นบันได ลดชั่วโมง 70% ไม่ได้แปลว่าค่าใช้จ่ายจะลด 70% เสมอไป ความไม่เชิงเส้นนี้ทำให้อัตราราคาคงที่ไม่สามารถให้ต้นทุนจริงได้ และเป็นเหตุผลเชิงปฏิบัติในการใช้เครื่องคำนวณแทนการดูจากราคาในรายการเพียงอย่างเดียว

การเปรียบเทียบแผนราคา

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

Pay-As-You-Go ไม่ต้องมีข้อผูกมัดและมีอัตราต่อชั่วโมงสูงสุด แต่ยืดหยุ่นเต็มที่ในการปรับขนาดหรือยกเลิกได้ตลอดเวลา Reserved Instances ให้ผูกพันกับขนาด VM เฉพาะในภูมิภาคเฉพาะเป็นเวลา 1 หรือ 3 ปี แลกกับอัตราที่ต่ำลงอย่างมีนัยสำคัญ การประหยัดสำหรับขนาดแบบใช้งานทั่วไปมักอยู่ในช่วง 40–70% ขึ้นกับระยะเวลาที่ผูกพัน

Azure Savings Plan ให้ผูกพันตามจำนวนการใช้จ่ายต่อชั่วโมงแทนที่จะเป็น VM เฉพาะ และ Azure จะใช้ส่วนลดกับ compute ที่เข้าเงื่อนไขทั้งหมด แม้จะเปลี่ยนขนาดหรือย้ายเวิร์กโหลดก็ตาม

ไม่มีคำตอบเดียวที่ถูกต้อง ขึ้นอยู่กับความเสถียรของเวิร์กโหลดและระดับความยืดหยุ่นที่ต้องการ

อะไรคือปัจจัยที่ทำให้ตัวเลขเปลี่ยนจริง

การตัดสินใจด้านสถาปัตยกรรมเพียงไม่กี่อย่าง ไม่ใช่ด้านการเงิน ควบคุมค่าใช้จ่ายส่วนใหญ่ของคุณ:

ภูมิภาค

ภูมิภาคมีบทบาทสำคัญ เพราะขนาด VM เดียวกันอาจมีราคาแตกต่างกันชัดเจนระหว่างภูมิภาค หากข้อกำกับดูแลไม่ได้บังคับให้ต้องอยู่ในภูมิภาคใดภูมิภาคหนึ่ง ลองตรวจสอบตัวเลือกใกล้เคียงสักสองสามแห่ง

ระดับบริการและขนาด

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

ระบบปฏิบัติการและลิขสิทธิ์

ระบบปฏิบัติการก็มีผลต่อราคา เพราะลิขสิทธิ์ Windows และ SQL Server มีต้นทุนจริง ดังที่กล่าวไว้ Azure Hybrid Benefit คือสวิตช์สำหรับทีมที่มีลิขสิทธิ์อยู่แล้ว และมองข้ามได้ง่าย

ปริมาณการใช้งานและแผนราคา

ปริมาณการใช้งานและแผนราคา ตามที่กล่าวไปแล้ว คือจุดที่ทำให้ตัวเลขแกว่งมากที่สุด

ข้อผิดพลาดทั่วไปที่ทำให้ประมาณการพัง

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

ปล่อยค่าการใช้งานเริ่มต้นไว้เหมือนเดิม

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

ลืมบริการที่รองรับ

ข้อที่สองคือลืมบริการที่รองรับ: VM ต้องมีดิสก์ และแอปพลิเคชันโดยทั่วไปต้องมีฐานข้อมูล การประเมินที่คิดราคาเฉพาะบริการหลักและละโครงสร้างพื้นฐานรอบๆ จะประเมินบิลจริงต่ำกว่าความจริงอย่างสม่ำเสมอ 

เลือกภูมิภาคผิด

ข้อที่สามคือเลือกภูมิภาคผิด ซึ่งเกิดได้ง่ายเมื่อประเมินให้ลูกค้าหรือทีมที่อยู่คนละที่กับตนเอง 

มองข้ามค่าโอนย้ายข้อมูลและเครือข่าย

ข้อที่สี่คือมองข้ามค่าโอนย้ายข้อมูลและค่าเครือข่าย ซึ่งแปรผันตามการใช้งาน 

เปรียบเทียบราคารายย่อยกับราคาที่เจรจาไว้

ข้อที่ห้าคือเปรียบเทียบราคารายย่อยกับราคาที่เจรจาไว้: หากองค์กรมีข้อตกลงระดับองค์กร ราคาปกติในเครื่องคำนวณสาธารณะจะไม่ตรงกับที่จ่ายจริง เว้นแต่จะลงชื่อเข้าใช้และใช้ข้อตกลงขององค์กร 

ถือว่าประมาณการคือบิลสุดท้าย

ท้ายที่สุด อย่าถือว่าประมาณการคือบิลสุดท้าย Microsoft เองระบุว่าผลรวมของประมาณการที่บันทึกไว้สามารถเปลี่ยนได้ตามการเปลี่ยนแปลงราคาที่เผยแพร่ของ Azure ดังนั้นควรเผื่อส่วนต่างไว้

Azure Pricing Calculator เทียบกับ Azure Cost Management

เป็นเครื่องมือคนละตัวแก้ปัญหาคนละแบบ Pricing Calculator ใช้ประเมินค่าใช้จ่ายก่อนปรับใช้อะไร ช่วยจำลองการตั้งค่าที่คาดการณ์และเปรียบเทียบสถานการณ์ที่ยังไม่มีจริง ขณะที่ Azure Cost Management วิเคราะห์สิ่งที่ใช้จ่ายจริงหลังทรัพยากรเริ่มทำงานแล้ว มุ่งกับการใช้งานจริง ใบแจ้งหนี้จริง และความผิดปกติจริง

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

แนวทางปฏิบัติที่ดีที่สุดสำหรับการประเมินค่าใช้จ่าย Azure

แนวทางปฏิบัติบางข้อช่วยให้ได้ประมาณการที่น่าเชื่อถือยิ่งขึ้นอย่างสม่ำเสมอ

• จำลองการใช้งานที่สมจริง ไม่ใช่ความจุสูงสุดและไม่ใช่ขั้นต่ำ
• รวมทุกองค์ประกอบในสถาปัตยกรรม ไม่ใช่เฉพาะชิ้นที่ดูแพง
• เปรียบเทียบสองสามภูมิภาคหากข้อกำกับดูแลเอื้ออำนวย
• รันเวิร์กโหลดเดียวกันทั้งแบบ Pay-As-You-Go และแบบมีข้อผูกพันก่อนตัดสินใจ
• สร้าง 3 สถานการณ์ (คาดหวัง ต่ำ และ สูง) แทนตัวเลขเดียว เพื่อมีช่วงสำหรับวางแผน
• ทบทวนประมาณการเมื่อสถาปัตยกรรมหรือราคาของ Azure เปลี่ยน เพราะทั้งสองอย่างไม่คงที่นาน

สรุป

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

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

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