สรุปเหตุขัดข้องของบริการ Amazon DynamoDB ที่เกิดขึ้นในรีเจียนฝั่งตะวันออกของสหรัฐฯ (Northern Virginia, US-East-1)

• วันที่ 19–20 ตุลาคม 2025 รีเจียน AWS N. Virginia (us-east-1) เกิดเหตุขัดข้องเป็นเวลานานกับ Amazon DynamoDB และบริการสำคัญอื่นอีกหลายรายการ
• เหตุขัดข้องเริ่มต้นจากการที่เกิดการสร้าง DNS record ว่างที่ไม่ถูกต้อง เนื่องจาก race condition แฝงในระบบจัดการ DNS อัตโนมัติของ DynamoDB
• ส่งผลให้เกิด ความล้มเหลวในการสร้างอินสแตนซ์ EC2, ข้อผิดพลาดการเชื่อมต่อของ Network Load Balancer (NLB) และ API หน่วงหรือใช้งานไม่ได้ในหลายบริการ เช่น Lambda, ECS, Redshift ต่อเนื่องเป็นลูกโซ่
• AWS ระบุสาเหตุของปัญหาว่าเป็น ความขัดแย้งจากการอัปเดตพร้อมกันผิดปกติระหว่าง DynamoDB DNS Enactor และกู้คืนระบบทั้งหมดได้สำเร็จราว 14:20 น. ของวันที่ 20 ตุลาคม ผ่านการกู้คืนแบบแมนนวล
• เหตุการณ์ครั้งนี้สะท้อนให้เห็นถึง ความซับซ้อนของการพึ่งพากันระหว่างระบบอัตโนมัติภายใน AWS และมีการส่งสัญญาณว่าจะปรับปรุงเชิงโครงสร้างเพื่อเสริมความทนทานของ DNS, EC2 และ NLB ต่อไป

---

ภาพรวมเหตุการณ์

• เหตุขัดข้องเริ่มขึ้นเมื่อวันที่ 19 ตุลาคม 2025 เวลา 23:48 น. (PDT) และสิ้นสุดเมื่อวันที่ 20 ตุลาคม เวลา 14:20 น. (PDT)
  • มีช่วงที่ได้รับผลกระทบหลัก 3 รอบ:
    1. 19 ต.ค. 23:48 น. – 20 ต.ค. 02:40 น.: อัตราข้อผิดพลาดของ DynamoDB API พุ่งสูง
    2. 20 ต.ค. 05:30 น. – 14:09 น.: ข้อผิดพลาดการเชื่อมต่อของ NLB เพิ่มขึ้น
    3. 20 ต.ค. 02:25 น. – 10:36 น.: การสร้างอินสแตนซ์ EC2 ใหม่ล้มเหลวและมีปัญหาการเชื่อมต่อเครือข่าย
• เหตุขัดข้องเริ่มจาก ข้อบกพร่องในระบบจัดการ DNS ของ DynamoDB แล้วลุกลามไปยังบริการจำนวนมาก เช่น EC2, NLB, Lambda และ Redshift

สาเหตุและผลกระทบของ DynamoDB

• ระบบจัดการ DNS อัตโนมัติของ DynamoDB เกิดการทำงานผิดพลาดจากข้อบกพร่องแฝง ทำให้ DNS record ของ dynamodb.us-east-1.amazonaws.com ถูกอัปเดตผิดเป็นค่าว่าง
  • ระบบแยกเป็น 2 องค์ประกอบ:
    • DNS Planner: ตรวจสอบสถานะของ load balancer และสร้างแผน DNS ใหม่
    • DNS Enactor: มีหน้าที่นำการเปลี่ยนแปลงไปใช้กับ Route53
• เกิด race condition ระหว่าง DNS Enactor ที่ถูกวางแยกอิสระใน 3 Availability Zone (AZ)
  • Enactor ตัวแรกนำแผนเก่ามาใช้ในขณะที่ทำงานล่าช้า
  • Enactor ตัวที่สองนำแผนล่าสุดมาใช้ แล้วลบแผนเก่า ส่งผลให้ IP address ทั้งหมดถูกลบออกและระบบเข้าสู่สถานะไม่สอดคล้องกัน
  • การกู้คืนอัตโนมัติล้มเหลว จึงต้องอาศัย การแทรกแซงแบบแมนนวล (manual intervention)
• ทันทีหลังเหตุขัดข้องเริ่มขึ้นเวลา 23:48 น. บริการทั้งหมดและทราฟฟิกลูกค้าที่พึ่งพา DynamoDB ไม่สามารถเชื่อมต่อได้
  • ลูกค้าที่ใช้ global table ยังสามารถส่งคำขอไปยัง replica ในรีเจียนอื่นได้ แต่เกิด replication lag
• เวลา 00:38 น. วิศวกรของ AWS ยืนยันได้ว่าสถานะ DNS คือสาเหตุของปัญหา
  • เวลา 01:15 น. มีมาตรการกู้คืนชั่วคราวที่ช่วยฟื้นการเชื่อมต่อของบริการภายในบางส่วน
  • เวลา 02:25 น. ข้อมูล DNS ถูกกู้คืนครบถ้วน และเวลา 02:40 น. การเชื่อมต่อทั้งหมดกลับสู่ภาวะปกติ

ผลกระทบต่อ Amazon EC2 และกระบวนการกู้คืน

• ระหว่างวันที่ 19 ต.ค. 23:48 น. ถึง 20 ต.ค. 13:50 น. เกิด อัตราข้อผิดพลาดของ EC2 API สูงขึ้น, การสร้างอินสแตนซ์ล้มเหลว และความหน่วงเพิ่มขึ้น
  • อินสแตนซ์ที่กำลังรันอยู่เดิมไม่ได้รับผลกระทบ
• การจัดการอินสแตนซ์ EC2 ใช้ 2 ระบบย่อยคือ DropletWorkflow Manager (DWFM) และ Network Manager
  • DWFM จัดการสถานะของเซิร์ฟเวอร์จริง (“droplet”) และตรวจสอบสถานะเป็นระยะ
  • Network Manager กระจายค่าคอนฟิกเครือข่ายของอินสแตนซ์
• เมื่อ DynamoDB ล่ม การตรวจสอบสถานะของ DWFM ล้มเหลว ทำให้ lease ของ droplet หมดอายุ
  • หลัง DynamoDB กลับมาทำงานเวลา 02:25 น. DWFM พยายามเชื่อมต่อใหม่ แต่ด้วยจำนวน droplet มหาศาลจึงเกิด congestive collapse
  • เวลา 04:14 น. วิศวกรรีสตาร์ตโฮสต์ DWFM บางส่วนแบบเลือกเฉพาะเพื่อเคลียร์คิวและเดินหน้ากู้คืน
  • เวลา 05:28 น. lease ของ droplet ทั้งหมดถูกกู้คืน และเริ่มสร้างอินสแตนซ์ใหม่ได้อีกครั้ง
• หลังจากนั้น Network Manager ต้องประมวลผล backlog ของการกระจายสถานะเครือข่ายที่ล่าช้า ทำให้เกิด ความหน่วงในการเชื่อมต่อเครือข่าย
  • เวลา 10:36 น. เวลาการกระจายข้อมูลเครือข่ายกลับสู่ภาวะปกติ
  • เวลา 11:23 น. เริ่มผ่อนคลายการจำกัดคำขอ (throttling) และเวลา 13:50 น. EC2 กู้คืนสมบูรณ์

ผลกระทบต่อ Network Load Balancer (NLB)

• ระหว่างเวลา 05:30 น. – 14:09 น. ของวันที่ 20 ต.ค. ลูกค้าบางส่วนพบ ข้อผิดพลาดการเชื่อมต่อของ NLB เพิ่มขึ้น
  • NLB มีโครงสร้างแบบ multi-tenant และทำหน้าที่ส่งทราฟฟิกไปยังอินสแตนซ์ EC2 ฝั่ง backend
• สาเหตุของปัญหาคือ ความล่าช้าในการกระจายสถานะเครือข่าย ทำให้ health check ล้มเหลว
  • คอนฟิกเครือข่ายของอินสแตนซ์ EC2 ที่เพิ่งเพิ่มเข้ามายังไม่เสร็จสมบูรณ์ จึงไม่ผ่าน health check
  • ผล health check ที่ขึ้นลงไม่เสถียรทำให้โหนด NLB ถูกถอดออกจาก DNS แล้วกลับเข้าไปใหม่ซ้ำ ๆ
• เวลา 06:52 น. ระบบมอนิเตอร์ตรวจพบปัญหาและวิศวกรเริ่มตอบสนอง
  • เนื่องจากภาระของระบบย่อย health check เพิ่มสูง จึงเกิดการ failover DNS ระดับ AZ โดยอัตโนมัติ
  • เวลา 09:36 น. ปิดการ failover อัตโนมัติ ทำให้โหนดที่ปกติทั้งหมดกลับมา
  • เวลา 14:09 น. หลัง EC2 ฟื้นตัวแล้ว จึงเปิดใช้การ failover อัตโนมัติอีกครั้ง

ผลกระทบต่อบริการ AWS อื่น ๆ

• AWS Lambda:
  • ระหว่าง 19 ต.ค. 23:51 น. – 20 ต.ค. 14:15 น. มีข้อผิดพลาดและความหน่วงของ API
  • จากปัญหา DynamoDB ทำให้การสร้างและอัปเดตฟังก์ชันล้มเหลว และการประมวลผล event จาก SQS/Kinesis ล่าช้า
  • เวลา 07:04 น. การล้มเหลวของ health check ใน NLB ทำให้ระบบภายในบางส่วนถูกลดขนาดลง และมีการจำกัดการเรียกใช้งานแบบ asynchronous
  • เวลา 14:15 น. backlog ทั้งหมดถูกประมวลผลเสร็จและกลับสู่ภาวะปกติ
• ECS, EKS, Fargate:
  • ระหว่าง 19 ต.ค. 23:45 น. – 20 ต.ค. 14:20 น. มีการรันคอนเทนเนอร์ล้มเหลวและการขยายคลัสเตอร์ล่าช้า
• Amazon Connect:
  • ระหว่าง 19 ต.ค. 23:56 น. – 20 ต.ค. 13:20 น. มีข้อผิดพลาดในการจัดการสายโทร, แชต และเคส
  • หลัง DynamoDB ฟื้นตัว ฟังก์ชันส่วนใหญ่กลับมาปกติ แต่หลัง 07:04 น. ก็กลับมามีข้อผิดพลาดอีกจากผลกระทบของ NLB และ Lambda
  • เวลา 13:20 น. กู้คืนสมบูรณ์
• AWS STS:
  • ระหว่าง 19 ต.ค. 23:51 น. – 20 ต.ค. 09:59 น. มีข้อผิดพลาดและความหน่วงใน API สำหรับการยืนยันตัวตน
  • หลัง DynamoDB ฟื้นตัวกลับมาปกติชั่วคราว แต่เกิดข้อผิดพลาดอีกจากปัญหา NLB
• IAM Login และ Identity Center:
  • ระหว่าง 19 ต.ค. 23:51 น. – 20 ต.ค. 01:25 น. การยืนยันตัวตนล้มเหลวเพิ่มขึ้น
  • หลัง DynamoDB ฟื้นตัวก็กลับสู่ภาวะปกติ
• Amazon Redshift:
  • ระหว่าง 19 ต.ค. 23:47 น. – 20 ต.ค. 02:21 น. การรันคิวรีและการแก้ไขคลัสเตอร์ล้มเหลว
  • หลัง DynamoDB ฟื้นตัว คลัสเตอร์บางส่วนยังทำงานผิดปกติอยู่จากปัญหา EC2
  • กู้คืนสมบูรณ์เมื่อวันที่ 21 ต.ค. เวลา 04:05 น.
  • เนื่องจากการพึ่งพา IAM API ทำให้เกิดความล้มเหลวของคิวรีชั่วคราวแม้ใน global region ด้วย
• บริการอื่น ๆ:
  • Managed Workflows for Apache Airflow, Outposts, AWS Support Center และบริการอื่น ๆ ก็ได้รับผลกระทบเช่นกัน

มาตรการหลังเหตุการณ์และแผนการปรับปรุง

• ปิดการทำงานอัตโนมัติของ DynamoDB DNS Planner และ Enactor ทั้งหมดชั่วคราว โดยจะยังไม่เปิดกลับจนกว่าจะแก้ race condition และเพิ่มกลไกป้องกันเสร็จสิ้น
• NLB: เตรียมนำ กลไกควบคุมอัตรา (rate control) มาใช้ เพื่อจำกัดปริมาณความจุที่ NLB เดียวสามารถถอดออกได้เมื่อ health check ล้มเหลว
• EC2:
  • สร้าง test suite ใหม่ที่รวม workflow การกู้คืนของ DWFM
  • ปรับปรุง smart throttling ของระบบกระจายข้อมูล เพื่อเพิ่มความสามารถในการจำกัดคำขอตามขนาดของคิวที่รออยู่
• AWS กำลังทบทวนเพิ่มเติมผ่านการวิเคราะห์การพึ่งพากันระหว่างบริการทั้งหมด เพื่อหาแนวทาง ลดเวลาในการกู้คืนและป้องกันเหตุลักษณะเดียวกันในอนาคต

บทสรุปและคำขอโทษ

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

[shakespeares]

เขาว่ากันว่าเป็นผลกระทบตามมาจากการปลดพนักงานระดับซีเนียร์ออกไป..จริงไหม?

[GN⁺]

ความคิดเห็นบน Hacker News

• ฉันเป็นคนที่พูดเรื่องนี้ซ้ำอยู่เสมอ ถ้าคุณยังไม่ได้อ่าน บทความของ Richard Cook ขอแนะนำให้หยุดอ่าน postmortem นี้ไว้ก่อน แล้วไปอ่าน How Complex Systems Fail ก่อน บทความนี้เป็นหนึ่งในงานเขียนเชิงเทคนิคที่ดีที่สุดเกี่ยวกับความล้มเหลวของระบบที่ซับซ้อน Cook ปฏิเสธแนวคิดเรื่อง “root cause” โดยตัวมันเอง และฉันคิดว่าเขาพูดถูกในเหตุการณ์ครั้งนี้

  • บทความของ Cook ก็ดี แต่เอาเข้าจริงมันให้ความรู้สึกเหมือน การเรียงข้ออ้างที่เข้าใจได้ตามสัญชาตญาณ มากกว่า ถ้าอยากเข้าใจให้ลึกจริง ๆ คงต้องอ่านเอกสารอ้างอิงทั้งหมด วิชา systems ของ MIT อย่าง 6.033 ก็ให้ไปอ่าน บทความปี 1962 และ บทความคลาสสิกอีกชิ้น ที่พูดถึงประเด็นคล้ายกัน ฉันมองว่าปัญหาแบบนี้สุดท้ายก็คือกรณีที่มีความซับซ้อนระดับ “Wicked problem”
  • สิ่งที่น่าประทับใจในบทความของ Cook คือประเด็นที่ว่า ความพยายามจะแก้ระบบให้ “ปลอดภัยขึ้น” หลังอุบัติเหตุ อาจกลับทำให้ ความปลอดภัยลดลงได้ มาตรการที่ตั้งใจป้องกันความผิดพลาดของมนุษย์กลับเพิ่มการเชื่อมโยงกันและความซับซ้อนของระบบ ทำให้มีจุดล้มเหลวแฝงมากขึ้น และตรวจจับหรือสกัดกั้นได้ยากขึ้น คำอธิบายนี้โดนใจฉันมาก
  • อีกมุมหนึ่งคือทฤษฎี “Normal Accidents” ซึ่งบอกว่า ยิ่งองค์ประกอบเชื่อมกันแน่น มีปฏิสัมพันธ์ซับซ้อน และผลของความล้มเหลวร้ายแรงเท่าไร ระบบก็ยิ่งเสี่ยงโดยเนื้อแท้มากขึ้น ดู Normal Accidents บนวิกิ
  • ฉันยังอ่านทั้งสองเอกสารไม่จบทั้งหมด แต่ฉันไม่เห็นด้วยกับคำกล่าวที่ว่า แค่ระบบซับซ้อนก็ทำให้เราไม่อาจระบุ root cause ของความล้มเหลวได้ ในกีฬา การทำคะแนนก็เป็นผลจากหลายปัจจัย แต่สุดท้ายก็ยังมี ‘ผู้ทำคะแนน’ อยู่ การมองภาพกว้างเป็นเรื่องดี แต่การชี้ต้นเหตุสำคัญก็ใช้งานได้จริง
  • ฉันเป็นผู้รับเหมาที่ทำ oncall บริษัทส่วนใหญ่ไม่ได้ให้ความสำคัญกับ oncall อย่างจริงจัง เอกสารก็ไม่พอ และก็ไม่ให้เวลาอ่านโค้ดซับซ้อนของคนอื่นมากพอ ฉันอยากลองสัมผัสวัฒนธรรมแบบ AWS ที่มอง oncall เป็นส่วนหนึ่งของการเรียนรู้และความรับผิดชอบจริง ๆ

• อินเทอร์เน็ตกำลังค่อย ๆ กลายเป็น mononet ที่รวมศูนย์มากขึ้น เดิมทีมันถือกำเนิดในยุคสงครามเย็นในฐานะเครือข่ายกระจายศูนย์ แต่ตอนนี้มันกลายเป็นโครงสร้างที่ความผิดพลาดจากการ deploy แค่ครั้งเดียวสามารถทำให้ธนาคาร การช้อปปิ้ง และการเดินทางทั่วโลกหยุดชะงักได้ อุปมาเรื่อง cloud ไปไกลเกินขีดจำกัดแล้ว
  สำหรับสตาร์ตอัปหรือ R&D มันยังมีประโยชน์ แต่สำหรับบริษัทช่วงเติบโตหรือภาครัฐ ควรมี เซิร์ฟเวอร์ของตัวเอง คลาวด์ของตัวเอง และบริการแกนหลักของตัวเอง เทคโนโลยีกับบุคลากรก็มีพร้อมอยู่แล้ว

• สิ่งที่น่าประทับใจใน postmortem ของ AWS คือ ภาพแสดงไทม์ไลน์ที่แม่นยำ คล้ายกับการบรรยายระดับตำนานของ GDC “I Shot You First” ที่ใช้ลูกศรเอียงแสดงการไหลของเวลาและตั้งคำถามว่า “ความหน่วงเกิดขึ้นตรงไหน” วิธีนี้มีประโยชน์มาก
  แต่สิ่งที่ทำให้ฉันแปลกใจกว่านั้นคือ บริการจัดการ lease ของโหนด EC2 กลับไม่มี ขั้นตอนกู้คืน (runbook) ถ้าเป็นบริการแกนหลักของ AWS ฉันนึกว่าจะมีการเตรียมพร้อมสำหรับสถานการณ์ยกเว้นแทบทุกแบบแล้ว

  • สถานการณ์แบบนี้ไม่ควรถูกมองว่าเป็นเรื่องน่ากลัว แต่ควรถูกมองว่าเป็น รูปแบบเชิงธรรมชาติของระบบซับซ้อน ความล้มเหลวแฝงมีอยู่แบบแฟร็กทัล และเป็นไปไม่ได้ที่จะมี runbook สำหรับทุกกรณีที่เป็นไปได้

• แก่นของเหตุการณ์นี้ดูเหมือนเป็นรูปแบบหนึ่งของปัญหา cache invalidation ในระบบ DNS DNS Enactor สองตัวใช้ plan ด้วยจังหวะเวลาต่างกันจนเกิด race condition และ plan เก่าไปเขียนทับ plan ใหม่

  • นี่เป็นเพียงคำอธิบายสำหรับคนทั่วไปเท่านั้น ภายในจริง ๆ หลังแก้เหตุการณ์แล้วก็จะมี การประเมินโอกาสเกิดซ้ำและจัดทำมาตรการบรรเทา (runbook) จากนั้นก็จะมีการเรียนรู้และแบ่งปันในระดับองค์กรต่อไป
  • ฉันมองว่า race condition ตัวนี้เองคือ root cause ถ้าไม่มีบั๊กนั้น เหตุการณ์นี้ก็คงไม่เกิด
  • ฉันสงสัยว่าทำไมต้องแยก DNS Planner กับ Enactor ถ้าเป็นบริการเดียวกัน สภาวะแข่งขันแบบนี้คงชัดเจนกว่านี้ อาจเป็นผลจาก การใช้ microservices มากเกินไป จนเพิ่มความซับซ้อน
  • ฉันเคยเจอปัญหาคล้ายกัน และต้นเหตุคือ ความหน่วงจาก JVM GC กับฮาร์ดแวร์ที่เสีย ครั้งนี้ก็อาจมีความเป็นไปได้แบบนั้น
  • แต่ AWS ไม่ได้ระบุมาตรการ ป้องกัน ว่าจะทำอย่างไรหากความหน่วงแบบนี้เกิดขึ้นอีก

• Enactor ควรตรวจสอบ การเปรียบเทียบเวอร์ชันของเรคคอร์ดปัจจุบัน (CAS) ก่อนจะใช้ค่าใหม่ แม้ประสิทธิภาพจะลดลงบ้าง แต่นี่คือมาตรการป้องกันพื้นฐาน และน่าจะทำได้ใน DynamoDB เอง

• ฉันแปลกใจที่ DynamoDB จัดการ DNS records หลายแสนรายการต่อรีเจียน แค่ dynamodb.us-east-1.amazonaws.com ก็อาจ resolve เป็น IP หลายแสนตัวได้ ดูเหมือน เกินขีดจำกัดของ Route53 ไปแล้ว น่าจะเป็นวิธีตั้ง TTL ต่ำแล้วอัปเดตเพียงบางส่วน

  • ในทางปฏิบัติ DNS ของ AWS ก็ทำงานแบบนั้น Route53 ทำงานในระดับ resource record set (RRSet) และคืนชุดที่เหมาะสมผ่าน health check หรือ logic การเลือกตาม latency
  • CDN ก็ทำงานคล้ายกัน โดยเก็บ metrics ของระบบแล้วคำนวณ PoP ที่เหมาะที่สุดต่อเครือข่าย bunny.net SmartEdge เป็นตัวอย่างที่ดี
  • ฉันก็ลองทดสอบกับ S3 เหมือนกัน และภายในไม่กี่วินาทีก็ได้ IP ที่ต่างกันหลายร้อยตัว แม้จะเป็นรีเจียนเดียวก็ยังมีความหลากหลายขนาดนี้

• บั๊กมีอยู่เสมอ formal verification เป็นเรื่องยาก และบั๊กที่มีโอกาสเกิดต่ำมากอาจเพิ่งระเบิดขึ้นหลังผ่านไปหลายปี
  ดังนั้นควรออกแบบโดยสมมติว่าระบบต้องล้มเหลวแน่ และสร้างโครงสร้างที่ จำกัดความเสียหาย ได้ เช่น สถาปัตยกรรมแบบ cell, gradual rollout และโซนที่แยกขาดจากกัน
  AWS ก็พยายามทำแบบ cell-based แต่โดยเฉพาะใน us-east-1 ยังมี การพึ่งพาไขว้แบบ legacy เหลืออยู่ ในระยะยาวควรออกแบบให้รีเจียนเป็นอิสระต่อกันอย่างสมบูรณ์
  งานแบบนี้เดินหน้าไม่ได้ถ้าไม่มีการสนับสนุนจากผู้บริหารระดับสูง แต่ในมุมผู้ถือหุ้น มันคือการลงทุนสำคัญเพื่อลด ความเสี่ยงต่อการอยู่รอดของบริษัท

• น่าแปลกที่รายงานใช้ เขตเวลา PT แทน UTC

  • ถึงขนาดมีมุกว่า “epoch fail?” แต่ลูกค้าส่วนใหญ่ก็คงอยู่ในสหรัฐฯ ทำให้ PT อาจเข้าใจง่ายกว่า
  • หรืออาจตั้งใจจะเน้น ความยากของการรับมือในช่วงกลางคืน

• ฉันแปลกใจที่ไม่มีรูปแบบอย่าง versioning ต่อ endpoint หรือ 2PC, single writer lease ถึงอย่างนั้นก็ยังชื่นชมที่ AWS เปิดเผยอย่างโปร่งใสขนาดนี้

  • จริง ๆ แล้ว API สำหรับเปลี่ยน DNS ทำ CAS อยู่ แต่ปัญหาเกิดจาก writer แบบ asynchronous หลายตัวที่ แข่งกันโดยไม่มีลำดับเชิงตรรกะ ควรใช้ zone serial หรือ sentinel record เพื่อ serialize ลำดับ

• ฉันมองว่า สาเหตุโดยตรง ของเหตุการณ์นี้คือ race condition แฝงในระบบจัดการ DNS ของ DynamoDB plan เก่าไปเขียนทับ plan ล่าสุดจน DNS records ของ regional endpoint ว่างเปล่า

  • แต่ก็ต้องระวังกับแนวคิดเรื่อง “root cause” เช่นกัน ครั้งนี้มันเป็น metastable collapse และปัญหาหลักคือการไม่มีขั้นตอนกู้คืน (runbook)
    ดูเพิ่มเติม: How Complex Systems Fail