Примечание переводчика: статья собрана на основании постмортема, документации AWS и других источников.

Масштабный сбой в AWS, случившийся 19–20 октября, губительно сказался на работоспособности многих глобальных сервисов. Пострадали Signal, Snapchat, ChatGPT, Zoom, Lyft, Perplexity, Slack, Reddit, McDonald's, United Airlines и Disney и другие. Упала даже гроза всех ленивцев и прокрастинаторов — сова Duolingo.

Давайте разберёмся, что же произошло. 

Структура AWS

Сначала несколько слов об особенностях структуры AWS, которые и привели к проблемам (причины сбоя описываются в разделе «Постмортем» — если хочется побыстрее погрузиться в конкретику, рекомендуем переключиться сразу на него).

Помимо региональных и зональных сервисов AWS, существует группа глобальных сервисов, чьи управляющие слои (control planes) и слои данных (data planes) не разделены по регионам. Ключевое отличие большинства глобальных сервисов заключается в том, что их управляющий слой размещён в одном регионе AWS, в то время как слой данных распределён по всему миру. Это создаёт потенциальные риски для отказоустойчивости. 

Существуют три основных типа таких сервисов, а также категория сервисов, которые могут выглядеть как глобальные из-за конфигурации по умолчанию.

Первый тип — это сервисы, которые разделены на уровне партиции AWS, а не по регионам. Ярким примером является AWS Identity and Access Management (IAM). Его управляющий слой находится в регионе us-east-1. Это означает, что любые операции по созданию, изменению или удалению пользователей, ролей и политик IAM зависят от доступности этого региона. При этом слой данных IAM, отвечающий за аутентификацию и авторизацию, реплицирован по всем регионам, что обеспечивает высокую доступность для уже существующих ресурсов.

Второй тип — сервисы, работающие на глобальной пограничной сети (Edge Network) AWS. К ним относятся Amazon CloudFront и Amazon Route 53. CloudFront — это сеть доставки контента (CDN), которая кеширует данные ближе к конечным пользователям, а Route 53 — это система доменных имён (DNS), отвечающая за преобразование доменных имён в IP-адреса. 

Управляющие слои обоих сервисов также расположены в регионе us-east-1, что делает операции по настройке дистрибуций CloudFront или обновлению DNS-записей Route 53 зависимыми от его состояния. Их слои данных, напротив, распределены по сотням точек присутствия (PoP) по всему миру — так и обеспечивается отказоустойчивость для выполнения их основных функций: доставки контента и разрешения DNS-запросов.

Третий тип объединяет сервисы, чьи глобальные операции управляются из одного региона. Сюда входят AWS IAM Identity Center (преемник AWS SSO), AWS WAF Classic и AWS Chatbot. Несмотря на то, что их функциональность используется глобально для управления доступом или интеграциями, их управляющие слои централизованы в одном регионе, что создаёт единую точку отказа для любых конфигурационных изменений.

Наконец, существуют сервисы, которые используют единый эндпоинт по умолчанию, из-за чего могут казаться глобальными. Например, сервис AWS Security Token Service (STS), который генерирует временные учётные данные, по умолчанию использует эндпоинт sts.amazonaws.com, направляющий все запросы в us-east-1. Однако для повышения отказоустойчивости и устранения зависимости от одного региона рекомендуется использовать региональные эндпоинты STS, например sts.eu-central-1.amazonaws.com. Подобный подход позволяет изолировать сбои и строить более надёжные архитектурные решения.

Что такое DynamoDB

Amazon DynamoDB — полностью управляемая бессерверная NoSQL-база данных, которая обеспечивает крайне высокую производительность при любом масштабе. Создана для высоконагруженных операционных задач, требующих стабильной и предсказуемой производительности, решая проблемы масштабирования и сложности, присущие реляционным базам данных. DynamoDB поддерживает как модели данных типа «ключ-значение», так и документоориентированные модели. 

Ключевые возможности DynamoDB включают в себя автоматическую репликацию данных между несколькими зонами доступности для обеспечения высокой отказоустойчивости и долговечности, а также встроенные механизмы безопасности. Сервис поддерживает ACID-транзакции для выполнения скоординированных изменений над несколькими элементами данных как внутри одной таблицы, так и между разными таблицами. 

Для ускорения операций чтения до микросекунд можно использовать DynamoDB Accelerator (DAX) — полностью управляемый кеш в памяти. Кроме того, глобальные таблицы обеспечивают мультиактивную репликацию данных между регионами AWS, позволяя создавать глобально распределённые приложения с низкой задержкой чтения и записи для пользователей по всему миру.

Постмортем

Хотим поделиться подробностями о сбое в работе сервисов, который произошёл в регионе Северная Вирджиния (us-east-1) 19 и 20 октября 2025 года. Сам инцидент продолжался с 23:48 PDT 19 октября (09:48 МСК 20 октября) до 14:20 PDT 20 октября (00:20 МСК 21 октября). За этот период были три разные волны, которые затронули приложения клиентов (далее всё время указано по Pacific Daylight Time — отстаёт от московского на 10 часов. — Прим. пер.): 

• Первая: с 23:48 19 октября по 02:40 20 октября у Amazon DynamoDB в регионе Северная Вирджиния (us-east-1) выросло количество ошибок API. 

• Вторая: с 05:30 по 14:09 20 октября Network Load Balancer (NLB) столкнулся с увеличением ошибок подключения для некоторых балансировщиков нагрузки в том же регионе. Причиной стали сбои health check'ов NLB, что и вызвало рост ошибок при попытках соединения. 

• Третья: с 02:25 по 10:36 20 октября запуски новых инстансов EC2 завершались неудачей. И хотя с 10:37 они снова начали запускаться, у некоторых свежесозданных инстансов были проблемы со связью, которые окончательно устранили к 13:50.

DynamoDB

В промежутке с 23:48 PDT 19 октября по 02:40 PDT 20 октября клиенты столкнулись с повышенным уровнем ошибок API Amazon DynamoDB в регионе Северная Вирджиния (us-east-1). В течение этого периода ни клиенты, ни зависимые от DynamoDB сервисы AWS не могли устанавливать новые соединения с сервисом. Инцидент был вызван скрытым дефектом в автоматизированной системе управления DNS-сервиса, который привёл к сбоям в разрешении IP-адреса эндпоинта DynamoDB.

Многие из крупнейших сервисов AWS активно используют DNS для бесшовного масштабирования, изоляции сбоев и восстановления, сокращения задержек и локализации данных. Сервисы вроде DynamoDB обслуживают сотни тысяч DNS-записей, обеспечивая работу огромного гетерогенного парка балансировщиков нагрузки в каждом регионе. Автоматизация здесь играет ключевую роль, позволяя незамедлительно добавлять DNS-записи для новых мощностей по мере их вступления в строй, корректно обрабатывать аппаратные сбои и эффективно распределять трафик с целью оптимизации клиентского опыта. Эта система автоматизации была разработана с упором на отказоустойчивость, чтобы сервис восстанавливался после широкого спектра эксплуатационных проблем. 

Помимо основного регионального адреса, эта система также управляет дополнительными DNS-эндпоинтами для разных версий DynamoDB: например, для FIPS-совместимого, для IPv6 и для отдельных аккаунтов. Главной причиной сбоя стало скрытое «состояние гонки» (race condition) в системе управления DNS. В результате для главного регионального эндпоинта (dynamodb.us-east-1.amazonaws.com) создалась пустая DNS-запись, а автоматика не смогла это починить. Чтобы объяснить, что произошло, нужно рассказать об архитектуре управления DNS в DynamoDB. Для надёжности система разбита на два независимых компонента. 

Первый — Планировщик DNS (DNS Planner). Следит за здоровьем и загрузкой балансировщиков и регулярно создаёт новый DNS-план для каждого эндпоинта, указывая, какие балансировщики и с каким весом использовать. Мы делаем один общий план на регион — это сильно упрощает управление ресурсами и борьбу со сбоями, когда мощности делятся между несколькими эндпоинтами (как, например, у публичного и IPv6-эндпоинтов). 

Второй компонент — Исполнитель DNS (DNS Enactor). Разработан максимально независимым, чтобы его можно было поднять в любой ситуации. Он берёт планы и применяет их в сервисе Amazon Route 53. Для надёжности полностью независимые инстансы Исполнителя распределены по трём разным Зонам доступности (Availability Zones, AZ). Каждый такой инстанс отслеживает появление новых планов и пытается обновить Route 53 через Route 53-транзакцию, заменяя старый план на новый. Это гарантирует, что эндпоинты обновятся корректно, даже если несколько Исполнителей попытаются сделать это одновременно. 

«Состояние гонки» возникло из-за редкого стечения обстоятельств в работе двух Исполнителей DNS. Обычно всё работает так: Исполнитель берёт свежий план и начинает по очереди применять его ко всем эндпоинтам. Этот быстрый и эффективный процесс обеспечивает актуальность DNS. Перед тем как применить новый план, Исполнитель проверяет, что его план новее того, что был применён ранее. Иногда при обновлении эндпоинта один Исполнитель может быть заблокирован другим, который занимается тем же эндпоинтом. Тогда он просто повторяет попытку, пока не получится. 

Непосредственно перед началом инцидента один из Исполнителей столкнулся с необычно высокими задержками, что потребовало многократных повторных попыток обновления для ряда DNS-эндпоинтов. Пока он медленно и постепенно обрабатывал эндпоинты, произошла пара других вещей. Во-первых, Планировщик DNS сгенерировал кучу новых планов. Во-вторых, другой Исполнитель начал применять один из этих новых планов и быстро обработал все эндпоинты. 

Совпадение этих событий во времени инициировало скрытое состояние гонки. Как только «быстрый» Исполнитель закончил обновление эндпоинтов, он запустил процесс очистки — удаление сильно устаревших планов. И ровно в этот же момент «медленный» Исполнитель наконец-то применил свой устаревший план к главному региональному эндпоинту DynamoDB, затерев им свежий. Проверка на новизну плана, которую он делал в самом начале, к этому моменту уже была неактуальной из-за огромных задержек. И не смогла предотвратить перезапись нового плана старым. 

Сразу после этого «чистильщик», инициированный «быстрым» Исполнителем, увидел этот старый план и удалил его. После этого из DNS-записи пропали все IP-адреса регионального эндпоинта. Кроме того, поскольку активный план был удалён, система оказалась в несогласованном состоянии, которое мешало Исполнителям применять новые планы. В итоге потребовалось ручное вмешательство.

Когда в 23:48 PDT произошёл сбой, все системы, подключающиеся к DynamoDB в регионе Северная Вирджиния (us-east-1) через публичный адрес, сразу же столкнулись с ошибками DNS и не могли установить соединение. Это коснулось и клиентов, и внутренних сервисов AWS, работающих с DynamoDB. Пользователи с глобальными таблицами DynamoDB могли работать с репликами в других регионах, но при этом возникло серьёзное отставание репликации в проблемном регионе (us-east-1). Инженеры пострадавших сервисов AWS сразу же подключились к расследованию. В 00:38 20 октября они выяснили, что причина сбоя связана с DNS-записями DynamoDB. К 01:15, благодаря временным фиксам, был восстановлен доступ к DynamoDB для части внутренних сервисов, а починка ключевых внутренних инструментов помогла ускорить дальнейшее восстановление. В 02:25 информация в DNS была исправлена, а к 02:32 все реплики глобальных таблиц догнали отставание. Доступ клиентов к DynamoDB был восстановлен в промежутке с 02:25 до 02:40 — по мере того, как истекал срок жизни кеша их DNS-записей. На этом основной этап восстановления после инцидента был завершён.

Amazon EC2

С 23:48 19 октября до 13:50 20 октября (PDT) пользователи в регионе us-east-1 столкнулись с ростом ошибок и задержек в API EC2 и с проблемами при запуске инстансов. Инстансы, которые работали до начала сбоя, не пострадали и продолжали функционировать нормально. Даже после того, как в 02:25 починили DNS для DynamoDB, проблемы с запуском новых инстансов не исчезли. Процесс восстановления начался в 12:01. Полностью работа EC2 нормализовалась в 13:50. В это время новые инстансы не запускались, выдавая ошибку «превышен лимит запросов» или «недостаточно ресурсов».

Чтобы понять, что произошло, следует рассказать о паре внутренних систем, которые отвечают за запуск инстансов EC2 и настройку их сети. Первая система — DropletWorkflow Manager (DWFM) — управляет всеми физическими серверами, на которых работают инстансы EC2. Мы называем эти серверы «droplets». Вторая — Network Manager — управляет сетевыми настройками и передаёт их всем инстансам и сетевым устройствам. Каждый DWFM отвечает за группу droplet'ов в одной Зоне доступности и поддерживает «аренду» (lease) для каждого из них. Эта аренда позволяет DWFM отслеживать состояние сервера и гарантирует, что любое действие — будь то команда API или выключение/перезагрузка из самой операционной системы инстанса — будет правильно обработано в общей системе EC2. Для поддержания аренды DWFM должен каждые несколько минут проверять состояние каждого своего droplet'а.

С 23:48 19 октября эти проверки состояния от DWFM стали сбоить, поскольку завязаны на DynamoDB, которая была недоступна. На работающие инстансы это никак не повлияло, но для любого нового действия с инстансами droplet должен был сначала установить аренду с DWFM. В результате с 23:48 19 октября до 02:24 20 октября аренды между DWFM и droplet'ами в EC2 начали потихоньку отваливаться по таймауту.

В 02:25, после восстановления API DynamoDB, DWFM начал переустанавливать аренды с droplet'ами. Так как droplet без активной аренды не может использоваться для запуска новых инстансов, API EC2 выдавал ошибки «недостаточно ресурсов» на запросы запуска новых инстансов. Проблема была в том, что из-за огромного количества droplet'ов DWFM не успевал установить аренду до того, как она истекала по таймауту, создавая бесконечную очередь из повторных попыток. В итоге DWFM вошёл в состояние полного коллапса из-за перегрузки, и восстановление аренды droplet'ов остановилось. Готового плана действий для такого случая не было, поэтому инженеры действовали очень осторожно. В 04:14, перепробовав несколько вариантов, они ограничили (включили троттлинг) приток новых lease-задач и начали точечно перезапускать хосты DWFM. Это помогло: очереди очистились, время обработки сократилось, и аренда, наконец-то, начала устанавливаться. К 05:28 DWFM восстановил аренду со всеми droplet'ами в us-east-1, и инстансы снова начали запускаться. Правда, из-за искусственного троттлинга многие пользователи всё ещё сталкивались с ошибкой «превышен лимит запросов».

Когда запускается новый инстанс EC2, Network Manager применяет к нему сетевые настройки, чтобы тот мог общаться с соседями по Virtual Private Cloud (VPC), другими устройствами и интернетом. В 05:28, как только DWFM восстановился, Network Manager начал раздавать сетевые настройки всем новым инстансам. Но из-за предыдущего сбоя у него накопилась огромная очередь из отложенных задач. В результате в 06:21, пытаясь разгрести этот завал, Network Manager затормозил. Новые инстансы EC2 успешно запускались, но не могли получить доступ к сети из-за проблем с получением конфигурации от Network Manager. Инженеры постарались снизить нагрузку на Network Manager и ускорить процесс. К 10:36 скорость применения сетевых настроек пришла в норму, и запуск инстансов полностью восстановился.

Последним шагом в восстановлении EC2 была отмена троттлинга запросов, который мы ввели для снижения нагрузки на подсистемы EC2. После того как поток API-вызовов и запросов на запуск новых инстансов EC2 пришёл в норму, инженеры начали (в 11:23) постепенно снимать эти ограничения. К 13:50 API EC2 и запуск новых инстансов работали нормально. 

Network Load Balancer (NLB)

Проблемы с получением сетевых настроек новыми инстансами EC2 также ударили по сервису балансировки сетевой нагрузки Network Load Balancer (NLB) и другим сервисам AWS, которые его используют. С 05:30 до 14:09 20 октября некоторые пользователи в регионе us-east-1 заметили рост числа ошибок подключения на своих NLB. NLB базируются на масштабируемой мультитентатной архитектуре, которая создаёт эндпоинты для балансировки нагрузки и направляет трафик на серверы-получатели (backend targets, целевые бэкенды) — обычно это инстансы EC2. В этой архитектуре есть отдельная система отслеживания состояния, которая постоянно проверяет узлы NLB и убирает те, которые считает нерабочими.

Во время сбоя система отслеживания состояния NLB начала фиксировать рост числа неудачных тестов здоровья. Причина была в том, что для своих проверок она запускала новые инстансы EC2, у которых, как описано выше, была проблема с получением сетевых настроек. Из-за этого проверки падали, хотя на самом деле и сам узел NLB, и целевые бэкенды были в полном порядке. В итоге получалось «моргание»: проверка здоровья то падала, то проходила успешно. Это приводило к тому, что узлы NLB и целевые бэкенды удалялись из DNS, а затем возвращались в строй после следующей успешной проверки.

Наш мониторинг заметил проблему в 06:52, и инженеры приступили к её решению. «Моргание» проверок сильно нагрузило и затормозило систему, что привело к задержкам и спровоцировало автоматическое переключение трафика между Зонами доступности. У балансировщиков, работающих в нескольких Зонах, часть мощностей оказалась отключена. Если оставшихся ресурсов не хватало для обработки всей нагрузки, возникали ошибки подключения. В 09:36 инженеры вручную отключили автоматическую проверку здоровья NLB, что позволило всем здоровым узлам NLB и целевым бэкендам вернуться в строй. Это решило проблему с ошибками подключения. Как только EC2 полностью восстановился, в 14:09 мы снова включили автоматическую проверку здоровья.

Lambda

В период с 23:51 19 октября по 14:15 20 октября клиенты сталкивались с ошибками API и задержками в работе Lambda-функций в регионе us-east-1. Изначально проблемы с эндпоинтом DynamoDB препятствовали созданию и обновлению функций, вызывали задержки в обработке источников событий SQS/Kinesis и приводили к ошибкам вызова. К 02:24 работа сервиса восстановилась, за исключением обработки очередей SQS, которая оставалась нарушенной, так как внутренняя подсистема, ответственная за опрос (polling) очередей SQS, вышла из строя и не восстановилась автоматически. Мы восстановили эту подсистему в 04:40 и обработали бэклог к 06:00. Но в 07:04 возникла новая проблема: сбои в NLB приводили к тому, что инстансы Lambda стали отключаться. Результат — дефицит мощностей. Так как новые инстансы EC2 всё ещё не запускались, нам пришлось искусственно ограничить (включить троттлинг) обработку событий (Lambda Event Source Mappings) и асинхронные вызовы, чтобы освободить мощности для чувствительных к задержкам синхронных вызовов. К 11:27 удалось восстановить достаточное количество ресурсов, и ошибки прекратились. После этого мы постепенно сняли ограничения и к 14:15 обработали все оставшиеся задачи, полностью вернув сервис к нормальной работе.

Результатом инцидента стал ряд изменений. Мы уже отключили по всему миру автоматику Планировщика DNS и Исполнителя DNS в DynamoDB. Прежде чем включить её снова, мы исправим «состояние гонки» и добавим дополнительную защиту, чтобы исключить применение неправильных DNS-планов. В случае NLB будет внедрён механизм контроля, который не позволит одному балансировщику отключать слишком много мощностей при сбоях проверок состояния. Для EC2 разрабатывается новый набор тестов в дополнение к существующим тестам на масштабируемость. Он будет прогонять сценарии восстановления DWFM, чтобы выявлять подобные проблемы в будущем. Также будет улучшен механизм троттлинга в системах доставки данных в инстансы EC2: он будет ограничивать нагрузку, ориентируясь на размер очереди, чтобы защитить сервис от перегрузок. И, конечно, мы продолжим анализировать этот сбой и искать новые способы, как не допустить подобного в будущем и как восстанавливаться ещё быстрее. 

В заключение

Приносим извинения за то влияние, которое это событие оказало на наших клиентов. У нас солидный опыт работы с сервисами с высочайшим уровнем доступности,  и мы знаем, насколько важны наши услуги для клиентов, их приложений и конечных пользователей, а также для их бизнеса. Мы понимаем, что это событие оказало значительное влияние на многих и сделаем всё возможное, чтобы извлечь из него уроки и использовать для дальнейшего повышения уровня доступности.

P. S.

Читайте также в нашем блоге:

• NeuVector в современной Kubernetes-инфраструктуре: почему мы не рекомендуем его для production

• Как мы ускорили ввод новых узлов до 40 секунд: надежная работа на spot-инстансах в Kubernetes с Karpenter

• Неожиданная находка в Kubernetes: постквантовая криптография в кластера