Сети дата-центров AWS переживают редкую для инфраструктурного мира встряску: компания заявила, что в большинстве новых площадок для обычных вычислительных нагрузок больше не строит классическую fat-tree-схему. Вместо нее AWS использует Resilient Network Graphs, или RNG, и на выходе получает на 69% меньше сетевых устройств, до 33% больше пропускной способности и прогнозное снижение энергопотребления сетевого оборудования на 40%.
Для русскоязычной IT-аудитории здесь важен не только масштаб AWS. Если гиперскейлер действительно смог вынести в продакшн идеи из теории случайных графов и сделать их стандартом для новых дата-центров, это хороший сигнал для всей отрасли: привычная иерархия spine-leaf и fat-tree больше не выглядит единственным разумным вариантом. Об этом сообщает InfoQ.
AWS раскрыла детали перехода вместе с публикацией на arXiv. Авторы работы — principal applied scientist AWS Джакомо Бернарди, профессор Университета Вашингтона и Amazon Scholar Ратул Махаджан, а также профессор UC Santa Cruz и Amazon Scholar Сешадхри Командур. Они называют RNG первым крупномасштабным промышленным внедрением сетевой фабрики на базе expander-графов. Если перевести это с академического на инженерный, смысл такой: вместо многоэтажной структуры из ToR-, aggregation- и spine-уровней AWS строит плоскую сеть, где стоечные коммутаторы связаны напрямую с квазислучайным набором других стоек.
Классическая fat-tree работает понятно и предсказуемо, но дорого обходится в момент, когда сеть надо расширять и держать под высокой нагрузкой. Трафик между серверами в разных стойках поднимается вверх по иерархии к общему уровню spine, а затем спускается обратно. Если этот верхний слой перегружен, просадка наступает даже тогда, когда в других частях сети свободная емкость еще есть. При росте дата-центра проблему обычно решают знакомым способом: добавляют новые уровни и новые устройства. Это означает больше портов, больше кабелей, больше потребления энергии и, как следствие, больше счетов за инфраструктуру.
В RNG AWS выкидывает из этой схемы сами уровни leaf/spine как архитектурную опору. Вместо них остается mesh из ToR-коммутаторов, соединенных напрямую через межстоечные uplink-кассеты. Логика маршрутизации и физика соединений при этом расходятся: кабельное хозяйство должно остаться управляемым, даже если логическая топология выглядит почти случайной. Для этого AWS разработала ShuffleBox — пассивное оптическое устройство, в котором волокна внутри уже «перемешаны» нужным образом. Снаружи монтаж для оператора остается сравнительно простым: он подключается к локальным портам, а квазислучайная структура формируется внутри коробки. Пассивность здесь не декоративная деталь: устройство не добавляет задержку, не ест электричество и не привносит отдельный активный домен отказа.
Вторая проблема еще интереснее: как вообще маршрутизировать трафик в такой сети, где нет привычной иерархии? AWS отвечает собственным распределенным протоколом Spraypoint. По описанию компании, он отправляет трафик одновременно по нескольким соседним маршрутизаторам и использует выделенные waypoint-узлы, чтобы довести пакеты до назначения. На бумаге идея «распылять» трафик по нескольким путям кажется не самой экономной. На практике ставка делается на то, что избыточность уже встроена в саму топологию, а равномерное распределение трафика позволяет лучше использовать полосу пропускания и снижать число перегретых линков.
Почему это важно не только для AWS
Самая сильная часть истории — не даже экономия на железе, а поведение сети при сбоях. В fat-tree потеря крупного spine-узла бьет сразу по большому числу стоек под ним, и деградация часто получается непропорционально болезненной. В RNG AWS утверждает более линейную модель: если из строя выходит 1% роутеров, сеть теряет примерно 1% емкости. Для операторов больших инфраструктур это почти идеальный сценарий деградации. Нет «центрального позвоночника», выход из строя которого превращает локальную аварию в системную.
Прежде чем довести архитектуру до статуса default, AWS довольно долго ее гоняла в моделях и на пилотах. По данным компании, на симуляции ушло 530 процессоро-лет в EC2, а тестирование охватило десятки типов трафика. Первая производственная сеть такого типа заработала в конце 2024 года рядом с Дублином. Затем AWS провела еще три развертывания для проверки и доработки — в Ирландии, Германии и Испании. И только после этого, в апреле 2026 года, RNG стала базовой архитектурой для большинства новых площадок без GPU-нагрузок по всему миру. Это важная деталь: речь не о лабораторной демонстрации и не о специальной зоне, а о решении, которое компания уже поставила на конвейер.
Экономика у перехода тоже выглядит убедительно, хотя тут стоит держаться ближе к формулировкам из статьи, а не к маркетинговому восторгу. В публикации на arXiv говорится о снижении совокупной стоимости в диапазоне от 9% до 45% по сравнению с fat-tree при сопоставимой или более высокой производительности. Разброс большой, что нормально для инфраструктуры такого класса: многое зависит от сценариев нагрузки, размеров площадки и конкретной конфигурации. Но даже нижняя граница для операторов дата-центров звучит как повод хотя бы пересчитать свои модели, особенно на фоне цен на электроэнергию и роста плотности вычислений.
Есть и ограничение, которое AWS не прячет. Сети дата-центров AWS в конфигурации RNG рассчитаны на обычные вычислительные нагрузки, где трафик близок к случайному распределению. Для AI-тренировки, где огромное число GPU синхронно разговаривает с ограниченным набором узлов и генерирует куда более централизованный паттерн, такая архитектура подходит хуже. Поэтому для GPU-кластеров AWS продолжает использовать UltraServer. Это, кстати, убирает соблазн записать RNG в универсальный рецепт на все случаи жизни. Для облачной инфраструктуры общего назначения — да, для любой высокоплотной AI-сети — уже не факт.
Для разработчиков и продуктовых команд вывод довольно простой. Пользовательские приложения ничего специально менять не должны: AWS прямо говорит, что миграция не потребовала модификации клиентских нагрузок. Но на уровне платформы это означает более предсказуемую производительность и меньшую вероятность неожиданных сетевых узких мест в регионах, где новые площадки будут вводиться именно на RNG. Для бизнеса важнее другое: облака продолжают искать не только новые чипы, но и новые способы удешевить саму физику дата-центров. Когда лидер рынка сокращает число сетевых устройств почти на две трети, это быстро становится не академическим упражнением, а аргументом на совете директоров.
Главный вопрос теперь не в том, сможет ли AWS жить со случайными графами — похоже, уже может. Вопрос в том, насколько быстро остальные гиперскейлеры перейдут от публикаций и экспериментов к массовому продакшну. Google, Microsoft и Meta давно исследуют альтернативы fat-tree, но сопоставимого раскрытого внедрения expander-сетей в таком масштабе пока не показывали. Если вслед за AWS они начнут убирать иерархию из обычных дата-центров, сама дискуссия о том, какой должна быть сетевая фабрика в облаке, заметно сдвинется. Подробности можно сверить в материале .