CloudFormation เพิ่ม Force Rollback: ปลด Stack ที่ย้อนอัปเดตค้างและตรวจ Drift ก่อน Deploy ต่อ

AWS CloudFormation เพิ่ม force rollback ตามประกาศวันที่ 22 ตุลาคม 2026 เพื่อช่วยให้ stack ที่ย้อนการอัปเดตไม่สำเร็จกลับสู่สถานะที่ deploy ต่อได้ในหนึ่งปฏิบัติการ ฟีเจอร์นี้มีให้ทุก Region โดยไม่มีค่าใช้จ่ายเพิ่มเติมตามประกาศ และใช้ได้ผ่าน workflow ของ CloudFormation รวมถึง CLI, SDK และ CDK

ปลดสถานะค้างไม่ได้แปลว่าทรัพยากรตรงแบบแล้ว

ปัญหาของ rollback มักซับซ้อนกว่าการรันคำสั่งเดิมซ้ำ เพราะบางทรัพยากรอาจถูกเปลี่ยนนอก CloudFormation หรือมีเงื่อนไขที่ทำให้คืนค่าไม่ได้ AWS ระบุว่า force rollback ช่วยให้จบ update rollback โดยไม่ต้องไล่ระบุและลองใหม่ทีละทรัพยากร ส่วนทรัพยากรที่ยังต้องดูแลจะถูกบันทึกไว้ให้ตรวจและแก้ก่อน deployment ถัดไป

จุดที่ต้องระวังคือสถานะ stack พร้อม deploy เป็นสถานะของ workflow ไม่ใช่หลักฐานว่าระบบจริงและ template กลับมาเหมือนกันทุกจุด ผู้ดูแลยังต้องอ่านรายการทรัพยากรที่ถูกทิ้งไว้ ตรวจความสัมพันธ์กับแอป และยืนยันว่าการเปลี่ยนครั้งต่อไปจะไม่ลบหรือสร้างสิ่งสำคัญโดยไม่ตั้งใจ โดยเฉพาะ resource ที่เก็บข้อมูลหรือเชื่อมต่อกับระบบภายนอก

ขั้นตอนที่ควรใส่ใน Runbook

ก่อนใช้ ให้บันทึก stack events เหตุผลที่ rollback หยุด และ resource ที่เกี่ยวข้องไว้กับ incident จากนั้นเรียก continue update rollback ด้วย force rollback option ตามเอกสาร AWS หลังจบให้สร้าง drift-aware change set เพื่อดูความต่างก่อน deploy รอบใหม่ ไม่ควรนำคำสั่ง force ไปต่อท้าย pipeline ทุกครั้งที่เกิดข้อผิดพลาด เพราะอาจทำให้สัญญาณความคลาดเคลื่อนถูกมองข้าม

หาก stack ประกอบด้วยฐานข้อมูล storage และบริการรับทราฟฟิก ควรให้เจ้าของแต่ละส่วนตรวจผลตามหน้าที่ เช่น connection endpoint ยังถูกต้องหรือไม่ policy และ network route เปลี่ยนหรือไม่ และข้อมูลที่แอปคาดว่าจะอยู่ยังครบหรือไม่ การดูเพียง HTTP health check ผ่านอาจไม่ครอบคลุมเส้นทางที่ใช้ทรัพยากรซึ่ง rollback ไม่สำเร็จ

ใช้เพื่อกู้การทำงาน แล้วแก้ต้นเหตุ

ทีมที่มี CDK หรือ AI agent เป็นผู้เริ่ม deployment ควรเก็บขอบเขตอำนาจของการกู้ stack แยกจากการตัดสินใจ deploy ต่อ การมี operation ที่สั้นลงช่วยลดเวลาจัดการสถานะค้าง แต่ไม่ได้ย้ายความรับผิดชอบการยืนยัน drift ออกจากผู้ดูแล ควรกำหนดว่าเมื่อพบ resource ที่ต้องแก้ด้วยมือ pipeline จะหยุดตรงใดและใครรับช่วง

ตัวชี้วัดที่มีประโยชน์คือเวลาจาก rollback ล้มเหลวถึงกลับมาพร้อม deploy จำนวนทรัพยากรที่ยังต้องแก้ และจำนวนเหตุการณ์ที่เกิดซ้ำจากการเปลี่ยนนอกระบบ หากทำให้ขั้นตอนกู้เร็วขึ้นแต่ drift สะสมเพิ่ม ผลลัพธ์อาจไม่ดีต่อการดูแลระยะยาว ข่าวนี้จึงควรนำไปปรับ runbook พร้อมกระบวนการตรวจ change set มากกว่ามองเป็นปุ่มข้ามปัญหา

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