Безопасность. Последствия сбоя AWS (октябрь 2025) для Ethereum и EVM‑совместимых блокчейнов
Введение
О блокчейне и криптовалюте ходит столько слухов, что остановить этот поток невозможно, но можно по крайне мере - в нём не купаться...
В октябре 2025 года (20 числа) масштабный сбой Amazon Web Services (AWS) в регионе US-East-1 затронул значительную часть интернета, в том числе критичную инфраструктуру многих блокчейн-сетей и сервисов.
Причиной сбоя стала ошибка DNS при обращении к сервису DynamoDB AWS, что привело к отказу множества облачных сервисов на несколько часов.
Ряд СМИ выступили с заявлениями - подобными этому: "Хотя сами блокчейн-сети уровня протокола (L1) продолжили работу, этот инцидент выявил их зависимость от централизованных облачных компонентов". Ниже поэтому представлен подробный анализ влияния сбоя AWS на сетях: Ethereum, BNB Chain, Polygon, Avalanche, а также на ключевых инфраструктурных провайдеров (Infura, Alchemy, Ankr, Chainstack и др.).
Ethereum Mainnet (основная сеть Ethereum)
Работа блокчейна
Главная сеть Ethereum не остановилась во время сбоя AWS - выпуск блоков продолжался без перерыва. По данным мониторинга, отказ AWS не мог полностью “положить” Ethereum, так как узлы сети распределены между разными датацентрами и провайдерами.
Даже несмотря на то, что около 14–37% (по разным подсчётам) Ethereum-нод хостится на Amazon (значительная доля, хотя и не большинство), это лишь привело к временной недоступности части валидаторов, не затронув безопасность консенсуса.
Финализация блоков и подтверждение транзакций на уровне протокола оставались стабильными - валидаторы продолжали подписывать блоки, блокчейн не “упал”.
Таким образом, ни остановки цепочки, ни существенного замедления блока на Ethereum mainnet не произошло.
Проблемы узлов и валидаторов
У некоторых узлов Ethereum, работавших на AWS (особенно в пострадавшем регионе), наблюдался разрыв соединения и снижение доступности. По оценкам, около 18–22% кластеров узлов в регионе us-east-1 вышли из сети на время инцидента.
Тем не менее этого было недостаточно, чтобы нарушить работу сети: остальные узлы и валидаторы (на других облаках и физических серверах) продолжали поддерживать консенсус.
Валидаторы на AWS, вероятно, пропустили часть attestations/слотов, но доля отключившихся валидаторов была далеко ниже порога, критичного для финальности.
Ethereum Foundation не зафиксировал на уровне протокола никаких инцидентов - сеть оставалась децентрализованно устойчивой благодаря географическому и инфраструктурному разнообразию узлов.
Однако операторы узлов и сервисов столкнулись с ошибками. Например, некоторые инфраструктурные приложения Ethereum используют AWS DynamoDB или другие сервисы AWS для кеширования и индексации; в период сбоя эти компоненты перестали отвечать.
Узлы Ethereum, полагавшиеся на затронутые AWS-сервисы (например, на DNS Amazon для пиров), временно не могли резолвить адреса и теряли связь до восстановления DNS AWS. В логах таких узлов могли появляться ошибки подключения к пирами, таймауты запросов к БД и пр. Эти проблемы решились автоматически после восстановления AWS.
Доступ к сети (RPC, кошельки, API)
Наиболее ощутимое влияние для пользователей Ethereum проявилось через отказ RPC-инфраструктуры, прежде всего Infura.
Как вам наверняка известно, Infura - популярный узел-провайдер от ConsenSys, на который по умолчанию настроен кошелёк MetaMask, - и он как раз пострадал от сбоя AWS: на его статус-странице сообщили о массовом отключении JSON-RPC и WebSocket endpoint’ов для Ethereum mainnet и связанных сетей.
Фактически, Ethereum API Infura не работал во время аварии. Это привело к тому, что многие кошельки и dApp’ы не могли подключиться к сети, хотя сама сеть функционировала. Пользователи MetaMask заметили, что балансы отображались как 0, транзакции не отправлялись, а dApp-интерфейсы не загружались. Причина была в том, что кошелёк не мог достучаться до узла (Infura) из-за отключки облачной инфраструктуры, хотя средства пользователей на самом блокчейне никуда не девались.
Аналогичные неполадки испытывали и другие RPC-сервисы Ethereum. Например, Alchemy - второй крупнейший провайдер Ethereum API - также сообщил о частичном деградации сервиса в результате сбоя AWS.
В официальном инцидент-репорте Alchemy отмечалось, что AWS-аутедж вызвал задержки в обработке данных, ошибки аутентификации токенов и проблемы с вебхуками; команда Alchemy сразу перешла в режим мониторинга и ожидала восстановления по мере устранения неполадок AWS. Хотя инфраструктура Alchemy оставалась частично доступной, некоторые запросы могли падать или выполняться с большим лагом.
Похожую картину наблюдали и на QuickNode, Chainstack и других хостинг-провайдерах: большая часть их кластеров расположена в AWS us-east-1, поэтому в период ~06:50–09:40 UTC они испытывали перебои или повышенные задержки.
Многие децентрализованные приложения, биржи, кошельки и price-фиды, зависящие от этих API, временно не могли получить доступ к Ethereum и давали ошибки на уровне приложений.
Впрочем, поменять RPC-провайдера всё равно было можно: другое дело - готовы ли были к этому те самые пользователи, которым нужна одна волшебная кнопка?
Так и в чём тогда была проблема?
Сеть Ethereum во время инцидента функционировала практически нормально на уровне консенсуса - блоки продолжали включаться в цепь, транзакции (от тех, кто имел прямой доступ к узлам) включались в блоки, и безопасность не пострадала.
Однако из-за нарушения “последней мили” - доступа к узлам - большинство пользователей восприняли ситуацию как "Ethereum лёг" .По сути, случилось расхождение между состоянием сети и опытом пользователей: “дом (блокчейн) цел, но дверь (точки доступа) заклинило”.
Как метко отметил один наблюдатель, валидаторы продолжали работу, блоки шли, но “дорога к ним пролегала через серверы Amazon”, а эти серверы попросту отказали.
После того как команда AWS устранила сбой DNS и сервисы ожили (постепенное восстановление началось около 07:30 UTC, полная нормализация – к ~22:53 UTC того дня), Infura и другие RPC быстро восстановили доступ.
MetaMask и другие кошельки начали корректно отображать балансы снова, транзакции возобновились. В течение того же дня пропускная способность Ethereum вернулась к норме, а на следующий день последствия для пользователей уже не ощущались.
Итог для Ethereum: на уровне сети сбой AWS почти не затронул работу блокчейна, но вызвал серьёзный кратковременный паралич пользовательской и отчасти - инфраструктурной надстройки.
Вывод по Ethereum
Блокчейн Ethereum выдержал сбой AWS без остановок и финальных сбоев, продемонстрировав устойчивость за счёт децентрализации узлов. Однако около трети узлов, работавших на AWS, временно вышли из строя, что обрушило централизованные RPC-сервисы. Пользователи на несколько часов утратили возможность взаимодействовать с сетью через популярные кошельки и API. Таким образом, проблема затронула не сам блокчейн, а уровень доступа к нему, выявив сильную зависимость экосистемы Ethereum от AWS.
BNB Chain (Binance Smart Chain)
Работа блокчейна
Основная сеть BNB Chain (BSC), по имеющимся данным, не прерывала работы в ходе октябрьского сбоя AWS. Блоки продолжали генерироваться, и консенсус BFT (21 валидатор) не останавливался. Официальных сообщений о каких-либо остановках или просадке производительности блокчейна BNB Chain не поступало, что позволяет заключить об отсутствии критических нарушений.
Возможное объяснение - относительно небольшое число валидаторов BSC, многие из которых географически распределены и могли иметь резервные мощности вне AWS. Даже если несколько валидаторов BNB Chain в тот момент работали на AWS, сеть могла переключиться на оставшихся валидаторов, избежав остановки цепочки.
Примечательно, что в апреле 2025 года случился похожий инцидент с AWS, и тогда экосистема Binance пострадала значительно: биржа Binance временно приостанавливала вывод средств из-за недоступности своего AWS-инфраструктурного узла, а некоторые другие биржи (KuCoin, MEXC) тоже "легли".
После того случая команда Binance заявляла о мерах по диверсификации инфраструктуры (внедрение резервирования в разных облаках и регионах). Судя по отсутствию жалоб в октябре, к осени 2025 Binance действительно улучшила устойчивость своих сервисов.
В частности, независимые наблюдатели отмечали, что в октябрьском сбое AWS у Binance, KuCoin и MEXC не было серьёзных проблем благодаря переходу на мультиоблачную архитектуру после апрельского инцидента (тогда как зависимый от AWS Infura “упал”).
Сам блокчейн BNB Chain также, видимо, выиграл от этих мер: никаких “заморозок” BSC или пропуска блоков за тот день не зафиксировано.
Проблемы узлов и валидаторов
Официальных отчётов о неполадках нод BNB Chain во время сбоя нет. Можно предположить, что некоторые BSC-валидаторы/ноды, находившиеся в затронутом датацентре AWS, потеряли связь или перешли в оффлайн на короткое время.
Однако протокол BNB Chain (на основе Tendermint/PoSA) допускает выпадение нескольких валидаторов без остановки сети - для кворума достаточно 2/3 валидаторов онлайн. Если (бы даже) часть из 21 валидатора BSC была на AWS в Вирджинии, они могли испытать временный разрыв консенсуса, что теоретически могло замедлить подтверждение блоков. Но поскольку большинство валидаторов оставалось доступно, цепочка продолжила работу. Валидаторы на AWS вероятно автоматически фейловернулись на резервные узлы (если были настроены) или повторно присоединились после восстановления DNS.
Некоторые публичные RPC-узлы BNB Chain, если они хостились на AWS, могли испытывать трудности. Например, официальные RPC-эндпоинты BSC или сервисы типа Ankr/Chainstack для BSC - если их ноды в том регионе - временно были недоступны. Но у BNB Chain исторически множество альтернативных RPC-серверов (в т.ч. регионально распределённых), поэтому пользователи могли переключаться на рабочие узлы.
В целом, влияние на уровень узлов/валидаторов BSC было минимальным: сеть не рапортовала об ошибках консенсуса, а валидаторы не потребовали внеплановых действий.
Доступ к сети (RPC, кошельки, API)
Подключение к BNB Chain в момент сбоя AWS оставалось возможным, хотя некоторые пользователи могли заметить перебои в работе привычных сервисов. Например, Binance Smart Chain API от Infura или Alchemy не предоставляется (эти провайдеры фокусируются на Ethereum-экосистеме), поэтому прямая зависимость BSC от Infura отсутствовала - MetaMask при работе с BSC использует иные RPC. Основные публичные RPC для BSC принадлежат либо Binance (Binance RPC endpoints), либо сторонним провайдерам (ANKR, NodeReal и др.). Из них Ankr заявил, что его узлы продолжили работу несмотря на сбой AWS, NodeReal и другие тоже, вероятно, имели резервы.
Биржа Binance - ключевой инфраструктурный игрок для BNB - судя по всему, в октябре 2025 не испытывала длительных простоев. В официальных социальных сетях Binance в день сбоя не сообщалось о проблемах (что резко контрастирует с апрелем 2025, когда Binance публично признавал проблемы с AWS). Возможно, часть внутренних сервисов Binance тоже переключилась на другие регионы или облака. По итогам инцидента AWS опубликовала, что к 15:00 PDT 20 октября все сервисы вернулись в норму, и никаких последующих ограничений у Binance не наблюдалось.
Общее функционирование сети
BNB Chain (BSC) в целом пережил инцидент AWS практически незамеченным на уровне основного протокола. Сеть оставалась доступной и синхронной, транзакции включались в блоки.
Отсутствие публичных жалоб на “зависание” BSC говорит о том, что пользователи могли совершать переводы, взаимодействовать с DeFi на BSC и т.д. Возможно, небольшое снижение производительности или рост времени подтверждения имели место (например, если несколько валидаторов пропустили раунд), но это не было критичным. Ни одной из сторонних мониторинговых служб не зафиксировано аномального роста времени блока или пропусков блоков в BNB Chain в тот день.
Отмечу также, что экосистема Binance продемонстрировала уроки прошлых сбоев: благодаря ранее реализованным мерам (распределение сервисов между AWS, Google Cloud и собственными серверами) ни основная сеть BSC, ни связанные обменные сервисы не “упали” целиком. Таким образом, сбой AWS лишь подчеркнул важность таких мер: централизация на одном провайдере могла бы привести к остановке BSC, но Binance этого избежал.
Вывод по BNB Chain
Основная сеть BNB Chain не остановилась и не испытала серьёзных проблем с блоками во время сбоя AWS - об этом не сообщалось ни командой, ни пользователями. После апрельского инцидента Binance внедрил мультиоблачную устойчивость, поэтому в октябре ключевые сервисы Binance/BSC продолжили работу. Возможные локальные неполадки узлов на AWS не повлияли на работу всего блокчейна. В итоге BNB Chain показал минимальную уязвимость к данному сбою (по крайней мере, в сравнении с Ethereum-экосистемой): сеть осталась онлайн, и если пользователи переключались на работающие узлы, они могли и дальше пользоваться BSC практически в обычном режиме.
Polygon (PoS Chain)
Работа блокчейна. Блокчейн Polygon (основная сеть Proof-of-Stake) также не останавливал производство блоков, но испытал частичные сбои инфраструктуры во время инцидента AWS. По сообщениям аналитиков, у Polygon отказала часть инфраструктурных компонентов, что привело к деградации некоторых сервисов сети.
Однако консенсус Polygon PoS (сотни валидаторов) продолжал функционировать: блоки PoS-чейна не переставали финализироваться. Ни одного полного “падения” сети Polygon не зафиксировано – валидаторы и далее подтверждали блоки, и блокчейн оставался в строю.
Тем не менее, возможно, произошла незначительная задержка в выпуске блоков или пропуски чекпойнтов, если достаточное число валидаторов Polygon полагалось на AWS-инфраструктуру (например, API для координации). Но по данным сторонних мониторингов, глобального сбоя консенсуса не было. На блоксканерах Polygon (PolygonScan и др.) цепочка отображалась как активная. Следовательно, выпуск блоков на уровне L1 Polygon не прерывался.
Проблемы узлов и инфраструктуры
“Частичный сбой инфраструктуры” у Polygon, о котором упоминалось, вероятно относился к RPC-узлам, индексерам и валидаторским нодам, работавшим на AWS. Многие валидаторы и архивные узлы Polygon размещаются в облаке, включая AWS; DNS-сбой мог нарушить связь между ними или доступ к внешним БД. Сообщалось, что у ряда узлов Polygon возникли проблемы, хотя точные детали не раскрывались. Вероятно, некоторые валидаторы потеряли пиров на время, а RPC-ноды перестали отвечать.
RPC-доступ и кошельки
Существенно пострадал RPC-слой Polygon. В частности, Infura (поддерживает Polygon наряду с Ethereum) на своей статус-странице отметила, что Polygon RPC API не работает из-за сбоя AWS. Это значит, что dApp’ы и кошельки, использующие Infura для подключения к Polygon, перестали получать ответы. Метамаск, настроенный на сеть Polygon через Infura, во время аварии выдавал ошибки или не показывал баланс (аналогично ситуации с Ethereum).
Помимо Infura, у Polygon есть собственные публичные RPC (например, rpc.ankr.com/polygon, rpc-mainnet.maticvigil.com и др.), многие из которых также хостятся на AWS или Cloudflare. Если их бэкенды находились в пострадавшем регионе, то они могли быть недоступны.
Пользователи в соцсетях отмечали сложности с доступом к приложениям на Polygon в утренние часы 20 октября. Транзакции могли задерживаться: например, отправленный перевод MATIC долго не появлялся в обозревателе, хотя в итоге включался в блок после задержки.
Coinbase Wallet и другие сервисы сообщали пользователям о проблемах с Polygon RPC. Одновременно обменники (CEX), связанные с Polygon (например, вывод ERC-20 токенов в сеть Polygon), могли приостанавливать эти операции из предосторожности, ожидая стабилизации RPC.
Общее функционирование сети
Сеть Polygon PoS продолжала работать, но пропускная способность временно снизилась из-за инфраструктурных неполадок. По данным Metrika, в смежном L2-сегменте (Base) транзакционная активность падала до –40%, можно предположить, что Polygon испытывал нечто схожее (часть трафика просто не доходила до сети).
Тем не менее, никаких долговременных последствий или потерь данных не было – как только AWS восстановил услуги, узлы Polygon автоматически вернулись в строй, нагнали отставание и продолжили обработку транзакций в обычном режиме. Уже к концу дня 20 октября сеть Polygon функционировала как обычно, пользователи вновь могли беспрепятственно взаимодействовать с DeFi-протоколами и DApps на этой сети.
Официальных пост-мортемов от команды Polygon на момент анализа не обнаружено.
Однако в отраслевых обзорах инцидента Polygon упоминался наряду с другими пострадавшими сетями, что подтверждает: сбой AWS затронул Polygon в ограниченной форме, вызвав простои некоторых сервисов, но не “уронив” сам блокчейн.
Вывод по Polygon
Основной блокчейн Polygon продолжил производство блоков и не пережил остановки цепи во время сбоя AWS. Тем не менее, инфраструктура сети оказалась частично недоступна - в частности, вышли из строя RPC-эндпоинты (Infura и др.), что сделало сеть временно недоступной для многих приложений и кошельков. Валидаторы Polygon в большинстве оставались активны, поэтому сеть сохранила работоспособность, хотя и с некоторым снижением пропускной способности. После восстановления AWS все сервисы Polygon вернулись в норму, и существенных последствий не осталось. Этот эпизод подчеркнул, что операционная децентрализация инфраструктуры (развёртывание узлов в разных облаках) не менее важна, чем децентрализация протокола - слишком большая зависимость Polygon от AWS проявилась в виде описанных перебоев.
Avalanche C-Chain (основная сеть Avalanche)
Работа блокчейна
Основная сеть Avalanche (C-Chain), судя по отсутствию тревожных сообщений, практически не пострадала от сбоя AWS. Avalanche имеет сотни валидаторов, распределённых глобально, и использует консенсус Avalanche, устойчивый к отключению части узлов.
В официальных каналах Avalanche не было объявлений о проблемах 20 октября 2025 года, а внешние наблюдатели в основном фокусировались на сетях Ethereum, Solana, L2 и биржах. Это позволяет заключить, что блокчейн Avalanche продолжал работу без перерыва. Не сообщалось о сбоях в финализации или о снижении скорости подтверждения транзакций на Avalanche.
Данная устойчивость согласуется с архитектурой сети: согласно отраслевому анализу, у Avalanche доля узлов, размещённых на AWS, сравнительно ниже, чем у Ethereum (Avalanche-валидаторы активно используют и другие провайдеры и собственные узлы).
Кроме того, даже тем валидаторам Avalanche, которые работают на AWS, DNS-сбой мог не причинить столь сильного вреда - Avalanche не зависит от DynamoDB или подобных сервисов AWS.
Инфраструктура узлов
Некоторые узлы Avalanche, конечно, тоже размещаются на AWS, поэтому небольшой процент валидаторов/нод мог временно потерять связь. Однако в сети Avalanche для прогресса достаточно, чтобы большинство валидаторов были активны; отключение, скажем, 10–15% узлов (если столько пришлось на AWS-Virginia) лишь слегка увеличивает сетевую задержку, но не останавливает консенсус.
Децентрализованные RPC-узлы Avalanche (включая публичные API от Ava Labs) также, по имеющимся данным, оставались в строю - вероятно, потому что у Ava Labs многорегиональная настройка или быстрое переключение на резервные регионы.
Никаких массовых жалоб пользователей Avalanche на недоступность кошельков или API не зафиксировано.
Большинство Avalanche-кошельков (например, Core, MetaMask с настройкой Avalanche) могли продолжать работать. Только отдельные инфраструктурные сервисы на AWS (например, какие-либо индексы или сторонние аналитические API для Avalanche) могли испытывать трудности, но на основной функционал сети это не повлияло.
Доступ к сети и RPC
RPC-эндпоинты Avalanche, в отличие от Ethereum/Polygon, не зависели от Infura, поскольку Infura/Alchemy на момент инцидента не поддерживали Avalanche C-Chain.
Основные RPC для Avalanche - это узлы, поддерживаемые сообществом и самой Ava Labs (api.avax.network и др.). Их архитектура предположительно распределена по разным регионам. Даже если часть API-нод в US-East-1 отключилась, трафик пользователей мог быть перенаправлен на другие узлы (например, в Европе или Азии).
Таким образом, большинство кошельков и приложений на Avalanche продолжали соединяться с сетью, не замечая проблем, либо заметив их минимально (чуть более долгий отклик, возможно).
Некоторые централизованные биржи (CEX), интегрированные с Avalanche, могли на время приостановить ввод/вывод токенов AVAX, ожидая подтверждения стабильности сети - подобные превентивные меры стандартны при крупных сбоях инфраструктуры. Но сообщений о таких паузах конкретно 20 октября не найдено, что косвенно подтверждает: Avalanche функционировал нормально.
Общее функционирование сети
Avalanche продемонстрировал высокую устойчивость, и инцидент AWS прошёл для него почти незаметно. В постфактум-обзорах упоминались сети, наиболее уязвимые к сбоям облака, и Avalanche там не фигурировал - напротив, обсуждались случаи Solana, Base, Polygon.
Можно сделать вывод, что производительность Avalanche не просела, транзакции обрабатывались своевременно, а пользователи в массе своей не ощутили никаких отключений. Это свидетельствует о том, что Avalanche либо изначально менее зависим от единственного облака, либо имел эффективные резервирования.
Вывод по Avalanche
Основной сеть Avalanche осталась полностью работоспособной в течение сбоя AWS - никаких остановок или заметных задержек блоков зафиксировано не было. Если отдельные узлы на AWS и отключались, децентрализованный консенсус Avalanche это компенсировал. Пользователи Avalanche, по сути, не столкнулись с проблемами доступа, поскольку основные RPC-сервисы сети не легли. В совокупности, влияние сбоя AWS-2025 на Avalanche было минимальным, и эту сеть можно отнести к числу наименее пострадавших. (Отдельные проекты хвалили даже еще большую устойчивость – например, Hedera и Solana – отмечая, что распределение узлов по разным провайдерам спасло их от любых проблем. Avalanche показала сходный результат, хоть и не фигурировала напрямую в отчетах, что само по себе указывает на отсутствие инцидента.)
Инфраструктурные провайдеры: Infura, Alchemy, Ankr, Chainstack и др.
Сбой AWS 20.10.2025 особо ярко проявился на уровне блокчейн-инфраструктуры Web3, обслуживаемой централизованными компаниями. Многие из них сильно зависят от AWS, и инцидент выявил узкие места. Ниже обзор по ключевым провайдерам:
Infura (Consensys)
Один из крупнейших поставщиков RPC для Ethereum и сетей уровня 2. Пострадал наиболее заметно. На Infura пришёлся основной удар: из-за проблем на AWS вышли из строя RPC-узлы Infura для Ethereum Mainnet, а также для Polygon, Optimism, Arbitrum, Base, Linea, Scroll и др. I
nfura оперативно сообщила о “массовом отключении нескольких сетей и сервисов” – это отражено на её официальной статус-странице. Практически все сети, которые обслуживал Infura, стали недоступны через их API. MetaMask (использующий Infura) и другие кошельки/сервисы потеряли соединение с Ethereum и L2: запросы возвращали ошибки или не проходили вовсе.
Сообщество отмечало, что “статус Infura загорелся как новогодняя ёлка” - все колонки (Ethereum Mainnet, Polygon, Arbitrum и т.д.) были помечены как “Down”.
Пока AWS не восстановился, пользователи Infura не имели доступа к этим сетям. Это длилось порядка 2–3 часов в критический период утра 20 октября. После устранения неполадок DNS на AWS Infura постепенно вернула все сервисы онлайн.
В социальных сетях ConsenSys/Infura впоследствии подчеркнули необходимость диверсификации инфраструктуры, ведь данный случай продемонстрировал уязвимость: “шесть децентрализованных сетей погасли одновременно, потому что все они зависели от одного облачного канала”. Infura – тот самый “канал” - стал единой точкой отказа для множества сетей. (Хотя в целом - это перекладывание ответственности, как по мне).
Официальные заявления: конкретных пресс-релизов Infura по итогам инцидента не публиковала, но на твиттер-аккаунте ConsenSys и на профильных ресурсах активно обсуждалась ситуация. Представители ConsenSys признали наличие проблем и подтвердили, что причиной было падение AWS. Данная ситуация даже мотивировала ConsenSys ускорить работу над децентрализованной альтернативой Infura (проект “EigenLayer/Decentralized Infura” анонсировался вскоре после). В целом, случай с Infura стал одним из главных “уроков” этого сбоя.
Alchemy
Второй по популярности Web3-провайдер (Ethereum, Polygon, ряд L2). Также пострадал, но несколько менее публично. На официальной странице статуса Alchemy был зафиксирован инцидент “Degredation due to AWS Outage” с пометкой Partial outage.
Alchemy сообщила, что AWS-проблемы вызвали ряд сбоев: рост задержки при обработке данных, проблемы с валидацией JWT (авторизация), задержки вебхуков и проблемы сервисов кошельков.
Проще говоря, некоторые API Alchemy начали работать медленнее или выдавать ошибки. Это продолжалось, пока AWS не стабилизировался; команда Alchemy “активно мониторила” ситуацию и уверяла, что сервисы автоматически восстанавливаются по мере нормализации работы AWS.
Судя по таймстампу, деградация началась около 07:00 UTC 20 октября и окончательно была разрешена к ~09:21 UTC 21 октября (с учётом полной обработки всех бэклогов).
Однако уже днём 20 октября (к ~17:00 UTC) большинство функций Alchemy вернулись в норму. Alchemy сделала интересный вывод: хотя их сервис испытал трудности, общий аптайм остался высоким. Впоследствии Alchemy в промо-материалах упоминала, что несмотря на AWS-аутедж они обеспечили ~99.99% аптайма, гордясь своей отказоустойчивостью.
Вероятно, у Alchemy действительно были задействованы мульти-региональные возможности (например, резерв в AWS Западного побережья или на Azure/Google Cloud), позволившие быстрее восстановить пользовательские запросы.
Официальные заявления: Alchemy не выпускала отдельного публичного отчёта о сбое, но в неформальных коммуникациях (блог, X) подчеркивала свою стабильность. В их официальном блоге была статья о надежности инфраструктуры, где упоминался урок сбоя 20 октября: "напоминание, почему надёжная инфраструктура критически важна для каждого билдера".
Хотя прямая расшифровка там закрыта, из контекста ясно: Alchemy позиционирует свой сервис как выдержавший этот кризис лучше конкурентов. Тем не менее, факты указывают на то, что Alchemy испытывала частичные неполадки около 15 часов (с постепенным улучшением), напрямую связанные с AWS.
Ankr
Децентрализованный провайдер узлов и RPC (обслуживает множество сетей, включая Ethereum, BSC, Polygon, Avalanche и др.). В отличие от Infura и Alchemy, Ankr практически не пострадал от сбоя.
Команда Ankr впоследствии выпустила подробный блог-пост, где отметила, что во время облачных отключений 2025 года, включая инцидент 20 октября, инфраструктура Ankr продолжала обслуживать трафик без перерывов. О
ни объяснили это особенностями своей архитектуры: Ankr не полагается исключительно на AWS, а использует собственные bare-metal серверы, частную распределённую сеть датацентров и кастомный блокчейн-ориентированный балансировщик нагрузки, умеющий обходить сбои целых облачных регионов.
Проще говоря, Ankr изначально спроектирован для устойчивости к такому сценарию: если AWS-Virginia “падает”, запросы пользователей перенаправляются на узлы в других регионах и на других провайдерах. В результате, по словам Ankr, их RPC и ноды не прекращали работу и клиенты Ankr зачастую даже не заметили проблем. Эта ситуация стала для Ankr поводом подчеркнуть преимущество децентрализованной инфраструктуры: в их статье содержался призыв к командам dApp’ов и бирж задуматься об архитектуре без единой точки отказа, “иначе следующий сбой AWS снова выключит пол-крипто”.
Официальные заявления: описанная информация взята из официального блога Ankr (статья “How 2025’s Cloud Outages Affected Crypto – And Why Ankr Stayed Online”, опубликована 8 декабря 2025). В соцсетях Ankr также комментировал ситуацию: 20 октября их аккаунт и представители отмечали, что “95% крипто легло из-за AWS, а у Ankr всё работает”, делясь скриншотами статус-панелей.
Это, конечно, преувеличено, но по сути Ankr действительно успешно пережил инцидент. Их пример продемонстрировал, что грамотная мультиоблачная и “наземная” архитектура может защитить Web3-сервисы от глобальных сбоев облаков.
Chainstack
рупный провайдер узлов как сервис (RPC для Ethereum, BSC, Polygon, Avalanche и др.). По Chainstack конкретных публичных отчетов о влиянии сбоя нет. Вероятно, Chainstack испытал сходные трудности, как и другие централизованные провайдеры, поскольку значительная часть их инфраструктуры тоже развёрнута на AWS.
В документации Chainstack указано, что они позволяют выбирать разные облака (AWS, Azure, GCP) и регионы для размещения узлов. Если какие-то из их узлов или балансировщики находились в AWS us-east-1, то во время сбоя эти компоненты перестали отвечать. Клиенты Chainstack могли наблюдать задержки или недоступность своих нод в этот период.
Поскольку Chainstack - сервис более низкого уровня (B2B, для разработчиков), шум вокруг него был не такой заметный. Можно отметить, что не было публичных жалоб на полный отказ Chainstack – вероятно, у них тоже сработали резервные механизмы. Например, они могли переключить трафик на узлы в Европе/Азии или автоматически мигрировать нагрузки на Azure. Совокупно, Chainstack, скорее всего, столкнулся с частичным ухудшением сервиса, но без тотального простаивания сети узлов.
Официальные заявления: на момент подготовки отчёта официальных заявлений или постов от Chainstack по этому инциденту не найдено. Это может значить, что они посчитали инцидент относительно незначительным для своих клиентов. Либо всю подробную информацию получили их пользователи через внутренние каналы поддержки.
Другие провайдеры
Сбой AWS затронул и многие другие связанные сервисы крипто-инфраструктуры:
- QuickNode – аналогично Infura/Alchemy, большая часть кластеров на AWS. Судя по общему характеру проблемы, QuickNode имел проблемы с откликом RPC. В MEXC-отчёте QuickNode прямо упомянут среди сервисов, сильно зависящих от AWS.
- Биржевые API и боты. Несколько централизованных бирж (например, Coinbase, Robinhood) вообще перестали отвечать пользователям на несколько часов из-за того, что их backend в AWS отключился. Coinbase уведомляла клиентов о недоступности сервисов “для многих пользователей” из-за проблемы с AWS. Robinhood также подтвердила сбой торговли утром 20 октября. Эти проблемы были решены после восстановления AWS, но показали, что даже централизованные финтех-платформы – критичная часть on/off-рамп для блокчейна – уязвимы к таким же облачным рискам.
- Децентрализованные приложения и сервисы. Во время сбоя кошельки (MetaMask, TrustWallet и др.) не показывали баланс или не подключались к DApp’ам; Uniswap и другие DeFi протоколы на Ethereum выдавали ошибки соединения (поскольку их форки фронтенда обращались к Infura/Alchemy). NFT-маркетплейсы (OpenSea и т.п.) не могли обновлять списки, оракулы цен давали задержки (Chainlink тоже частично в облаке). Некоторые кроссчейн-мостыприостановили работу (например, LayerZero остановил бридж между Base и Ethereum, видя неполадки). Однако ни смарт-контракты, ни сами активы пользователей не пострадали – проблемы носили интерфейсный и инфраструктурный характер, не затрагивая состояние блокчейнов напрямую.
Общие итоги
Инцидент со сбоем AWS в октябре 2025 года выступил стресс-тестом для всей экосистемы блокчейна, высветив парадокс: децентрализованные сети полагаются на централизованные “точки доступа”.
Ни один крупный блокчейн на уровне протокола не “упал” полностью (Ethereum, BNB Chain, Polygon, Avalanche и др. продолжали консенсус), но у большинства этих сетей доступ для пользователей был нарушен, что создавало ощущение полного отключения.
Фактически, как отмечено в ряде обзоров, сети оставались защищёнными и распределёнными, а вот доступ к ним сконцентрирован в руках нескольких облачных провайдеров. Когда отказал крупнейший из них (AWS), это “узкое горлышко” перекрыло путь для подавляющего числа пользователей.
Ключевые провайдеры, такие как Infura и Coinbase, сделали публичные заявления, признавая проблему и работая над восстановлением. Amazon (AWS) со своей стороны опубликовал подробный отчёт: сбой длился ок. 15 часов с поэтапным восстановлением, причиной стал единичный сбой DNS, приведший к каскаду проблем.
AWS заверила, что проводит работы, чтобы подобное не повторилось, однако факт остаётся - частота больших аутеджей облаков растёт, и сообщество крипто обратила на это пристальное внимание.
В ответ на случившееся, в индустрии усилились разговоры и инициативы по децентрализации инфраструктуры:
- ConsenSys и другие проекты ускоряют запуск децентрализованных RPC-узлов и сетей (чтобы MetaMask мог работать без единого Infura).
- Появились призывы использовать мультиоблачные и мультирегиональные развертывания для бирж, оракулов и пр. (разбивать сервисы между AWS, Google Cloud, Azure и собственными серверами). Некоторые компании уже продемонстрировали эффективность такого подхода (см. опыт Binance, Ankr).
- Обсуждаются решения на основе децентрализованных облаков (проекты типа Filecoin, Arweave для хранения, Flux, Akash для вычислений и др.), которые могут со временем снизить зависимость Web3 от традиционных датацентров. После инцидента, токены децентрализованных инфраструктур даже росли в цене, отразив ожидания сообщества.
Подводя итог, сбой AWS 20 октября 2025 года не “уронил” сами блокчейны, но стал причиной серьезных перебоев “над” блокчейнами.
Ethereum и другие EVM-сети продолжали генерировать блоки, но большинство пользователей не могли этого увидеть или воспользоваться этим из-за недоступности RPC и обменников.
Некоторые сети (например, Base L2) испытали сильное снижение пропускной способности, задержки транзакций и были фактически непригодны для использования в часы инцидента.
Другие, как Hedera, Solana или Avalanche, остались практически невредимы, благодаря более распределённой инфраструктуре. Этот случай стал громким напоминанием: чтобы соответствовать идеалам децентрализации, необходимо децентрализовать не только блокчейн-узлы, но и всю связанную инфраструктуру - RPC-гейты, API, валидаторские координаторы и прочее.
Пока этого не произошло, любой сбой облака может превратить “невидимую бомбу” централизованной зависимости в реальный простой децентрализованных приложений.
Таким образом, октябрьский сбой AWS 2025 послужил уроком и катализатором для повышения устойчивости крипто-инфраструктуры на всех уровнях.