AWS ยอมรับข้อมูลลูกค้าสูญหายถาวร และ Multi-AZ ป้องกันสงครามไม่ได้

โดย Nokka (นก-กา) | 18 กันยายน 2026

บทความนี้เขียนโดย AI (โมเดล deepseek-v4.1-flash ของผู้ให้บริการ ollama-cloud) ผ่าน Hermes Agent จาก Nous Research ตรวจสอบและเรียบเรียงโดย Nokka

มีประโยคหนึ่งจาก AWS ที่ผมอ่านแล้วต้องวางมือจากงานอื่น [1][2]

"ความเสียหายต่อโครงสร้างพื้นฐานของเรา *แผ่ข้ามหลาย Availability Zone และเกินกว่าที่บริการระดับภูมิภาคและ multi-AZ ของเราถูกออกแบบมาให้รับได้*"

⇒ ประโยคนี้สั้น แต่ความหมายหนัก ⇒ เพราะ multi-AZ คือคำตอบมาตรฐานที่ทั้งอุตสาหกรรม cloud ใช้ตอบคำถามเรื่องความเสียหาย ⇒ และตอนนี้ AWS บอกเองว่า มันไม่พอ

หนึ่ง: เกิดอะไรขึ้น และ AWS ยอมรับอะไร

AWS ประกาศในอัปเดตบน health dashboard เมื่อวันที่ 15 กันยายน 2026 ⇒ เป็นการอัปเดตสาธารณะครั้งแรกนับจากเดือนเมษายน [1][3]

สรุปสิ่งที่ AWS ยอมรับ [1][2][4]

UAE (me-central-1)      ⇒ กู้ข้อมูลไม่ได้ใน 1 จาก 3 availability zone (mec1-az2)
                          อีกสองโซน (mec1-az1, mec1-az3) ยังกู้อยู่
Bahrain (me-south-1)    ⇒ กู้ข้อมูลไม่ได้ทั้งภูมิภาค ⇒ ทั้ง 3 availability zone

⇒ และ AWS ยอมรับเพิ่มเติมว่า ⇒ "เราประเมินโครงสร้างพื้นฐานที่ได้รับผลกระทบทั้งหมดแล้ว *และใช้ทางเลือกทุกทางที่มีในการกู้ข้อมูลและทรัพยากรที่ยังไม่ได้ย้าย** ก่อนที่ภูมิภาค Bahrain จะใช้งานไม่ได้"* [5]

⇒ แปลว่ามันไม่ใช่ "ยังกู้อยู่" แต่คือ "กู้ไม่ได้แล้ว" [5]

ไทม์ไลน์ ⇒ และนี่คือส่วนที่ผมคิดว่าสำคัญกว่าตัวข่าว

การโจมตีไม่ได้เกิดครั้งเดียว แต่เกิดสามครั้ง ห่างกันหลายเดือน [1][2]

เวลา	เหตุการณ์
28 ก.พ. 2026	สหรัฐและอิสราเอลโจมตีอิหร่าน ⇒ สงครามเริ่ม
1 มี.ค. 2026	โดรนอิหร่านโจมตี ⇒ UAE: โดนตรง 2 อาคาร · Bahrain: โดรนตกใกล้ ทำโครงสร้างเสียหาย
เม.ย. 2026	โจมตีซ้ำที่ Bahrain ⇒ AZ ที่สองเสียหาย ⇒ ภูมิภาค Bahrain ล่มทั้งภูมิภาค
24 ก.ค. 2026	IRGC ยิงขีปนาวุธเฉพาะเจาะจงอาคารที่เหลือใน Bahrain ⇒ ยืนยันด้วยภาพถ่ายดาวเทียม
15 ก.ย. 2026	AWS ยอมรับว่ากู้ข้อมูลบางส่วนไม่ได้

⇒ สังเกตว่า AWS แนะนำให้ลูกค้าย้าย workload ออกตั้งแต่เดือนเมษายน ⇒ และ "ลูกค้าส่วนใหญ่ทำตามก่อนที่ภูมิภาค Bahrain จะใช้งานไม่ได้" [5][6]

⇒ นั่นแปลว่าข้อมูลที่หายไป คือข้อมูลของลูกค้าที่ไม่ได้ย้าย ⇒ ซึ่งเป็นกลุ่มที่ไม่มี backup หรือไม่ได้ทำ replication ไว้ที่ภูมิภาคอื่น [7]

และความเสียหายมาจากน้ำ ไม่ได้มาจากระเบิดอย่างเดียว

นี่คือรายละเอียดที่ผมหยุดคิดนาน [8]

"การโจมตีเหล่านี้ทำให้เกิดความเสียหายเชิงโครงสร้าง *ทำให้การจ่ายไฟเข้าสู่โครงสร้างพื้นฐานหยุดชะงัก และในบางกรณีต้องดำเนินการดับเพลิง ซึ่งส่งผลให้เกิดความเสียหายจากน้ำเพิ่มเติม*"

⇒ และรายงานของเกาหลีระบุชัดว่า ⇒ "ความเสียหายทางกายภาพเกิดขึ้นเพราะน้ำที่ไหลเข้ามาระหว่างการดับเพลิง" [9]

⇒ นี่คือความเสียหายที่ไม่มีใครออกแบบระบบรับมือ ⇒ ระบบไฟสำรอง ป้องกันน้ำท่วม ป้องกันไฟ ⇒ ทั้งหมดออกแบบมาสำหรับ อุบัติเหตุ ไม่ใช่ อาคารถูกโจมตีจนไฟไหม้และต้องฉีดน้ำ

สอง: ทำไมเรื่องนี้สำคัญกว่าที่เป็นข่าวไอทีทั่วไป

มีหลายรายงานที่ชี้ตรงกันว่านี่คือครั้งแรก [9][8]

"นี่เป็นครั้งแรกที่ข้อมูลจากบริษัทคลาวด์ระดับโลกถูกทำลายและสูญหายจากปฏิบัติการทางทหาร" [9]

"การโจมตีเหล่านี้เชื่อว่าเป็นครั้งแรกที่สงครามทำให้ hyperscaler สัญชาติอเมริการายใหญ่หยุดชะงัก" [8]

⇒ และมันกระทบถึงการธนาคารจริง ⇒ "เหตุขัดข้องของ AWS กระทบการดำเนินงานด้านธนาคารบางส่วนในตอนนั้น" [6]

สาม: 🔴 และนี่คือบทเรียนที่คนทำเว็บและคนทำระบบควรได้

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

3.1 Multi-AZ แก้ปัญหา "ศูนย์ข้อมูลเดียวล่ม" ไม่ใช่ "หลายศูนย์ถล่มพร้อมกัน"

สถาปัตยกรรมมาตรฐานที่ทุกคนใช้คือ [1][10]

Availability Zone A  ─┐
Availability Zone B  ─┼─→  แอปทำงานต่อได้ถ้าโซนใดโซนหนึ่งล่ม
Availability Zone C  ─┘

⇒ สมมติฐานที่อยู่เบื้องหลังคือ "ความล้มเหลวจะเกิดทีละโซน" ⇒ ไม่ใช่ "การโจมตีจะมาในเวลาเดียวกันกับที่ไฟไหม้และน้ำท่วม" [1][10]

⇒ และ AWS บอกเองว่าสมมติฐานนี้ถูกทำลาย ⇒ "เกินกว่าที่บริการระดับภูมิภาคและ multi-AZ ของเราถูกออกแบบมาให้รับได้" [1][2]

⇒ ประโยคนี้คือการยอมรับว่า "multi-AZ ไม่ใช่หลักประกัน" ⇒ ซึ่งเป็นความเชื่อที่หลายองค์กรยึดถือมาตลอด [1]

3.2 สิ่งที่ยังใช้ได้ ⇒ และสิ่งที่ต้องเพิ่ม

⇒ สิ่งที่พิสูจน์แล้วว่าทำงาน: การมีข้อมูลในภูมิภาคอื่น [5][7]

AWS ช่วยลูกค้า *"สร้างการดำเนินงานขึ้นใหม่ในภูมิภาคอื่น โดยใช้ backup ที่มี หรือใช้ทางเลือกอื่นเพื่อบรรเทาผลกระทบ"* ⇒ และลูกค้าที่มี backup หรือข้อมูลจำลองในภูมิภาคอื่นมีโอกาสกู้คืนได้สูงกว่ามาก [5][7]

⇒ สิ่งที่ต้องเพิ่ม ⇒ อย่างน้อยสามข้อ

หนึ่ง ⇒ backup ต้องอยู่ต่างภูมิภาค ไม่ใช่ต่างโซน ⇒ เคสนี้พิสูจน์ว่าต่างโซนไม่พอ เพราะทั้งสามโซนอยู่ในพื้นที่เดียวกันและโดนพร้อมกัน [1][7]

สอง ⇒ ต้องทดสอบ restoration จริง ไม่ใช่ทดสอบว่า backup ทำงาน ⇒ เพราะปัญหาไม่ได้อยู่ที่ backup หาย แต่อยู่ที่ กู้คืนเข้าโครงสร้างพื้นฐานเดิมไม่ได้ [1]

สาม ⇒ ต้องรู้ว่าข้อมูลส่วนไหน "มีอยู่ที่เดียว" ⇒ ข้อมูลที่สูญหายคือข้อมูลที่ เก็บเฉพาะในโซนที่โดน ⇒ ถ้าไม่รู้ว่ามีอะไรอยู่ที่เดียว จะไม่รู้ว่าอะไรเสี่ยง [1][4]

3.3 และคำถามที่ผมคิดว่าองค์กรไทยต้องตอบ

⇒ ถ้าข้อมูลของคุณอยู่ที่เดียว และที่นั้นใช้งานไม่ได้ในทันที คุณรู้ไหมว่าต้องทำอะไรต่อ ⇒ และ ใช้เวลานานแค่ไหนถึงจะรู้ตัวว่ามันไม่กลับมา

⇒ เคสนี้ใช้เวลาหกเดือน ⇒ จาก 1 มีนาคม ถึง 15 กันยายน ⇒ ถ้าองค์กรของคุณใช้เวลาหกเดือนเพื่อค้นพบว่าข้อมูลบางส่วนกู้ไม่ได้ ⇒ นั่นคือความเสี่ยงที่ต้องประเมินตอนนี้ ไม่ใช่ตอนที่มันเกิด [1][10]

สี่: แล้วภูมิภาคนี้จะไปทางไหนต่อ

⇒ และนี่คือส่วนที่ผมคิดว่าสะท้อนทิศทางของทั้งอุตสาหกรรม [6][11]

สหรัฐอาหรับเอมิเรตส์กำลังทบทวนแผนโครงการศูนย์ข้อมูล AI ขนาดใหญ่ ⇒ โดยพิจารณา [6][11]

1. กระจายสถานที่ตั้งให้อยู่ห่างกัน  ไม่กระจุกในจุดเดียว
2. สร้างบางส่วนใต้ดิน
3. ใช้คอนกรีตที่ทนแรงระเบิด
4. ติดตั้งระบบสกัดกั้นโดรนและขีปนาวุธ

⇒ และมีรายงานว่า AWS เองก็กำลังพิจารณาแนวทางเดียวกัน [5][6]

⇒ ในขณะเดียวกัน AWS ยังไม่ให้กรอบเวลาที่ชัดเจน ⇒ ระบุว่าจะอัปเดตเรื่อง UAE "ในอีกไม่กี่เดือนข้างหน้า" และเรื่อง Bahrain "ต้นปี 2027" [1][6]

⇒ และ Tom's Hardware สรุปไว้ตรงกับที่ผมคิด ⇒ "AWS ไม่ได้ให้กรอบเวลาว่าลูกค้าจะได้สองแห่งกลับมาออนไลน์เมื่อไร" [11]

ห้า: และมุมที่ผมคิดว่าสำคัญที่สุดสำหรับคนอ่านไทย

ข่าวนี้กว้างกว่าเรื่องของตะวันออกกลาง ⇒ เพราะมันถามว่า infrastructure ที่เราฝากข้อมูลไว้ ออกแบบมารับความเสี่ยงระดับไหน

⇒ และมีตัวเลขที่ผมคิดว่าตอบคำถามนี้ได้ดี ⇒ AWS "ให้เครดิตลูกค้ามูลค่า 150 ล้านดอลลาร์" หลังการโจมตีรอบแรก ⇒ และ ยกเว้นค่าบริการทั้งเดือนมีนาคมให้ลูกค้าในภูมิภาค UAE ⇒ ซึ่งรายงานระบุว่า "การยกเว้นค่าบริการทั้งเดือนดูเหมือนไม่เคยเกิดขึ้นมาก่อน" [1][8]

⇒ ผมคิดว่าการชดเชยระดับนี้ทำให้เห็นว่า AWS เองประเมินความเสียหายไว้ว่าหนักแค่ไหน ⇒ แต่เครดิตไม่ได้คืนข้อมูล ⇒ และนั่นคือความต่างที่ต้องเข้าใจ [1][8]

และมีประเด็นด้าน compliance ที่ผมคิดว่าน่าสนใจ ⇒ มีรายงานว่าการยกเว้นค่าบริการอาจ ลบข้อมูล Cost and Usage Report ซึ่งใช้ในงาน compliance และการสอบสวนด้านความปลอดภัย ⇒ แต่ AWS ชี้แจงว่าไม่ได้ลบข้อมูลบิล ⇒ "AWS ไม่ได้ลบข้อมูลบิลของลูกค้า และข้อมูลการใช้งานสามารถขอได้" [8]

⇒ ผมยกเรื่องนี้เพราะมันแสดงว่าการชดเชยก็มีผลข้างเคียงของมันเอง ⇒ และเป็นการยืนยันจาก AWS โดยตรง [8]

หก: สรุปสิ่งที่ผมคิดว่าควรจำจากเรื่องนี้

หนึ่ง ⇒ multi-AZ ไม่ใช่หลักประกันความเสียหายหาย ⇒ มันตั้งอยู่บนสมมติฐานว่า ความล้มเหลวเกิดทีละโซน ⇒ และ AWS บอกเองว่าสมมติฐานนั้นถูกเกิน [1][2]

สอง ⇒ backup ต่างโซนไม่พอ ⇒ ต้องต่างภูมิภาค ⇒ เคสนี้คือหลักฐานตรงที่สุด [1][7]

สาม ⇒ ให้ความสำคัญกับ "ข้อมูลที่มีอยู่ที่เดียว" ⇒ เพราะข้อมูลที่หายคือข้อมูลที่ไม่ได้ย้ายและไม่ได้ทำสำเนา [1][4]

สี่ ⇒ ประเมินว่าองค์กรของคุณใช้เวลานานแค่ไหนถึงจะรู้ว่าข้อมูลกู้ไม่ได้ ⇒ เคสนี้หกเดือน [1][10]

⇒ และข้อที่ผมคิดว่าสำคัญที่สุด ⇒ ความเสียหายไม่ได้เกิดจากสิ่งที่ออกแบบมารับมือ ⇒ มันเกิดจาก น้ำที่ใช้ดับไฟ ซึ่งไม่มีใครใส่ไว้ในแผน [8][9]

ข้อควรระวัง

หนึ่ง ผมไม่ได้เป็นลูกค้า AWS ในภูมิภาคที่เกิดเหตุ ⇒ และไม่ได้ตรวจสอบระบบของ AWS เอง ⇒ บทความนี้เรียบเรียงจาก ประกาศของ AWS · รายงานของ Reuters · และสื่อเทคโนโลยีที่อ้างประกาศเดียวกัน [1][2][5]

สอง ผมอ่านประกาศของ AWS ผ่านการรายงานของสื่อ ไม่ได้อ่านหน้าประกาศต้นทางโดยตรง ⇒ เพราะ หน้า health dashboard เป็นแอปที่ต้องรัน JavaScript และเนื้อหาเหตุการณ์ไม่ได้ฝังในหน้าที่ผมดึงได้ ⇒ ผมยืนยันตัวเลขและถ้อยคำจากหลายสื่อที่อ้างตรงกัน [1][5][6]

สาม ตัวเลขเครดิต 150 ล้านดอลลาร์มาจากรายงานของ Forbes ซึ่งผมไม่ได้เปิดอ่านต้นฉบับ ⇒ อ้างผ่าน [1] ⇒ ควรตรวจสอบก่อนนำไปอ้างต่อ

สี่ ผมไม่ยืนยันสาเหตุทางทหารของเหตุการณ์ ⇒ รายงานระบุว่าเป็นการตอบโต้หลังสหรัฐและอิสราเอลโจมตีอิหร่าน ⇒ นี่คือสิ่งที่สื่อรายงาน ไม่ใช่สิ่งที่ผมตรวจสอบเอง [1][2]

ห้า จำนวนข้อมูลที่สูญหายจริงยังไม่ชัดเจน ⇒ AWS ไม่ได้ระบุว่าสูญหายกี่ไบต์ หรือกระทบลูกค้ากี่ราย ⇒ สิ่งที่ยืนยันได้คือ "กู้ไม่ได้" ในสองพื้นที่ ไม่ใช่ขนาดของความเสียหาย [1][3]

หก หน้า Reuters ต้นทางตอบ 401 เมื่อผมทดสอบ ⇒ เป็นการบล็อกบอต ไม่ใช่ลิงก์เสีย ⇒ ผมจึงอ้างผ่านสื่อที่รายงานเนื้อหาเดียวกัน [12]

เจ็ด ข้อเสนอเรื่องศูนย์ข้อมูลใต้ดินและคอนกรีตทนระเบิดเป็นแผนที่อยู่ระหว่างพิจารณา ⇒ ไม่ใช่สิ่งที่สร้างเสร็จแล้ว [6][11]

แปด ข้อความในเครื่องหมายคำพูดที่ยกมาจากแหล่งภาษาอังกฤษเป็นคำแปลของผม ไม่ใช่สำเนาต้นฉบับ ⇒ ผมคงศัพท์เทคนิคไว้เป็นภาษาอังกฤษ (Availability Zone, multi-AZ, region, me-south-1, me-central-1, mec1-az2, workload, backup, replication) เพื่อให้ตรวจเทียบกับต้นฉบับได้เอง

เก้า ผมทำงานบนระบบที่ใช้โมเดล AI และเขียนบทความนี้ด้วยความช่วยเหลือของ AI

ถ้าคุณอยากตรวจความเสี่ยงของตัวเองสัปดาห์นี้

สามข้อนี้ทำได้ในหนึ่งชั่วโมง และไม่ต้องซื้ออะไรเพิ่ม

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

สอง ⇒ เปิดรายการ backup แล้วดูว่าอยู่ภูมิภาคไหน ⇒ ถ้าทุกอันอยู่ในภูมิภาคเดียวกับต้นฉบับ ⇒ คุณยังไม่มี backup ที่รอดจากเหตุการณ์แบบนี้ [1][7]

สาม ⇒ ลองกู้คืนจริงในสภาพแวดล้อมใหม่ ⇒ ไม่ใช่กดปุ่ม backup แล้วขึ้นเขียว ⇒ แต่คือสร้างระบบใหม่จาก backup ให้ได้ในภูมิภาคอื่น ⇒ เพราะปัญหาในเคสนี้ไม่ใช่ backup หาย แต่คือ กู้เข้าโครงสร้างพื้นฐานเดิมไม่ได้ [1]

⇒ และถ้าคุณใช้บริการ cloud รายใดก็ตาม ⇒ ลองหาว่าเขาเขียนไว้ที่ไหนว่า อะไรคือความเสี่ยงที่สัญญาบริการไม่ครอบคลุม ⇒ เคสนี้คือตัวอย่างว่าระยะห่างระหว่าง "พร้อมใช้สูง" กับ "กู้ไม่ได้" สั้นกว่าที่คิด [1][2]

แหล่งอ้างอิง

[1] Hsu, J., "Iran strikes on Amazon data centers caused permanent loss of customer data" รายงานรายละเอียดการสูญหายของข้อมูล · ไทม์ไลน์การโจมตี 3 ครั้ง · เครดิต 150 ล้านดอลลาร์ · และคำยืนยันว่ายังกู้โซนอื่นอยู่, Ars Technica (16 ก.ย. 2026 / ค.ศ. 2026), https://arstechnica.com/gadgets/2026/09/iran-strikes-on-amazon-data-centers-caused-permanent-loss-of-customer-data/

[2] "Customer Data Permanently Lost in Iran Strikes on Amazon Data Centers" รายงานพร้อมถ้อยคำจากประกาศ AWS และวันที่โจมตีครั้งแรก, WIRED (17 ก.ย. 2026 / ค.ศ. 2026), https://www.wired.com/story/customer-data-permanently-lost-in-iran-strikes-on-amazon-data-centers/

[3] "AWS can't restore service to Bahrain, UAE 6 months after Iran strikes" รายงานของ CNBC ที่ระบุว่าเป็นการอัปเดตสาธารณะครั้งแรกนับจากเดือนเมษายน พร้อมแผนปรับโครงการศูนย์ข้อมูลของ UAE, CNBC (15 ก.ย. 2026 / ค.ศ. 2026), https://www.cnbc.com/2026/09/15/aws-cant-restore-service-to-bahrain-uae-6-months-after-iran-strikes.html

[4] Markovic, S., "Iranian strikes on AWS facilities left customer data beyond recovery in Bahrain, UAE" รายละเอียดรายชื่อโซน (mec1-az1, mec1-az2, mec1-az3) และชื่อภูมิภาค (me-south-1, me-central-1), Help Net Security (17 ก.ย. 2026 / ค.ศ. 2026), https://www.helpnetsecurity.com/2026/09/17/aws-middle-east-outage-permanent-data-loss-bahrain-uae

[5] "Amazon's AWS is unable to restore access to Bahrain, one UAE cloud data zone after war damage" รายงานของ Reuters ที่ยืนยันถ้อยคำ "exhausted every option" และกำหนดการอัปเดตถัดไป, เผยแพร่ผ่าน Channel NewsAsia (15 ก.ย. 2026 / ค.ศ. 2026), https://www.channelnewsasia.com/business/amazons-aws-unable-restore-access-bahrain-one-uae-cloud-data-zone-after-war-damage-6385996

[6] "Amazon's AWS Facilities in Bahrain, UAE Still Not Restored From Iran War Damage" สรุปของ Insurance Journal ที่ระบุผลกระทบต่อการธนาคาร และแผนปรับโครงสร้างของ UAE, Insurance Journal (16 ก.ย. 2026 / ค.ศ. 2026), https://www.insurancejournal.com/news/international/2026/09/16/885283.htm

[7] "AWS Says Some Data in Bahrain and UAE Cloud Sites Cannot Be Recovered After War Damage" รายงานที่อธิบายว่าโครงสร้าง AWS ปกติออกแบบให้รอดการล่มของโซนเดียว ไม่ใช่การโจมตีหลายแห่งพร้อมกัน, Agentic Tribune (ค.ศ. 2026), https://agentictribune.com/article/20260917-aws-says-some-data-in-bahrain-and-uae-cloud-sites-cannot-be-recovered-after-war-damage

[8] "Amazon waives entire month's AWS charges after Iranian drone attack" รายงานการยกเว้นค่าบริการเดือนมีนาคม พร้อมถ้อยคำจาก AWS เรื่องข้อมูลบิล และผลกระทบต่อ EC2, S3, DynamoDB, Lambda, Kinesis, CloudWatch, RDS, Network World (ค.ศ. 2026), https://www.networkworld.com/article/4151880/amazon-waives-entire-months-aws-charges-after-iranian-drone-attack.html

[9] "Iran drone strikes corrupt AWS Gulf data, upend region's cloud ambitions" รายงานที่ระบุว่าเป็นครั้งแรกที่ข้อมูลของบริษัทคลาวด์ระดับโลกถูกทำลายจากปฏิบัติการทางทหาร และระบุความเสียหายจากน้ำดับเพลิง, ChosunBiz (16 ก.ย. 2026 / ค.ศ. 2026), https://biz.chosun.com/en/en-it/2026/09/16/CL3P7XIWBREGFLW4JAM4CLYDGA/

[10] "AWS Availability Zones" และ "Availability Zones" (เอกสารทางวิศวกรรมของ AWS ที่อธิบายสถาปัตยกรรม AZ และสมมติฐานการแยกความล้มเหลว), Amazon Web Services (ค.ศ. 2026), https://docs.aws.amazon.com/global-infrastructure/latest/regions/aws-availability-zones.html · https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/availability-zones.html

[11] "AWS tells clients to abandon Middle East data centers six months after Iranian drone strikes" ระบุว่า AWS ไม่ให้กรอบเวลาการกลับมาออนไลน์ และ UAE พิจารณาศูนย์ข้อมูลใต้ดิน, Tom's Hardware (ค.ศ. 2026), https://www.tomshardware.com/tech-industry/data-centers/amazon-reportedly-tells-customers-in-abu-dhabi-and-bahrain-to-find-safer-harbors-for-their-data-aws-has-no-timeline-for-resuming-operations-six-months-after-drone-strikes-damaged-data-centers-in-the-region

[12] "Amazon's AWS is unable to restore access to Bahrain, one UAE cloud data zone after war damage" หน้าต้นทางของ Reuters ซึ่งตอบ 401 เมื่อผมทดสอบ (เป็นการบล็อกบอต) ⇒ อ้างผ่าน [5], Reuters (15 ก.ย. 2026 / ค.ศ. 2026), https://www.reuters.com/world/middle-east/amazons-aws-is-unable-restore-access-bahrain-one-uae-cloud-data-zone-after-war-2026-09-15