AWS Bahrain: что региональный сбой говорит об устойчивости облаков

AWS столкнулась со сбоем в своём облачном регионе в Бахрейне из-за активности дронов поблизости, что подчёркивает уязвимость дата-центров перед геополитическими и физическими рисками. Инцидент подтверждает растущую важность учёта внешних угроз при обеспечении надёжности и безопасности цифровой инфраструктуры.

• 24 марта 2026 года Amazon сообщила, что работа региона AWS Middle East (Bahrain),me-south-1, была нарушена конфликтом, и что компания помогает клиентам перенести рабочие нагрузки в другие регионы.
• В этом уведомлении не были указаны затронутые сервисы, точное время начала, зона доступности, детальная физическая причина или предполагаемый срок восстановления для нового инцидента.

Два отдельных мартовских инцидента

Хронология имеет значение. В первом инциденте, 1 марта, AWS сообщила о физических последствиях удара дрона вблизи объекта в Бахрейне. В обновлениях о состоянии, о которых сообщалоAssociated Press, Бахрейн, затронутый инцидентом поблизости, был отделён от двух объектов в ОАЭ, которые были поражены напрямую. В открытых данных по Бахрейну указывалась потеря электропитания в зоне доступностиmes1-az2регионаME-SOUTH-1.

Данная статья посвящена второму инциденту. Вечером 23 марта, а затем в сообщении от24 марта, Amazon заявила, что регион в Бахрейне был «нарушен» конфликтом.Reutersсообщило, что представитель компании связал это с активностью дронов в этом районе, но Amazon не заявляла, что объект был поражён, не описала ущерб и не назвала ожидаемую продолжительность. Фразу «активность дронов в этом районе» нельзя переписывать как подтверждение прямого попадания или как простое превентивное отключение.

Что публичный статус показал — и чего он не показал

Amazon подтвердила влияние на уровне региона и попросила клиентов с рабочими нагрузками в затронутых регионах продолжать их переносить. Компания заявила, что поддерживает миграции и что многие приложения уже работают в других местах. Однако в публичном уведомлении об инциденте 23–24 марта не было проверяемого перечня сервисов EC2, S3, RDS, Lambda или других, точного времени начала, числа недоступных зон или срока восстановления.

Эти пробелы — часть официальной картины. Клиенты могли получать уведомления по конкретным ресурсам в Personal Health Dashboard, но частные уведомления не позволяют составить единый публичный список сервисов. Сервисы, связанные с событиями 1 марта или с регионом в ОАЭ, нельзя переносить на этот новый инцидент в Бахрейне. Корректная формулировка — «региональный сбой с рекомендацией миграции», а не «все сервисы AWS отказали».

Регион — это не зона доступности и не всё облако

AWS открыла регион в Бахрейне в 2019 году. Регион содержит несколько зон доступности; сам по себе он не является «зоной доступности». Зоны доступности изолируют локальные сбои, но остаются в пределах одной географической области. Физическая угроза или операционное решение, затрагивающее общие региональные зависимости, может выйти за рамки модели отказа одной зоны.

Ни один из приведённых источников не свидетельствует о глобальном сбое AWS. Amazon направила клиентов в другие регионы, что указывает на доступность альтернативных регионов для восстановления. Фактическое влияние зависело от рабочих нагрузок вme-south-1, их региональных зависимостей, репликации данных и способности клиента выполнить аварийное переключение.

Multi-AZ — это не план восстановления между регионами

В документе AWSReliability Pillarрекомендуется распределение по зонам доступности, а там, где этого требует риск, — и по регионам. Multi-AZ может выдержать отказ одной зоны только тогда, когда компоненты, данные, квоты и сетевые пути действительно избыточны. Такая схема не гарантирует непрерывность, если регион становится непригодным или нарушается работа региональной плоскости управления.

Восстановление между регионами не происходит автоматически. VPC, вычислительные ресурсы, секреты, ключи, образы, данные и зависимости должны существовать в регионе восстановления. Команды должны выбрать RTO и RPO, реплицировать данные в эти целевые регионы, зарезервировать мощности и квоты, автоматизировать переключение трафика, протестировать аварийное переключение и возврат в основной регион, а также хранить восстановимые резервные копии за пределами основного региона.

Практическая проверка

Надёжный план отвечает на конкретные вопросы: какие функции можно остановить; какой объём данных допустимо потерять; кто объявляет аварию; как переносятся идентификация, DNS, сертификаты и очереди; какую задержку поддерживает площадка восстановления; и как соблюдаются требования к месту хранения данных. Требование о локализации данных может ограничить выбор региона восстановления, но не заменяет анализ непрерывности.

Команды должны сверять три источника: публичный Service Health Dashboard, уведомления Personal Health Dashboard для конкретного аккаунта и собственную телеметрию. Им следует избегать частичного аварийного переключения, при котором приложение переносится, но по-прежнему зависит от базы данных, ключа KMS, провайдера идентификации или канала Direct Connect, оставшихся в Бахрейне.

Что доказывает этот инцидент

Он доказывает, что один регион AWS подвергся сбою во время конфликта и что Amazon рекомендовала миграцию. Он не доказывает глобального отказа облака, отказа каждого сервиса, наличия срока восстановления или автоматического отказа любой архитектуры Multi-AZ. Полезный вывод более узкий: архитектурная устойчивость существует только тогда, когда зависимости, данные и процесс аварийного переключения подготовлены и проверены за пределами затронутого региона.