AWS потеряла данные клиентов. Что этот инцидент говорит о DR и резервном копировании

В сентябре 2026 года AWS признала, что не сможет восстановить часть данных и ресурсов клиентов в Бахрейне и ОАЭ после физического повреждения дата-центров в ходе военного конфликта на Ближнем Востоке.

Случай примечательный: речь не об атаке шифровальщика, программном сбое или ошибке администратора. В результате серии атак БПЛА и ракет было физически повреждено несколько площадок облачного провайдера.

Первоначально в марте 2026 от ударов иранских БПЛА пострадали ЦОДы AWS в ОАЭ и Бахрейне. В ОАЭ два объекта получили прямые попадания. В Бахрейне БПЛА ударил рядом с ЦОД, в результате чего он получил «структурные повреждения и проблемы с электропитанием». В апреле новый иранский удар вывел из строя вторую Availability Zone в Бахрейне. Позднее, в июле, КСИР заявил об очередной атаке на оставшуюся инфраструктуру AWS в Бахрейне с применением крылатых ракет.

Масштаб события превысил то, на что рассчитаны обычные региональные механизмы отказоустойчивости AWS. Сама AWS сформулировала это достаточно прямо:

Именно эта фраза, пожалуй, лучше всего объясняет смысл произошедшего.

Multi-AZ — это ещё не Disaster Recovery

Регион AWS состоит из нескольких зон доступности (Availability Zones, AZ). Размещение системы в нескольких AZ позволяет пережить отказ отдельного дата-центра или другой локальный инцидент. Но все эти зоны всё равно находятся внутри одного региона.

High Availability: AZ-1 ⇄ AZ-2 ⇄ AZ-3

помогает пережить отказ одной площадки. Но для сценария потери целого региона нужна уже другая архитектура:

Disaster Recovery: Region A → Region B

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

Репликация — тоже не панацея

На этом месте легко сделать другой вывод: достаточно было реплицировать всё в соседний AWS Region. Для доступности — во многих случаях да.

Но репликация сама по себе не отменяет необходимости в резервном копировании. Ошибочное удаление, повреждение данных или действия злоумышленника могут успешно реплицироваться вместе с рабочей системой.

Поэтому имеет смысл разделять три задачи:

Multi-AZ — высокая доступность.

Multi-Region — восстановление после потери региона.

Backup — возможность вернуться к корректному состоянию данных.

Это разные механизмы, и наличие одного не отменяет потребность в остальных.

Интересный факт — у клиентов было время спастись

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

Получилась примерно такая последовательность:

повреждение AZ → предупреждение → миграция части клиентов → новое повреждение → потеря региона

И это уже вопрос не только архитектуры, но и планирования. Хороший DR-план должен отвечать не только на вопрос «как восстановиться после аварии?», но и на вопрос «когда начинать восстановление?»

Извлеченные уроки

Если вы пользуетесь услугами классического облачного провайдера, с регионами и зонами доступности, пройдитесь по короткому чек-листу:

Если вы уже продумывали сценарий защиты от атаки шифровальщика, то многие вопросы покажутся вам знакомыми, а ответы (надеюсь) — будут очевидны.