Сбой AWS на Ближнем Востоке перешел из категории «подождем восстановления» в более неприятную: часть ресурсов и данных компания восстановить не сможет. По данным The Register, повреждения после иранских ударов затронули несколько зон доступности в Бахрейне и одну Availability Zone в ОАЭ, а региональная отказоустойчивость оказалась слабее военной реальности.
Речь идет прежде всего о регионе Bahrain Region, он же me-south-1. AWS сообщила в AWS Health Dashboard, что ресурсы и данные, размещенные исключительно в этом регионе, остаются недоступными. После оценки инфраструктуры компания пришла к выводу, что вернуть доступ к ним не получится: повреждения затронули несколько Availability Zones и превысили сценарии, на которые рассчитаны региональные и multi-AZ-сервисы.
Хронология выглядит жестко. Первая зона доступности в Бахрейне была повреждена в марте 2026 года. Тогда AWS рекомендовала клиентам переносить нагрузки в другие регионы. По словам компании, большинство клиентов успели это сделать до новых атак в апреле, после которых была нарушена работа второй зоны доступности, а весь регион me-south-1 стал недоступен.
Похожая, но не идентичная ситуация сложилась в регионе ОАЭ. AWS признала, что не сможет восстановить доступ к ресурсам и данным в зоне mec1-az2. Это одна из трех Availability Zones в UAE Region. В марте два объекта AWS в стране были повреждены дронами на фоне ответных ударов Ирана после американо-израильских атак по его территории. При этом AWS продолжает восстановление отдельных ресурсов в регионе, включая то, что связано с mec1-az1 и mec1-az3.
Для тех, кто строил архитектуру по классической схеме «раскидаем сервисы по нескольким зонам внутри одного региона», это неприятное напоминание о границах модели. В терминологии AWS регион состоит из нескольких изолированных зон доступности, а каждая зона включает один или несколько дата-центров с отдельным питанием, охлаждением и сетевой связностью. Multi-AZ помогает пережить потерю одной площадки. Но если проблема накрывает регион шире, нужна уже межрегиональная стратегия восстановления.
Именно это AWS рекомендовала клиентам после первых ударов: включать disaster recovery, восстанавливаться из удаленных бэкапов в других регионах и перенаправлять трафик из пострадавших локаций. В качестве практического направления тогда назывались альтернативные регионы, в том числе в Европе. Теперь этот совет выглядит не перестраховкой юристов и архитекторов, а довольно трезвой инструкцией по выживанию.
Для разработчиков и платформенных команд главный вывод простой: сбой AWS такого масштаба нельзя закрыть галочкой «у нас Multi-AZ». Если критичные данные жили только в одном регионе, даже у крупнейшего облачного провайдера нет магической кнопки отката после физического разрушения инфраструктуры. Нужны проверенные бэкапы за пределами региона, понятные RTO и RPO, регулярные учения, автоматизация восстановления и честный список систем, которые бизнес действительно не готов потерять.
Для бизнеса это еще и вопрос закупок. Многие компании привыкли обсуждать облачную устойчивость через SLA, стоимость инстансов и задержку до пользователей. Теперь в повестку снова возвращаются более скучные, но дорогие вопросы: где лежат резервные копии, кто имеет право запустить восстановление, сколько стоит простой региона и выдержит ли бюджет постоянную репликацию в другую географию. В мирное время такие обсуждения часто проигрывают фичам. В военное — становятся разницей между паузой и потерей данных.
Рынок в этой истории пока реагирует не пресс-релизами, а архитектурными выводами. AWS отказалась добавлять комментарии сверх данных в Health Dashboard, а клиенты, судя по сообщению компании, в основном пытались поднять операции в других регионах через бэкапы или доступные копии данных. Это не красивый кейс про бесшовную отказоустойчивость, а редкий публичный пример того, что облако тоже состоит из железа, зданий, кабелей и географии.
Сбой AWS на Ближнем Востоке вряд ли заставит компании массово уходить из публичных облаков. Скорее он поднимет цену самообмана: если приложение «критичное», но его DR-план существует только в презентации, следующий региональный инцидент быстро отделит архитектуру от слайдов. Вопрос уже не в том, бывает ли потеря облачного региона, а в том, сколько команд готовы признать такой сценарий нормальной частью проектирования.