Сбой AWS в Бахрейне: почему multi-AZ — по-прежнему один домен отказа

К 16 марта самым надёжным публичным источником о проблемах AWS на Ближнем Востоке оставалась собственная лента статусов AWS, а не громкие пересказы, выстроенные поверх неё.

Того, что AWS подтвердила публично, было уже достаточно. В начале марта её ближневосточные регионы пережили затяжную аварию, затронувшую и me-south-1 в Бахрейне, и me-central-1 в ОАЭ. AWS рекомендовала клиентам вводить в действие планы аварийного восстановления, восстанавливаться из удалённых резервных копий и при необходимости переносить нагрузки в другие регионы. 1

Это и есть полезная часть истории. Многие публикации о сбоях быстро скатываются в выдуманную точность: точное число сервисов, точная последовательность восстановления, точная первопричина — ещё до того, как выйдет публичный разбор. На дату этой статьи устойчивый вывод был проще. Регион остаётся общей границей устойчивости, даже если внутри него несколько зон доступности.

Что AWS подтвердила публично

В собственных сводках AWS описала исходную локальную проблему с электропитанием в одной зоне доступности в Бахрейне 1 марта — mes1-az2, — которая вызвала проблемы со связностью, ошибки API и деградацию сервисов для ресурсов в этой зоне. К 2 марта AWS сообщала клиентам, что восстановление займёт не меньше суток, и рекомендовала запускать замещающие ресурсы в незатронутых зонах или в другом регионе. 1

В ОАЭ отказ был другого класса. 2 марта AWS сообщила, что две зоны доступности в me-central-1 существенно повреждены и что и регион ОАЭ, и регион Бахрейна пострадали физически — из-за продолжающегося конфликта на Ближнем Востоке. В публичном уведомлении AWS говорилось, что два объекта в ОАЭ были поражены напрямую, а удар рядом с одним из объектов в Бахрейне также привёл к повреждению инфраструктуры, отключению питания и, в отдельных случаях, к срабатыванию систем пожаротушения и ущербу от воды. 1

К 3 марта AWS заявила, что перейдёт к адресным уведомлениям через Personal Health Dashboard для затронутых клиентов. То есть публичных данных хватало, чтобы понять характер отказа, но не хватало на уверенный рассказ о каждой минуте и каждом сервисе. 1

Multi-AZ — это не аварийное восстановление

Собственная страница AWS об инфраструктуре ясно объясняет, что такое регион и зона доступности. Регион — это физическая локация, содержащая несколько изолированных, физически разнесённых зон доступности. У каждой зоны собственные питание, охлаждение и физическая безопасность, и приложения, разнесённые по зонам, лучше защищены от обычных отказов масштаба дата-центра. 2

Это настоящая устойчивость, но она не равна независимости от физических или политических событий, охватывающих регион целиком. Если проблема выходит за пределы отдельных объектов — питание, безопасность, доступ, конфликт, — одно и то же событие способно затронуть сразу несколько зон. Мартовский региональный сбой AWS напоминает: высокая доступность внутри одного провайдера — не то же самое, что аварийное восстановление за его пределами.

То же различие проводит и Well-Architected Framework самой AWS. Для нагрузок, которым нужны более серьёзные гарантии доступности, на сцену выходит мультирегиональная архитектура. Размещение в нескольких зонах доступности повышает устойчивость ко многим инфраструктурным отказам внутри региона. Защита от потери региона целиком требует мультирегиональной стратегии аварийного восстановления. 3

Три вещи, снижающие коррелированный отказ

Снизить этот риск помогают три архитектурных решения.

Другая физическая география — то есть другая страна в другой энергосети, до которой идёт другое волокно, а не другая зона доступности в той же агломерации.

Другая юрисдикция — потому что сбой очень быстро перестаёт быть проблемой железа.

Другой провайдер — потому что если основная и резервная площадки приходят в одном счёте, у них общий control plane, общая служба поддержки и общая политика блокировки аккаунта.

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

Четыре страны, четыре энергосети

Мы — распределённая сеть, а не один большой кампус. У AVS ISP площадки в Тиране, Скопье, Амстердаме и Дублине: четыре страны, четыре регуляторные среды, четыре независимые среды по питанию и волокну.

На практике это важно по одной простой причине. Клиент, у которого VPS за 5 €/мес. в Амстердаме и второй в Тиране, получает настоящее географическое и юрисдикционное разнесение по цене обеда навынос. Чтобы купить независимость, не нужен корпоративный договор на 50 000 €. Нужны две системы, которые вряд ли откажут по одной и той же причине.

Клиентам, которые ведут собственную маршрутизацию, мы предоставляем AS210464 с проверкой RPKI и полным набором BGP-сообществ, так что вы управляете тем, откуда анонсируются ваши префиксы, — включая выборочный анонс по региону и по типу пира, а также blackhole по удалённому запросу, когда он нужен.

Хотите посмотреть на сеть, прежде чем ей довериться, — наш looking glass выполняет ping, traceroute и BGP-запросы вживую с каждой нашей площадки. Без регистрации и без звонка менеджера.

Мы тоже не застрахованы

Мы не станем утверждать, что европейская сеть из четырёх площадок застрахована от того, что случилось с AWS в марте. Ни одна не застрахована. Риск концентрации — это шкала, а не выключатель, и аплинки с точками стыка у нас общие со всеми, кто работает в Европе.

Скажем другое: самая дешёвая страховка в хостинге остаётся самой старой — разместите вторую нагрузку или резервную копию там, где она не может отказать по той же причине, что и первая. На практике это по-прежнему один из простейших способов повысить устойчивость.

Хотите проверить это с нами — поднимите VPS во второй стране и посмотрите, во что это обойдётся. Принимаем криптовалюту, не просим KYC, и запуститься можно за считаные минуты.

Источники

1. AWS Service Status RSS Feed, сводки AWS по me-south-1 и me-central-1 за 1–3 марта 2026 года
2. AWS Regions and Availability Zones, Amazon Web Services
3. AWS Well-Architected Framework – Disaster Recovery Strategy, Amazon Web Services