เกิดเหตุขัดข้องกับบริการหลายรายการของ AWS ในภูมิภาค us-east-1

 (health.aws.amazon.com)
1 คะแนน โดย GN⁺ 2025-10-21 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • AWS มีเหตุขัดข้องเกิดขึ้นกับบริการหลากหลายใน ภูมิภาค us-east-1
  • เหตุขัดข้องนี้ทำให้องค์กรที่ใช้ โครงสร้างพื้นฐานคลาวด์ ต้องประสบกับการหยุดให้บริการ
  • รายงานปัญหาความพร้อมใช้งานของบริการสำคัญเช่น API Gateway, Lambda
  • วิศวกรย้ำถึงความจำเป็นในการจัดทำ เส้นทางสำรอง และพิจารณามาตรการตอบสนองฉุกเฉิน
  • AWS Health Dashboard จะให้ข้อมูลเหตุขัดข้องและอัปเดตแบบเรียลไทม์

ภาพรวมเหตุขัดข้องในภูมิภาค AWS us-east-1

  • ในวันที่ 21 ตุลาคม 2025 AWS Health Dashboard ระบุว่าในภูมิภาค us-east-1 มีเหตุขัดข้องเกิดขึ้นกับบริการหลายรายการ
  • โดยเฉพาะบริการสำคัญอย่าง API Gateway, Lambda, S3 ได้รับผลกระทบ ทำให้ลูกค้าจำนวนมากประสบกับการหยุดให้บริการ
  • ตั้งแต่เริ่มเกิดเหตุ ฝ่าย AWS ได้รับรู้ปัญหาและเริ่ม วิเคราะห์สาเหตุและการกู้คืน โดยทันที
  • บริษัท SaaS สตาร์ตอัป และไอทีที่พึ่งพาภูมิภาคนี้รายงาน ความล่าช้าของบริการและ downtime
  • วิศวกรและผู้ดูแลระบบไอทีเน้นการสร้าง เส้นทางสำรองฉุกเฉิน และความสำคัญของกลยุทธ์การใช้งานหลายภูมิภาคสำหรับบริการสำคัญ

ผลกระทบและการตอบสนอง

  • us-east-1 เป็นหนึ่งในภูมิภาคที่มีปริมาณทราฟฟิกสูงที่สุดใน โครงสร้างพื้นฐานคลาวด์โลก จึงมีผลกระทบรุนแรงต่อระบบกว้างเมื่อเกิดเหตุขัดข้อง
  • ในทางปฏิบัติ ลูกค้าหลายรายประสบปัญหาพร้อมกัน เช่น การหยุดให้บริการ การหน่วงเวลา API และความล้มเหลวในการประมวลผลข้อมูล
  • AWS ให้ข้อมูลสถานการณ์แบบเรียลไทม์ผ่าน Health Dashboard พร้อมเอกสารการช่วยเหลือและอัปเดตต่างๆ
  • ทีมไอทีของลูกค้าดำเนินการ การมอนิเตอร์สถานการณ์ความขัดข้อง ชั่วคราว โดยย้ายผ่านเส้นทางสำรอง และแจ้งผู้ใช้เพื่อพยายามลดความเสียหาย
โฆษณา

ข้อคิดสำหรับวิศวกร

  • การเน้นย้ำความสำคัญของ ระบบมอนิเตอร์ และระบบแจ้งเตือนเหตุขัดข้องในช่วงเกิดเหตุ
  • ความสำคัญของการออกแบบสถาปัตยกรรมที่ทนทาน (resilient) เช่น การปรับใช้หลายภูมิภาค, การดำเนินการตอบสนองอัตโนมัติ และกลยุทธ์การสำรองข้อมูลได้รับการเน้นย้ำ
  • AWS Health Dashboard ถูกใช้เป็นเครื่องมือช่วยเข้าถึงข้อมูลอย่างรวดเร็วและสนับสนุนการตัดสินใจในช่วงเหตุขัดข้อง

สรุป

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

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2025-10-21
ความคิดเห็นจาก Hacker News
  • วันนี้เป็นวันที่น่าติดตามมาก ผมอยู่ในห้องประสานงานรับมือเหตุขัดข้องตั้งแต่ตี 3 ระบบโดยรวมเกือบฟื้นตัวแล้ว แต่ยังมีบางทีมด้าน back office ที่ยังตกรุ่นเพราะขาดแคลนทรัพยากร สิ่งที่เราพลาดร้ายแรงที่สุดคือ เราออกแบบให้ทำงานแบบ multi-region ได้ แต่กลับไม่สามารถรันกระบวนการ failover ได้ เพราะทีมความปลอดภัยย้ายเราไปใช้ Identity Center แล้ววางไว้เพียงที่ us-east-1 เท่านั้น ทำให้ทั้งองค์กรถูกล็อกเข้ากับ AWS control plane อย่างสมบูรณ์เมื่อดึง root credentials ออกจาก vault ออกมาแล้ว ระบบแทบฟื้นตัวหมดแล้ว เหตุการณ์นี้ย้ำอีกครั้งว่า จุดที่อ่อนแอที่สุดคือสิ่งที่กำหนดความแข็งแกร่งทั้งหมด
    • หลายปีที่แล้วนึกถึงตอนที่ศูนย์ข้อมูลของ Google ในปารีสถูกน้ำท่วมแล้วเกิดไฟไหม้ เราไม่ได้วาง compute resources ของตัวเองที่นั่นโดยตรง แต่บริการคำนวณอยู่ใน AWS EU และ DNS resolver สำหรับบริการของ Google โฮสต์ที่ปารีส ทำให้เส้นทางการเข้าถึงถูกกำหนดไปที่ปารีสเป็นหลัก วิธีแก้ไขชั่วคราวครั้งนั้นสนุกมาก ตอนนั้นได้รู้ว่าการแก้ไฟล์ /etc/hosts ที่ deploy ใน Kubernetes ทำได้ทั่วโลกได้ง่าย และในสถานการณ์นั้นจำเป็นมาก ปกติเราไม่ค่อยใช้ /etc/hosts เพื่อจุดประสงค์แบบนี้ แต่ในฐานะ patch ชั่วคราว มันเป็นระดับ abstraction ที่พอดีมาก
    • นึกถึงเหตุการณ์คล้ายกันที่ Facebook ที่อัปเดต BGP ผิดพลาดจนเข้าถึง vault ไม่ได้เลย หากเส้นทางยืนยันตัวตนเป็นวงจร พอ DNS พังครั้งเดียวก็ทำอะไรไม่ได้
    • สุดท้ายก็ต้องมีใครสักคนถือ hardware token ขึ้นเครื่องไปยัง datacenter อื่นเพื่อรีเซ็ตอุปกรณ์หลักที่ทำให้ระบบทั่วโลกกลับมาทำงาน
    • มีคนพูดถึงว่า Identity Center วางไว้ที่ us-east-1 เท่านั้นเลยคิดว่าสามารถวางหลายรีเจียนได้ไหม ตอนที่ผมเช็กล่าสุดพบว่าสามารถใช้ได้ที่รีเจียนเดียว และถ้าจะย้ายต้องลบก่อน
    • ความปลอดภัยที่เคร่งเกินไปกลับทำให้ไม่สามารถเคลื่อนไหวได้ อยากรู้ว่าทีมความปลอดภัยจะรับผิดชอบเหตุนี้ไหม เห็นชัดว่ามันจะทำให้ทุกโปรเจกต์ช้าลงไปอีกมาก ทีมความปลอดภัยดูเหมือนขับรถเร็วเกินไปมานานแล้ว แต่ใครกันที่เฝ้าดูคนเฝ้าดู
  • ดูเหมือนเหตุขัดข้องหลักยังคงดำเนินต่อเนื่องอยู่ สถานะตอนนี้แย่ลงจากสี่ชั่วโมงที่แล้ว ผมเป็น data engineer และ Redshift กับ Airflow (บริการ managed ของ AWS) พังแบบครึ่งครึ่งหนักมาก
    • การล่มกินเวลายาวพอสมควรจนสงสัยว่าสูญเสีย 9 หลุดไปกี่ตัวแล้ว คิดจาก 365 วัน * 24 ชั่วโมง * 0.0001 ก็ได้ประมาณ 8 ชั่วโมง ซึ่งหมายความว่าเราสูญเสีย 99.99% availability ไปแล้ว
    • ไม่เข้าใจว่าทำไมหลายบริษัทยังยึดติดกับ us-east-1 อยู่ แม้ดูจากความถี่ของเหตุขัดข้องแล้วสถานที่นี้คือจุดแย่ที่สุดตามสถิติ บริษัทเราก็ตัดสินใจหลีกเลี่ยง us-east-1 และใช้รีเจียนอื่นมาก่อนแล้ว แน่นอนว่าหากบริการถูกเรียกว่า “global” มักหมายถึง us-east-1 จริงๆ และบางครั้งก็ไม่ช่วย
    • งาน control plane ของ Lambda create-function ยังล้มเหลวด้วย InternalError อยู่ ขณะนี้บริการอื่น ๆ (Lambda, SNS, SQS, EFS, EBS, CloudFront) ฟื้นตัวแล้ว ผมกำลังทำวิจัย CS ระดับปริญญาโทด้าน cloud availability จึงทดสอบในหลายบัญชี AWS และสรุป timeline กับผลกระทบเอาไว้เป็นลายลักษณ์อักษร โพสต์วิเคราะห์
    • Down Detector ยังแสดงว่าเหตุขัดข้องของ AWS ยังรุนแรงอยู่ Amazon ระบุว่า ‘บริการกำลังฟื้นตัว’ แต่ในความเป็นจริง Amazon.com เองยังค้นหาสินค้าไม่ได้เช่นกัน หน้า AWS Health
    • ตามข้อมูล DownDetector เวลา 12:52 AM PT (3:53 AM ET) มีการรายงานปัญหา AWS 5,755 ครั้งที่เวลา 4:22 AM PT (7:22 AM ET) ลดลงเหลือ 1,190 และเวลา 9:32 AM PT (12:32 PM ET) พุ่งขึ้นอีกเป็น 9,230 ราย การเพิ่มจากฝั่ง US West ที่ลุกขึ้นมาเองอาจเป็นปัจจัยหนึ่ง แต่ดูเหมือน AWS ยังยังคุมสถานการณ์ไม่ได้อย่างครบถ้วน
  • ความล่มครั้งนี้กระทบตรงชีวิตประจำวันผมโดยตรง ตอนนี้กำลังไปซื้อช็อกโกแลตบาร์ที่ Whole Foods ที่ Hudson Yards นิวยอร์กแล้วส่วนลด Prime ใช้ไม่ได้ เลยไม่ซื้อมายังไงก็ได้ และระดับช็อกโกแลตปัจจุบันของผมต่ำมาก
    • เช้านี้สั่ง “alexa เปิดเครื่องชงกาแฟให้” ก็ไม่ได้ผล ทำให้อาการงงมากขึ้น
    • ตอนเที่ยงเอาอาหารจากฮอตบาร์ไปแช็คเอาต์เอง แต่เดาไปนานมากว่าทำไมบาร์โค้ดของ Whole Foods ถึงไม่ทำงาน จนกว่าจะผ่านไปประมาณ 20 วินาทีถึงรู้ว่าเป็นเพราะเหตุขัดข้อง
    • ขอบคุณที่แชร์กรณีสนุกๆ นี้ อย่างน้อยทำให้สงสัยว่าคนที่อยู่ใน Amazon Go ตอน AWS ล่มเป็นอย่างไร
  • วันนี้มีนัดพบผู้รับผิดชอบบัญชี AWS และจะเสนอว่านโยบาย “All in on AWS” จะถูกเปลี่ยนไปกระจาย workload ต่อไป เหตุผลหลักคือความเร็วนวัตกรรมของบริการแกนหลักช้าลง และบริการ AI ก็ตกรุ่นหลังคู่แข่งมากกว่านั้น AWS Team มักยืนยันเสมอว่าเรื่องเสถียรภาพสูงของ AWS ควรไม่ต้องแยกคลาวด์ บ่ายนี้คงได้ยินแนวคิดชัดๆ
    • ไม่ว่าเป็น AWS, Cloudflare, Google Cloud หรือ Akismet ล้วนเจอเหตุขัดข้องได้เหมือนกัน ทุกครั้งทำให้คิดถึงการย้ายไปโฮสต์ในองค์กรบ้าง เราอาจได้เครดิตคืนเงินและกลับมาเปิดใช้งานอีกครั้ง อยู่ ๆ ผลลัพธ์ก็แทบไม่ต่างกัน จึงคิดว่าไม่จำเป็นต้องเสียแรงมากกว่านี้
    • ในรายงานผลประกอบการรอบก่อน ตอน Andy Jassy ถูกวิจารณ์เรื่อง AWS ล้าหลังด้านนวัตกรรม เขาตอบว่าเน้นเสถียรภาพ ความเชื่อถือได้ และความทนทาน แต่จากสถานการณ์ปัจจุบันข้ออ้างนี้ไม่สามารถยืนได้
    • ยกเว้น us-east-1 แล้วรีเจียนอื่นค่อนข้างเสถียร ผมบริษัทเองก็ย้ายไปไว้ที่ eu-west-1 เป็นส่วนใหญ่และยังทำงานได้ดีโดยไม่มีปัญหาสำคัญ
    • AWS ดูเหมือนกำลังเข้าสู่การเสื่อมถอยระยะยาว ตอนนี้รู้สึกว่าเป็นการคงบริการเดิมเป็นหลัก นักนวัตกรรมที่ดีๆ ก็ถูกระบบราชการภายในและแรงกดดันผลลัพธ์กลืน จึงตามหลังในฝั่ง AI ไปอีก
    • การอ้างว่า AWS มีเสถียรภาพยอดเยี่ยมเดิมทีไม่เป็นความจริง ผมเคยตั้งระบบมอนิเตอร์แบบ multi-cloud พร้อม dedicated server ไว้มาก่อน และเห็นชัดว่าใครล้มก่อนในเหตุขัดข้องครั้งใหญ่ AWS ไม่ได้เป็นอันดับหนึ่งเสมอ ข้อมูลกลับตรงกับ netcraft.com อย่างมาก
  • ลีกพรีเมียร์ลีกวันนี้ก็มีกำหนดให้ระบบ VAR และระบบตัดสินออฟไซด์อัตโนมัติทำงานแบบจำกัดเพราะ AWS outage นี่แหละครับ แปลกจริง ๆ ว่าถึงยุคนี้แล้ว ลิงก์ BBC
    • รู้สึกได้ถึงแง่มุมบวกเล็กน้อยจาก cloud outage
  • หากกำหนด us-east-1 เป็นรีเจียนหลัก ความเสียหายจะมาพร้อมกันทั้งระบบ จึงไม่ใช่มีใครเดือดร้อนคนเดียว รีเจียน AWS อื่นใน US ไม่ได้รับ privilege แบบนี้
    • หนึ่งในข้อดีที่ไม่คาดคิดตอนย้ายจาก data center เดิมไป AWS คือ เมื่อมีการปิดรีเจียนทั้งเลเยอร์ ผู้ใช้จะเข้าใจง่ายขึ้น เพราะล้มพร้อมกันพร้อมๆ กันจึงผ่านไปได้
    • บางครั้งองค์กรทุกแห่งควรประสบ technical downtime อย่างน้อยหนึ่งครั้ง
    • โอเค งั้นก็ย้าย infrastructure ไป US-East-1 กัน
    • ในโลกองค์กร การเข้าใจว่าสิ่งสำคัญจริงๆ ใช้เวลาไม่น้อย ที่จริงแล้วความสำคัญอาจอยู่ที่ความสามารถเอาความผิดไปให้คนอื่นได้มากกว่า availability หากคนงานทำผิดแล้วล่ม 5 นาทีต่อปี ก็เป็นความรับผิดชอบของ CTO แต่ถ้า AWS ล่ม 5 ชั่วโมงก็เป็นเรื่องที่ทุกคนยอมรับได้ว่าแก้ไม่ได้ สุดท้าย AWS, Crowdstrike และอื่นๆ จึงไม่ได้หมายถึงความแข็งแรง ความคุ้มค่า หรือความเสี่ยงที่ถูกจัดการ แต่คือช่วงที่ทุกคนต้องเดือดร้อนไปด้วยกัน ความไม่สะดวกยังคงอยู่ และสำหรับคนที่ชอบระบบเทคโนโลยีที่เดินหน้าได้ดีมันก็รำคาญมาก
    • ตอนนี้รีเจียนโตเกียวยังทำงานได้ดี มีเพียงบางฟีเจอร์อย่างการล็อกอินคอนโซลที่ยังติดปัญหา
  • มีประกาศจากฝ่าย incident ว่า “ผลสรุปพบว่าปัญหาน่าจะเกี่ยวข้องกับปัญหาการ resolve DNS ของ DynamoDB API endpoint ใน us-east-1 และเรากำลังเร่งการฟื้นฟูผ่านทางขนาน” เสมอเหมือนเดิม สาเหตุสุดท้ายก็คือ DNS นี่เอง
    • อยากรู้ว่าการล่มนี้คือปัญหา DNS resolution จริงๆ หรือเป็นเรื่องการตั้งค่า/การจัดเก็บข้อมูลภายใน DNS server กันแน่ ผมเดาแล้วว่าเป็นอย่างหลังมากกว่า
    • ภายหลังประกาศระบุว่าเป็น network load balancer failure ซึ่ง DNS คืออาการของรากปัญหา ไม่ปฏิเสธได้ว่า DNS อาจทำให้ health check พัง แต่ผมคิดว่าความเป็นเหตุหลักคือเครือข่าย
    • บางที BGP อาจแฝงตัวเป็นปัญหา DNS ได้
    • ต้นตอมาจาก us-east-1 อยู่เสมอ
    • แม้ไม่ใช่ DNS แต่สุดท้ายก็คือ DNS
  • ความทนทานที่วางแผนไว้ได้ทำงานตามที่ออกแบบไว้ เราตั้ง static site origin แบบ multi-region บน CloudFront จึงผ่านเหตุขัดข้องนี้ได้ดี ส่วน control plane ก็เป็นโครงสร้าง multi-region แบบ native และต้องพึ่งบริการหลายตัว แต่ยังคง availability ได้ แต่ละรีเจียนทำงานอิสระ และ replicate ข้อมูลได้ แม้ไม่ replicate ไป us-east-1 ก็ไม่มีผล ระบบถูกออกแบบเป็น multi-region และทำ failover หลายชั้น (DNS, routing, destination choice) ครับ แน่นอนว่าวิธีนี้ไม่สมบูรณ์และยังมีจุดล้มเหลวหลายแห่งอยู่ แต่ครั้งนี้มันทำงานได้ดี ช่างเป็นความภูมิใจ งานของผมไม่ใช่ rocket engineering และไม่ได้แพงแรงมาก เป็นวิธีที่ต่างจากแนวปฏิบัติปกติ เปิดเผยได้เสมอหากสงสัย
    • การวาง CloudFront ให้มี static origin หลายรีเจียนเพื่อเลี่ยง AWS outage ควรเป็น standard ในปี 2025 แล้ว แต่นี่ยังคงเป็นเรื่องที่ชมได้อยู่
    • อยากรู้ว่าเป็นสถาปัตยกรรม active/active หรือไม่ และ data stack จัดเรียงยังไง ผมว่าตรงนี้ยากเป็นพิเศษ
    • อยากรู้ว่าการทำ key และ certificate แบบ fault-tolerant authentication ทำอย่างไร
  • ปัญหาใหญ่คือ IAM/Auth เกิด chain reaction เมื่อระบบนี้เกิด overload หรือ down โดยมีข้อมูลว่าต้นเหตุคือ DynamoDB อยากรู้อีกว่า IAM ต้องพึ่ง Dynamo ภายในหรือไม่ ในระบบขนาดใหญ่ที่มี dependency มากมาย IAM/Auth เสี่ยงกลายเป็น global single point แน่นอนจึงอยากลดการผูกพึ่งพาให้น้อยที่สุด แต่ปัจจัย scalability, consistency ก็สำคัญจึงต้องใช้ DB ที่ผ่านการพิสูจน์ผล เมื่อระบบล่มเสร็จจึงต้องผ่าน bootstrap ที่ซับซ้อนด้วยเช่นกัน สงสัยว่าพวกเขาจัดการยังไง
    • ประมาณปี 2017 เคยมีเหตุขัดข้องใหญ่ของ DynamoDB EC2 เก็บ server list ใน DynamoDB พอ DynamoDB ล่ม EC2 ก็ล่มตาม เพราะ DynamoDB รันบน EC2 จึงไม่สามารถยก EC2 ใหม่เพื่อฟื้นฟูได้ ต้องรัน instance ทีละตัวด้วยมือเป็นหลายวัน หลังจากนั้นผมก็เลยพยายามแยก dependency ระหว่างระบบระดับหนึ่งอย่าง S3, DynamoDB, EC2 ให้มากที่สุดเท่าที่จะทำได้ แม้ว่าแบบนี้จะไม่สมบูรณ์แบบ 100%
    • ลูกค้า AWS จำนวนมากมี retry policy ที่ไม่เหมาะสม จนเมื่อระบบหนึ่งมีปัญหาก็ซ้ำเติมให้อีกระบบ overloaded ได้ เหตุขัดข้องของ DynamoDB จึงทำให้ IAM ล่มตาม
    • ภายใน Amazon มีแพลตฟอร์ม KV store ชื่อ Dynamo ซึ่งแยกจาก DynamoDB ดังนั้นเหตุเกิดอาจเป็น DNS routing หรือการ deploy node ก็ได้ ปัญหาแบบนี้ขึ้นซ้ำๆ ใน postmortem ของความล่มใหญ่
    • เมื่อผมทำงานที่ AWS แล้ว IAM ไม่ได้พึ่ง Dynamo อย่างตรงๆ ตอนนี้อาจมีการเปลี่ยน แต่ผมไม่มั่นใจ อย่างไรก็ดีผมคิดว่าปัญหาใหญ่คือเครือข่ายเป็นตัวกระตุ้น แท้จริงแล้วเพื่อไม่ให้ Auth/IAM เป็น global single point จึงพยายามลด dependency และให้ IAM มี cache แบบ read-only ในแต่ละรีเจียน พร้อมกับออกแบบ AWS SigV4 ให้ทำงานโดยคำนึงถึงการแยกรีเจียนไว้แล้ว (เอกสารอ้างอิง)
    • ก็น่าสนใจมากว่าเหตุขัดข้องล่าสุดของ GCP ก็ดูมีรากปัญหาคล้ายๆ กัน
  • AWS ประกาศเวลา 3:03AM PT ว่ากำลังฟื้นตัว แต่สถานการณ์กลับเลวร้ายลง เมื่อ 9:13AM PT มีข้อความว่ากำลังวิเคราะห์สาเหตุใหม่อีกครั้ง ดูเหมือน AWS เองยังไม่เข้าใจสาเหตุที่แท้จริง ทำให้เกิดความกังวลตามมา
    • เหตุการณ์นี้ตรงกับสัปดาห์ Diwali (เทศกาลใหญ่ที่สุดของอินเดีย) จึงน่าจะมีผลจากวิศวกรอินเดียหลายคนที่อยู่ช่วงวันหยุด