Добавить в корзинуПозвонить
Найти в Дзене

AWS лег: Amazon объяснила причину сбоя

Ночью с 19 на 20 октября 2025 года интернет ощутимо «пошатнулся»: переставали открываться приложения и сайты, от мессенджеров до онлайн‑игр и «умных» устройств. Теперь Amazon подробно рассказала, что пошло не так в облаке AWS. Если коротко — в центре истории оказался DNS для базы данных DynamoDB: автоматические системы составления и применения DNS‑планов разошлись по времени, и в определённый момент региональный адрес сервиса в us‑east‑1 оказался пустым. Дальше — каскад: всё, что зависело от DynamoDB, стало сбоить. Внутри AWS эта часть инфраструктуры устроена так: один компонент вычисляет «план» DNS‑записей с учётом здоровья балансировщиков, второй применяет его в Route 53. В роковой момент «планировщик» начал выпускать планы быстрее обычного, один «применятель» тормозил, другой — летел вперёд. Итог — старый план переписал новый, а затем автоматизация удалила «как устаревшее» то, что было нужно. Система не смогла самовосстановиться и потребовала ручного вмешательства инженеров. Отдельн
Оглавление

AWS лег: Amazon объяснила причину сбоя

Ночью с 19 на 20 октября 2025 года интернет ощутимо «пошатнулся»: переставали открываться приложения и сайты, от мессенджеров до онлайн‑игр и «умных» устройств. Теперь Amazon подробно рассказала, что пошло не так в облаке AWS. Если коротко — в центре истории оказался DNS для базы данных DynamoDB: автоматические системы составления и применения DNS‑планов разошлись по времени, и в определённый момент региональный адрес сервиса в us‑east‑1 оказался пустым. Дальше — каскад: всё, что зависело от DynamoDB, стало сбоить.

Что именно случилось

Внутри AWS эта часть инфраструктуры устроена так: один компонент вычисляет «план» DNS‑записей с учётом здоровья балансировщиков, второй применяет его в Route 53. В роковой момент «планировщик» начал выпускать планы быстрее обычного, один «применятель» тормозил, другой — летел вперёд. Итог — старый план переписал новый, а затем автоматизация удалила «как устаревшее» то, что было нужно. Система не смогла самовосстановиться и потребовала ручного вмешательства инженеров.

Отдельная соль на рану — масштаб зависимости от DynamoDB. Сервисом пользуются не только внешние клиенты, но и внутренние компоненты AWS. Из‑за этого эффект домино докатился до множества услуг: от очередей и лямбд до банальной авторизации в приложениях.

Почему пострадали «умные вещи»

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

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

Зачем это знать обычному пользователю

  • Проверяйте офлайн‑функции. Перед покупкой умного устройства убедитесь, что базовые операции доступны без интернета: включить/выключить, изменить температуру, открыть дверь.
  • Сохраняйте дубли. Умный замок — хорошо, но физический ключ лучше один раз положить в кошелёк, чем однажды ночевать на коврике.
  • Будьте готовы к «плану Б». Для критичных сервисов держите альтернативные каналы связи и платежей, а важные документы храните локально.

Что делать бизнесу

  • Проектируйте отказоустойчивость по умолчанию. Многозонность и межрегиональные реплики — не роскошь. Даже если мультиоблако пока не по карману, как минимум держите read‑only режимы и деградацию функциональности.
  • Думайте о DNS как о приложении. Агрессивное кеширование, короткие TTL там, где критично переключение, внутренние резолверы с независимым кэшем — это снижает вероятность «обнулить» весь трафик.
  • Стоп‑краны и очереди. Circuit breaker, back‑pressure, лимиты на фоновую телеметрию — чтобы ваши сервисы не рухнули от собственного количества ретраев.
  • Наблюдаемость и учения. Синтетические пробы из разных регионов, алерты на рост NXDOMAIN/SERVFAIL, регулярные «game day» с имитацией недоступности зависимостей.
  • IoT без интернета. Для устройств — обязательный локальный канал (Bluetooth/локальная сеть) и «минимальный набор кнопок» для критичных сценариев.

Вывод

Этот сбой — не «чёрный лебедь», а напоминание: любой большой облачный провайдер — всё равно один провайдер. Автоматизация способна спасать и… ошибаться на космических скоростях. Хорошая новость — из таких инцидентов экосистема быстро извлекает уроки: Amazon уже отключила проблемные механизмы и добавляет предохранители, производители гаджетов спешно внедряют офлайн‑режимы. Плохая — следующий форс‑мажор будет другим. Поэтому лучший «анти‑сбой» для нас с вами — разумная автономность, от домашнего гаджета до корпоративной архитектуры.

Ключевые слова: AWS, Amazon, сбой, DynamoDB, DNS, облака, отказоустойчивость, офлайн‑режим, IoT, безопасность данных