Мрачным утром 20 октября 2025 года мониторинг AWS был краснее некуда, его залило кровью сервисов. Пал крупнейший и по совместительству старейший регион, обрабатывающий 35–40% всего глобального трафика AWS — US-EAST-1. На его воскрешение чернокнижники из AWS потратили 13 часов.

В этой статье я хочу разобрать, что именно произошло, почему восстановление заняло так много времени, и самое главное — что мы можем сделать, чтобы наши системы пережили подобное в будущем. Ведь US-EAST-1 падает уже не первый раз, и явно не последний.

Что произошло?

20 октября 2025 года в 12:11 PDT (это 03:11 по времени Восточного побережья США) системы мониторинга AWS зафиксировали первые проблемы. Начало было незаметным: отказал health check-мониторинг сетевых балансировщиков нагрузки (Network Load Balancers). На первый взгляд не так и страшно, но на деле всё оказалось не очень радужно. Этот мониторинг начал генерировать некорректные оценки работоспособности, что запустило каскадный эффект:

1. 12:11 PDT — Затронуто 14 сервисов, в основном проблемы с балансировщиками.

2. 14:01 PDT — AWS идентифицировала проблему DNS: запросы к dynamodb.us-east-1.amazonaws.com перестали разрешаться.

3. 14:24 PDT — AWS объявила в статусе: «DNS полностью устранён».

Наши чернокнижники думали, что, залатав раны, они воскресили регион, но яд просочился очень глубоко: EC2-инстансы не запускались, Lambda-функции падали, DynamoDB был полностью недоступен, CloudWatch не показывал метрики. Даже собственные инструменты AWS — Support Center, Health Dashboard, Management Console — работали с перебоями или не работали вовсе.

В итоге яд распространился по следующему пайплайну:

Health Check Monitoring (NLB)    
  ↓
DNS Resolution для DynamoDB   
  ↓
DynamoDB Control Plane    
  ↓
┌── EC2 (метаданные инстансов)
├── Lambda (конфигурация функций)
├── SQS (очереди)
├── CloudWatch (логи и метрики)
└── 70+ других сервисов

20:04 PDT (спустя 8 часов после начала) — AWS наконец-то нашла настоящую первопричину: отказ подсистемы health check-балансировщиков. Но знание причины ещё не означало быстрого решения.

22:30 PDT (через 10+ часов) — большинство сервисов начали восстанавливаться. Полное восстановление для некоторых сервисов заняло до 13 часов.

Почему так долго?

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

Каскадные зависимости

Допустим, у вас есть микросервисная архитектура из 70+ сервисов, где каждый зависит от нескольких других. DynamoDB — это не просто база данных. Это:

• хранилище метаданных для EC2;

• бэкенд конфигурации для Lambda;

• состояние для CloudWatch;

• и десятки других критических ролей.

Когда DynamoDB падает, нельзя просто его включить обратно. Нужно восстанавливать сервисы точно так же каскадно, снизу вверх. Сначала DNS, потом DynamoDB control plane, потом зависимые сервисы.

Накопленные долги

За 8–10 часов простоя накопилось бесчисленное количество отложенных запросов:

• запросы на запуск EC2-инстансов;

• lambda invocations в очереди;

• CloudWatch-метрики для записи;

• API-вызовы, ожидающие обработки.

Представьте, что вы пришли в понедельник на работу, открыли Jira и получили несколько тысяч задач. Тяжёлое начало недели, не правда ли? Вот и когда сервисы начали оживать, они столкнулись с огромной очередью задач. AWS пришлось аккуратно ограничивать скорость обработки, чтобы не перегрузить только что восстановленные системы.

Масштаб US-EAST-1

Этот регион огромен. Он сильнейший и важнейший боец AWS. Он включает:

• тысячи стоек серверов;

• петабайты данных;

• миллионы customer workloads;

• собственную инфраструктуру AWS.

Когда такие великие герои падают, их быстро не оживить.

Список жертв

Наш великий регион пал, и все, кто был под его покровительством, остались без защиты. Более 1000 компаний пострадали от этого инцидента. От малых стартапов до публичных корпораций. Вот только несколько примеров:

Финтех:

• Coinbase — торговля криптовалютой остановлена, пользователи не могли выводить средства;

• Robinhood — невозможно совершать сделки на бирже;

• Venmo — платежи не проходили

• несколько банков Великобритании — проблемы с онлайн-банкингом.

Игровая индустрия:

• Fortnite — игроки не могли подключиться к серверам;

• Roblox — платформа недоступна для миллионов детей;

• Pokémon GO — проблемы с авторизацией.

Другие:

• United Airlines — задержки в системах бронирования;

• UK Gov.uk — сервисы правительства Великобритании были полностью недоступны;

• Snapchat, Signal — проблемы с мессенджерами;

• собственные сервисы Amazon (не AWS!) — проблемы с заказами.

По оценкам, бизнес-потери составили сотни миллионов долларов. Надеюсь, это не станет причиной увеличения подати.

SLA и реальность

Герой обещал, что для EC2 SLA 99.99%. Давайте посчитаем, что это означает:

99.99% uptime = 0.01% допустимого простоя
В месяц (43,200 минут): 43,200 × 0.0001 = 4.32 минуты

Этот инцидент длился 10–13 часов = 600–780 минут. Это превышение SLA примерно в 139–180 раз.

Но вот что интересно: согласно AWS Service Level Agreement, при нарушении SLA вы получаете сервисные кредиты:

Звучит неплохо? Давайте посчитаем реальность:

# Ваш месячный счёт AWS
monthly_bill = 10000  # $10k
# Берём 100% кредит
credit = monthly_bill * 1.0  # $10k
# Ваши реальные потери от простоя
# (для ecommerce при $100000 дневной выручки)
actual_losses = 100000 * (13/24)  # $54k
# Компенсация покрывает
coverage = credit / actual_losses * 100  # 18%

AWS выдаст вам 10k кредитов на будущее использование в рамках их системы, когда Вы потеряли 54k реальной выручки.

Cнова US-EAST-1

Вот, что действительно пугает. Это не первый раз, когда US-EAST-1 пал и заставил понервничать множество храбрых воинов, стоящих на страже своих сервисов:

• ноябрь 2020: Kinesis, 5+ часов простоя;

• сентябрь 2021: EBS I/O деградация, 8 часов

• декабрь 2021: Сетевые устройства, несколько часов;

• июль 2024: Kinesis Data Streams, 7 часов;

• октябрь 2025: DNS/балансировщики, 10–13 часов.

Все эти инциденты объединяет одно: US-EAST-1. И тут уже напрашивается вывод: это не изолированные инциденты, это система.

Почему именно этот регион?

1. Самый старый — запущен в 2006, legacy-инфраструктура.

2. Самый большой — 35–40% глобального трафика AWS.

3. Самые сложные зависимости — многие внутренние сервисы AWS привязаны к нему.

4. Default-регион — миллионы приложений используют его по умолчанию.

Чему мы научились?

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

Урок #1: мониторинг систем — это критическая инфраструктура

Ирония ситуации в том, что проблема началась с системы мониторинга. Health check для балансировщиков (казалось бы, вспомогательный компонент) превратился в точку отказа.

Присмотритесь к своей тоже, вдруг она что-то замышляет ? Если ваш Prometheus упадёт, смогут ли ваши сервисы работать? Если Grafana недоступна, начнётся ли каскадный отказ? Нужен independent, external-мониторинг основных систем.

Используйте внешний мониторинг (Datadog, New Relic, Pingdom). Не полагайтесь только на CloudWatch — как мы видели, он тоже может упасть.

Урок #2: DNS — недооценённая зависимость

DNS настолько фундаментален, что инженеры часто думают: «DNS просто работает». До тех пор, пока не перестаёт.

В этом инциденте проблема DNS для dynamodb.us-east-1.amazonaws.com была идентифицирована через 2 часа, но полностью была решена только через 8 часов.

Советы:

• Внедрите мониторинг DNS на критичных эндпоинтах.

• Используйте кэширование DNS с правильными TTL.

Урок #3: Multi-AZ недостаточно для критичных систем

Multi-AZ архитектура звучит хорошо и надёжно, но иногда и величайшие могут дать слабину. У вас инстансы в us-east-1a, us-east-1b, us-east-1c — отлично защищены от падения одного дата-центра! Но весь регион упал, и Multi-AZ не спасла никого.

Давайте разберём стратегии мультирегиональной архитектуры на примере псевдокода:

Active-Active

# Оба региона работают одновременно
routing:  dns: Route53  policy: latency-based  # Ближайший регион к пользователю  health_checks: enabled
regions:  us-west-2:    instances: 10 × m5.xlarge    database: DynamoDB Global Table    traffic: 50%    eu-west-1:    instances: 10 × m5.xlarge    database: DynamoDB Global Table (реплика)    traffic: 50%
data_sync:  method: continuous replication  lag: < 1 second

Преимущества:

• оба региона обрабатывают трафик постоянно;

• RTO (Recovery Time Objective) — секунды;

• RPO (Recovery Point Objective) — секунды.

Недостатки:

• двойная стоимость инфраструктуры;

• сложность с консистентностью данных (eventual consistency);

• нужна синхронизация сессий пользователей.

Active-Passive

# Primary работает, DR готов к переключению
routing:  dns: Route53  policy: failover  primary: us-east-1  secondary: us-west-2 (активируется при сбое)
primary_region:  instances: 20 × m5.xlarge  database: RDS Primary  traffic: 100%
dr_region:  instances: 2 × t3.small (минимум)  database: RDS Read Replica  traffic: 0% (до failover)  auto_scaling: 2 → 20 (при активации)

Преимущества:

• умеренная стоимость (30–50% от active-active);

• RTO (Recovery Time Objective) — 15–30 минут;

• RPO (Recovery Point Objective) — 15 минут.

Недостатки:

• требует ручного или semi-automated переключения;

• риск, что DR-инфраструктура не протестирована.

Pilot Light

# Только критичные данные реплицируются, compute разворачивается по требованию
routing:  dns: Route53  policy: manual failover  default: us-east-1
primary_region:  instances: 20 × m5.xlarge  database: RDS Primary  storage: S3 с cross-region replication  traffic: 100%
dr_region:  instances: 0 (разворачиваются из AMI/Terraform при сбое)  database: RDS snapshots (автоматические каждые 6 часов)  storage: S3 replica (постоянно синхронизируется)

Преимущества:

• минимальная стоимость (+5–15% к primary-инфраструктуре);

• RTO (Recovery Time Objective) — 1–2 часа;

• RPO (Recovery Point Objective) — 30–60 минут (зависит от частоты snapshots);

• простота поддержки.

Недостатки:

• длительное время восстановления;

• требует отработанного процесса деплоя (IaC обязателен);

• необходимы регулярные тесты восстановления (ежемесячно);

• риск устаревших snapshots или сломанной автоматизации.

Сравнительная таблица:

Урок #4: проектируйте для graceful degradation

Вместо полного отказа при падении зависимости системы должны деградировать gracefully — продолжать работать с ограниченной функциональностью.

Ключевые паттерны устойчивости:

Circuit Breaker — после нескольких неудачных попыток обращения к сервису перестать его дёргать на определённое время. Вместо того, чтобы каждый запрос ждал таймаута DynamoDB (30 секунд × 1000 запросов = катастрофа), circuit breaker «размыкается» и сразу возвращает fallback.

Retry с exponential backoff — не бомбардировать упавший сервис запросами. Первая попытка → 1 секунду ждём → вторая попытка → 2 секунды → третья попытка → 4 секунды. Это даёт сервису время восстановиться и не усугубляет проблему.

Локальное кэширование с fallback на stale data — храните критичные данные локально (Redis, in-memory). Если DynamoDB недоступен, отдавайте данные из кэша, даже если они устарели на час. Устаревшие данные лучше, чем полный отказ сервиса.

Offline-first возможности — приложение должно иметь базовую функциональность без облака. Во время инцидента AWS даже умные дверные звонки Ring и будильники Alexa перестали работать — плохое проектное решение для устройств, которые должны работать оффлайн.

Асинхронные операции вместо синхронных — если запись в DynamoDB не критична прямо сейчас, положите её в локальную очередь и обработайте позже. Пользователь получает ответ мгновенно, а синхронизация произойдёт, когда AWS восстановится.

Режимы деградации по уровням:

• Уровень 1 (полная функциональность): Все сервисы доступны.

• Уровень 2 (деградация): Используем кэш, отключаем некритичные features (рекомендации, аналитику).

• Уровень 3 (survival mode): Только критичная функциональность (авторизация, основные операции).

• Уровень 4 (read-only): Показываем данные, но запрещаем изменения.

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

Урок #5: мониторинг SystemErrors, не только UserErrors

Критический урок из этого инцидента: нужно мониторить системные ошибки AWS, а не только ошибки приложения.

Ключевые метрики для мониторинга инфраструктуры:

DynamoDB:

• SystemErrors — ошибки AWS инфраструктуры (алерт при любом значении > 0!);

• UserErrors — ваши ошибки (throttling, validation);

• ConsumedReadCapacityUnits — внезапное падение = проблема.

Network Load Balancer:

• TCP_ELB_Reset_Count — сбросы от балансировщика (критический индикатор);

• HealthyHostCount — количество здоровых таргетов;

• UnHealthyHostCount — алерт когда > 0.

EC2:

• Успешность запуска инстансов (не только работоспособность запущенных);

• 5xx ошибки API (указывают на серверные проблемы AWS).

DNS:

• Время разрешения критичных эндпоинтов;

• Процент неудачных DNS-запросов.

Композитные алерты — настройте алерты, которые срабатывают при одновременном росте ошибок в нескольких сервисах. Это паттерн каскадного сбоя:

ALERT: AWS Regional Issues
Триггер: (DynamoDB SystemErrors > 0) AND (EC2 API 5xx > threshold) AND (Lambda throttles > baseline)
→ Вероятно проблема на уровне региона, а не в вашем приложении line) → Вероятно проблема на уровне региона, а не в вашем приложении

Выводы

Инцидент AWS US-EAST-1 20 октября 2025 года — это отличный пинок для всей индустрии. Основные выводы:

1. Multi-AZ ≠ High Availability в современном понимании. Для критичных систем нужен multi-region.

2. SLA-кредиты — не компенсация. $10k кредитов не покрывают $500k+ реальных потерь. Страхуйте риски сами. Большой брат о вас не позаботится.

3. Системы мониторинга — важная инфраструктура. Health checks могут стать точкой отказа.

4. DNS — это не про «просто работает». Мониторьте DNS resolution, кэшируйте агрессивно, имейте fallback.

5. Каскадные отказы страшны. Граф зависимостей сложнее, чем кажется. DynamoDB → 70+ сервисов за считаные минуты.

6. US-EAST-1 проблемный регион. Пять крупных инцидентов за 5 лет — это паттерн, не случайность.

7. Восстановление требует времени. Нельзя «просто перезагрузить» облачный регион. 10-13 часов — это реальность масштаба.

Помните: вопрос не в том, падёт ли наш славный герой снова, а в том, когда это произойдёт и будете ли вы готовы.

© 2025 ООО «МТ ФИНАНС»