Кратко

  • AWS относит плоскости управления IAM, Route 53 и CloudFront к us-east-1 и предупреждает: восстановление, опирающееся на операции создания, обновления, удаления или перечисления, может не сработать, пока этот регион деградирован.
  • При той же деградации Route 53 продолжает разрешать имена и выполнять проверки работоспособности: заранее настроенное переключение выдерживает, переключение через правку записей — нет.

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

AWS публикует этот список. Технический документ о границах изоляции отказов помещает плоскости управления IAM, Route 53 и CloudFront в us-east-1 для коммерческого раздела, напоминая при этом, что их плоскости данных распределены. Формулировка прямая: «These service operations have a cross-Region control plane dependency.» (AWS Fault Isolation Boundaries: global services)

Это не признание слабой надёжности, а описание того, где исполняется класс действий. Для совета директоров вопрос не в том, надёжен ли us-east-1. Вопрос в том, требует ли план переживания плохого дня в us-east-1 операции, которая исполняется в us-east-1.

Проверки работоспособности переживают сбой. Инструкции по восстановлению — обычно нет.

Та же серия документов необычно чётко делит переключение DNS на две половины. Разрешение имён, выполнение проверок работоспособности и изменения маршрутизации по их результатам относятся к плоскости данных Route 53. А вот правка записей, изменение весов и создание новых записей: «These approaches depend on the Route 53 control plane.» (Partitional services best practices)

То есть самая распространённая схема переключения конструктивно зависит от плоскости управления. Инструкция, которая при деградации региона перезаписывает CNAME, функционально равна бегству от сломанного при помощи сломанного. Уже настроенная проверка работоспособности переводит трафик без чьего-либо редактирования: первая работает во время сбоя, вторая — только после него.

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

В учётных данных важнее деталь, а не заголовок.

«AWS STS will process your request based on the originating Region and DNS resolver used.» Запросы из региона, включённого по умолчанию и разрешённого через DNS-сервер Amazon, могут обслуживаться на месте; запросы из регионов, подключаемых по выбору, или через сторонний DNS-провайдер по-прежнему обслуживаются в us-east-1 (AWS STS Regions and endpoints). Глобальное доменное имя не даёт обратного вывода: решают только поля CloudTrail о типе эндпоинта и регионе обслуживания.

Переключение убивает не отказ сервиса, а замкнутая зависимость.

В сентябре 2026 года команда архитекторов AWS опубликовала разбор полезнее большинства отчётов об инцидентах. При проверке межрегионального восстановления после катастрофы для Terraform Enterprise авторы обнаружили, что скрипты переключения за пределами основного региона всё ещё требовали идентификаторов из файлов состояния в S3 этого региона. Блокировка связи с S3 валила скрипты: путь восстановления зависел от того самого объекта, который восстанавливали (Validating multi-Region DR for Terraform Enterprise with AWS FIS).

Их исправление укладывается в строку: «Remove recovery dependencies on the Region you are recovering from.» Обращения к состоянию во время выполнения заменены заранее настроенным переключением DNS, и восстановление больше не читает из пострадавшего региона в момент, когда это нужнее всего.

Как выглядит отчёт заказчика, когда зависимость реальна.

Отчёт Coinbase об инциденте 7 мая 2026 года превращает абстракцию в конкретный случай. Три из пяти узлов движка сопоставления оказались в одной группе размещения; когда зона доступности отказала, кворум исчез вместе с ней. «There was no automated cross-zone failover.» Кроме того, дефект плоскости управления управляемого Kafka не дал переизбрать лидеров разделов, затронув кластеры как с двумя, так и с тремя зонами, и отказ распространился по зависимостям расчёта комиссий и котирования (Coinbase, 7 мая 2026).

Документ не допускает двух удобных прочтений. Он не доказывает отказа региональной изоляции: событие зоны, решение о концентрации на уровне приложения и дефект управляемого сервиса не равны падению всей Виргинии. И он не позволяет свалить всю ответственность на заказчика, потому что Coinbase относит часть длительности к дефекту сервиса. Оба факта должны стоять в одном абзаце; совет директоров обычно получает только успокаивающий.

Выход существует. И это опция.

AWS описывает и путь восстановления самой плоскости управления: для публичных хостед-зон есть ускоренное восстановление через us-west-2 с целевым ориентиром около 60 минут после обнаружения деградации в us-east-1. Главное — ограничения. «Accelerated recovery is available only for public hosted zones.» Включать нужно до сбоя, частные хостед-зоны не покрываются, а во время переключения доступна лишь часть операций API (Enabling accelerated recovery for managed public hosted zones). Создание и удаление хостед-зон остаются недоступными.

Здесь в одном абзаце и честность оператора, и его граница. Выход есть, порядок и момент включения названы. Но он не по умолчанию: он существует только у тех, кто закупил и настроил его заранее.

Как это читают третьи стороны и где предел такого чтения.

Control Plane доказывает, что операции идентификации, DNS, мониторинга и восстановления сохраняют общие зависимости, и пишет: «It doesn’t cover failures in layers every region shares.» (Control Plane, 12 октября 2026). CloudForge требует картировать зависимости восстановления шире, чем сервисы, которые приложение вызывает напрямую, и заключает: «Recovery that needs new resources is the riskiest recovery.» (CloudForge, 8 октября 2026). Оба текста — архитектурная интерпретация, а не внутренние наблюдения провайдера; CloudForge прямо сообщает об исследовании и письме с помощью ИИ.

Есть три предела. Во-первых, это исследование не установило нормированного по охвату сравнения, показывающего, что в 2026 году us-east-1 был менее надёжен, чем другие регионы AWS. Во-вторых, год публикации не равен году инцидента: аналитика 2026 года обсуждает сбой AWS в октябре 2025 года, а собственная запись оператора об этом событии в этом исследовании не открывалась, поэтому механизм, длительность и масштаб здесь не утверждаются. В-третьих, независимая публикация не является независимым операционным доказательством: интерпретации консультантов, заявления поставщиков и отчёты клиентов сохраняют свою атрибуцию.

Связанная запись справочника: Amazon.com, Inc..