Skip to main content
Back to articles

Aurora และ RDS จอง Compute Capacity แบบ On-Demand ได้แล้ว ต้องแยกจากส่วนลดราคา

Amazon Aurora และ Amazon RDS รองรับ On-Demand Capacity Reservations ตามประกาศวันที่ 21 ตุลาคม 2026 เพื่อให้ผู้ใช้กัน compute capacity ของ DB instance ในหนึ่งหรือหลาย Availability Zones ไว้สำหรับงานที่ต้องการความมั่นใจว่าจะมีเครื่องพร้อมเมื่

Aurora และ RDS จอง Compute Capacity แบบ On-Demand ได้แล้ว ต้องแยกจากส่วนลดราคา

Amazon Aurora และ Amazon RDS รองรับ On-Demand Capacity Reservations ตามประกาศวันที่ 21 ตุลาคม 2026 เพื่อให้ผู้ใช้กัน compute capacity ของ DB instance ในหนึ่งหรือหลาย Availability Zones ไว้สำหรับงานที่ต้องการความมั่นใจว่าจะมีเครื่องพร้อมเมื่อสร้าง กู้คืน ขยาย compute หรือ start ฐานข้อมูล ประเด็นนี้เกี่ยวข้องกับความพร้อมของ capacity และต้องแยกจากการซื้อส่วนลดค่าใช้งาน

จองอะไร และยังไม่ได้ยืนยันอะไร

ผู้ใช้เลือก DB instance class, engine, Availability Zones และจำนวน capacity ต่อ zone จากนั้นอ้างอิง reservation ตอนสร้าง restore modify หรือ start DB instance ได้ ตามประกาศสามารถกัน capacity ตั้งแต่สอง AZ ขึ้นไปเพื่อรองรับ Multi-AZ deployment ความสามารถนี้ออกแบบเพื่อลดโอกาสที่ operation ดังกล่าวล้มเหลวเพราะ capacity ไม่เพียงพอ

การกัน compute ไม่ได้แทนแผน high availability ทั้งระบบ แอปยังต้องจัดการ connection การสลับ endpoint ข้อมูลสำรอง และ dependency อื่น การจองเครื่องจึงควรอยู่ในแผน migration หรือ disaster recovery ที่ทดสอบครบเส้นทาง มิใช่ใช้เป็นหลักฐานเพียงอย่างเดียวว่ากู้บริการได้ตามเวลาที่ต้องการ

ต้นทุนเกิดแม้ยังไม่เปิด DB Instance

AWS ระบุว่าจองใช้ทันทีโดยไม่มี commitment และยกเลิกเมื่อใดก็ได้ หรือกำหนดเริ่มในอนาคต 5 ถึง 120 วันภายใต้ minimum commitment ตามเงื่อนไขบริการ capacity ที่จองคิดตาม On-Demand rates ระหว่าง reservation ทำงาน แม้ยังไม่มี DB instance รันอยู่ ส่วนลดจาก Reserved DB Instances หรือ Database Savings Plans ที่มีอยู่ใช้ได้อัตโนมัติตามประกาศ

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

วางแผนร่วมกับเหตุการณ์ธุรกิจ

งานที่เหมาะนำไปประเมิน ได้แก่ ย้ายฐานข้อมูลก่อนเปิดตัวสินค้า ช่วงยอดใช้งานพุ่งตามฤดูกาล หรือการทดสอบกู้ระบบที่ต้องการ instance class เฉพาะ ควรตรวจ engine และ class ที่ต้องใช้จริงในทุก AZ พร้อมระบุว่าถ้าขั้นตอน restore ใช้เวลานานกว่าคาด reservation จะยังครอบคลุมช่วงนั้นหรือไม่

ก่อน production ให้ทดลองอ้างอิง reservation กับฐานข้อมูลทดสอบและบันทึกวิธียืนยันว่าใช้ capacity ที่กันไว้ถูกต้อง เปรียบเทียบเวลาสร้างหรือกู้คืนกับ baseline โดยแยกเวลารอ capacity ออกจากเวลาที่ใช้คืนข้อมูล AWS ระบุเปิดใน commercial Regions ทั้งหมดสำหรับ Aurora และ RDS แต่รายละเอียด engine และการใช้งานต้องตรวจเอกสารล่าสุด การมีเครื่องพร้อมเป็นเงื่อนไขที่ดี ส่วนความสำเร็จของแผนต้องยืนยันด้วยการซ้อมครบขั้นตอน

แหล่งข่าว: ประกาศทางการวันที่ 21 ตุลาคม 2026