Динамическая маршрутизация в облаках 2026: практическое сравнение AWS Transit Gateway, Azure VNet Peering и Google Cloud VPC

Динамическая маршрутизация в публичных облаках перестала быть вопросом настройки протоколов BGP на виртуальных маршрутизаторах. AWS, Azure и Google Cloud предлагают управляемые сервисы, которые абстрагируют эту сложность. Эти сервисы - AWS Transit Gateway, Azure Virtual Network Peering и Google Cloud VPC с Cloud Router - формируют сетевую связность автоматически. Ваша задача теперь сводится к определению политик и архитектуры, а провайдер обеспечивает масштабирование, отказоустойчивость и безопасность. Это сравнение поможет выбрать оптимальный инструмент для вашей топологии и избежать ошибок в проектировании гибридной инфраструктуры.

Эволюция маршрутизации: от BGP к управляемым облачным сервисам

В традиционных центрах обработки данных динамическая маршрутизация строилась на распределенных протоколах, таких как BGP или OSPF. Сетевые инженеры конфигурировали их на физических или виртуальных маршрутизаторах, управляя таблицами маршрутов, метриками и сессиями соседей. В облаке эта модель меняется. Провайдеры берут на себя операционную сложность, предлагая сервисы, где связность между изолированными сетями (VPC, VNet) устанавливается через API или графический интерфейс. Вы определяете, какие сети должны общаться, а облачная платформа автоматически обеспечивает маршрутизацию трафика между ними.

Основное преимущество управляемых сервисов - снижение операционных затрат. Вам не нужно отслеживать состояние BGP сессий, настраивать фильтрацию маршрутов или решать проблемы сходимости сети. Провайдер гарантирует доступность и производительность сервиса согласно SLA. Встроенная интеграция с другими облачными компонентами, например, с сервисами безопасности или мониторинга, также упрощает архитектуру. Однако эта абстракция имеет ограничения. Тонкий контроль над политиками маршрутизации, который возможен с "голым" BGP, в управляемых сервисах часто заменяется более простыми, но менее гибкими механизмами, например, таблицами маршрутов с привязкой к подсетям.

Где BGP все еще незаменим в гибридных сценариях

Управляемые сервисы не полностью заменяют BGP. Этот протокол остается критически важным для сложных гибридных сценариев, где требуется прямой и детальный контроль над маршрутизацией между локальной инфраструктурой и облаком. Например, при подключении локального ЦОД к AWS через Direct Connect или к Azure через ExpressRoute вы настраиваете BGP-сессии между вашим физическим маршрутизатором и облачным шлюзом провайдера. Это позволяет рекламировать специфичные маршруты из локальной сети в облако и обратно, использовать BGP communities для применения сложных политик или обеспечивать маршрутизацию между устройствами разных вендоров в вашем ЦОД и облачными ресурсами.

BGP также необходим для сценариев мультиоблачности, где прямой пиринг между сетями разных провайдеров отсутствует. Если вам нужно соединить VPC в AWS с VNet в Azure без использования сторонних VPN-туннелей, вам придется настроить BGP на сетевых виртуальных аппаратах (NVA) в каждом облаке. Это дает полный контроль, но увеличивает сложность управления. Таким образом, выбор между управляемым сервисом и BGP зависит от требований к гибкости, контроля и архитектурной сложности вашего проекта.

Архитектурное сравнение: AWS Transit Gateway vs. Azure Virtual Network Peering vs. Google Cloud VPC

Каждый облачный провайдер реализовал динамическую маршрутизацию через свою уникальную архитектурную модель. AWS использует концепцию централизованного транзитного хаба. Azure предлагает модель глобального пиринга между сетями. Google Cloud строит связность вокруг концепции общих VPC и динамических маршрутов.

Эта таблица показывает фундаментальные различия, которые определяют выбор провайдера для конкретной задачи. AWS Transit Gateway идеально подходит для крупных организаций с четкой архитектурой Hub-and-Spoke и множеством изолированных VPC. Azure VNet Peering эффективен для глобальных проектов с сетями в разных регионах, где требуется прямая связность между ними. Google Cloud подход оптимален для проектов, глубоко интегрированных в его экосистему, особенно использующих Shared VPC для централизованного управления ресурсами нескольких проектов.

Hub-and-Spoke: как реализовать в каждом облаке

Hub-and-Spoke - популярная топология для централизации управления, безопасности и контроля трафика. Вот как ее реализовать в каждом облаке.

AWS: Создайте Transit Gateway в целевом регионе. Для каждой VPC, которая должна быть присоединена (Spoke), создайте Transit Gateway Attachment типа "VPC". Настройте таблицы маршрутизации Transit Gateway: создайте отдельную таблицу для каждой группы сетей или примените одну таблицу ко всем присоединениям. В таблице маршрутов каждой VPC добавьте маршрут к Transit Gateway для трафика, предназначенного другим сетям. Ключевой нюанс: маршруты между присоединениями распределяются автоматически, если они связаны с одной таблицей маршрутизации Transit Gateway. Для изоляции трафика используйте разные таблицы.

Azure: Создайте центральную VNet, которая будет хабом. В этой сети создайте Virtual Network Gateway (например, для VPN или ExpressRoute). Для каждой периферийной VNet (Spoke) создайте пиринг к центральной сети. В свойствах пиринга разрешите "Use remote gateway" или "Allow gateway transit", чтобы периферийные сети могли использовать шлюз в хабе для связи друг с другом. Важно: пиринг между двумя периферийными сетями напрямую не создается автоматически, трафик проходит через хаб. Это требует правильной настройки таблиц маршрутов в каждой сети.

Google Cloud: Используйте Shared VPC. Создайте сеть в проекте-хосте (Host Project) и включите для нее режим Shared VPC. Присоедините к этой сети проекты-сервисы (Service Projects), которые будут представлять периферийные сети (Spokes). Внутри Shared VPC создайте подсети. Для маршрутизации между проектами-сервисами или для подключения внешних сетей используйте Cloud Router. Он может динамически рекламировать маршруты через BGP или статически распределять маршруты между подсетями. Подводный камень: управление IAM разрешениями для Shared VPC критически важно для безопасности.

Для более глубокого понимания архитектурных подходов при миграции, ознакомьтесь с руководством "Миграция в облако в 2026 году: стратегии для DevOps инженеров от Rehost до Refactor", где разбираются фундаментальные стратегии интеграции инфраструктуры.

Таблицы маршрутов (Route Tables): управление трафиком под микроскопом

Таблицы маршрутов остаются основным инструментом для тонкого контроля трафика в облаке, но их управление отличается от традиционных сетей.

В AWS таблица маршрутов привязывается к подсети (Subnet). Каждая VPC имеет главную таблицу маршрутов, но вы можете создать дополнительные таблицы и ассоциировать их с конкретными подсетями. Это позволяет, например, направлять трафик из подсети разработки через сетевой виртуальный аппарат (NVA) для inspection, а трафик из подсети производства - напрямую к Transit Gateway. Команда для просмотра эффективных маршрутов для экземпляра: aws ec2 describe-route-tables --filter Name=vpc-id,Values=vpc-id.

В Azure таблица маршрутов (Route Table) создается как отдельный ресурс и затем ассоциируется с подсетью. Это дает схожую с AWS гибкость. Вы можете создать маршрут с адресом назначения 0.0.0.0/0 и следующим прыжком "VirtualAppliance", чтобы направлять весь трафик подсети через ваш NVA. Для диагностики используйте az network route-table list и проверяйте эффективные маршруты для интерфейса сетевой карты (NIC).

В Google Cloud таблицы маршрутов являются частью сети (VPC) и не могут быть явно ассоциированы с подсетью напрямую. Маршруты применяются на уровне всей сети. Однако вы можете управлять трафиком на уровне экземпляров ВМ через теги сетевых интерфейсов и статические маршруты с указанием тегов. Для создания маршрута, который применяется только к ВМ с определенным тегом, используйте команду gcloud compute routes create с параметром --tags. Это менее гибко, чем подсетевой подход, но позволяет реализовать базовую изоляцию.

Пример практического применения: создание "черной дыры" для безопасности. Если вы обнаружили вредоносный трафик с определенного IP, вы можете добавить в таблицу маршрутов маршрут с адресом назначения этого IP и следующим прыжком "blackhole" (в AWS) или "None" (в Azure). Это мгновенно блокирует трафик без изменения правил безопасности групп.

Подключение локального ЦОД: VPN, Dedicated Interconnect и Direct Connect

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

Site-to-Site VPN - самый простой и быстрый способ. Вы создаете VPN-туннель между вашим локальным VPN-оборудованием и облачным VPN-шлюзом (AWS Site-to-Site VPN, Azure VPN Gateway, Google Cloud VPN). Это решение не требует физической инфраструктуры от провайдера, дешевле в установке, но имеет ограниченную пропускную способность (обычно до 1.25 Гбит/с на туннель) и более высокую задержку. Маршрутизация обычно статическая: вы указываете локальные сети в конфигурации туннеля, и облачный шлюз добавляет соответствующие маршруты.

Dedicated Interconnect (Google Cloud), ExpressRoute (Azure), Direct Connect (AWS) - выделенные физические каналы связи. Они предоставляют прямое соединение между вашим ЦОД и сетью провайдера через партнера-оператора связи. Эти решения дороже, требуют больше времени на установку (несколько недель), но предлагают высокую пропускную способность (от 1 Гбит/с до 10 Гбит/с и выше), низкую задержку и строгие SLA по доступности. Здесь динамическая маршрутизация через BGP становится стандартом: ваш локальный маршрутизатор устанавливает BGP-сессию с облачным шлюзом и рекламирует маршруты локальных сетей.

Выбор метода зависит от требований. Для временных рабочих нагрузок, разработки или резервного канала достаточно VPN. Для постоянных производственных нагрузок с требованием высокой пропускной способности и низкой задержки, таких как миграция баз данных или синхронная репликация, необходим выделенный канал. При планировании гибридной инфраструктуры важно также оценить общую стоимость владения (TCO), которая включает не только сетевые компоненты.

Пошаговая инструкция: настраиваем гибридную сеть с динамической маршрутизацией

Рассмотрим типовый сценарий: подключение локального ЦОД с сетью 10.0.0.0/16 к облачной инфраструктуре для использования динамической маршрутизации через BGP.

Для AWS с Direct Connect:

1. Заказать и настроить порт Direct Connect через партнера AWS.
2. В консоли AWS создать Direct Connect Gateway.
3. Создать Virtual Interface (Private VIF) и ассоциировать его с Direct Connect Gateway.
4. Создать Transit Gateway и присоединить к нему необходимые VPC (Attachments).
5. Ассоциировать Direct Connect Gateway с Transit Gateway.
6. На локальном маршрутизаторе настроить BGP-сессию с использованием IP адресов и ASN, предоставленных AWS.
7. Рекламировать маршруты локальной сети (10.0.0.0/16) в облако и принимать маршруты облачных VPC от AWS.

Для Azure с ExpressRoute:

1. Заказать канал ExpressRoute через партнера Microsoft.
2. Создать ресурс ExpressRoute Circuit в Azure.
3. Создать ExpressRoute Gateway и связать его с целевой VNet (хабом).
4. Настроить пиринг между ExpressRoute Circuit и ExpressRoute Gateway.
5. На локальном маршрутизаторе настроить BGP-сессию с параметрами из конфигурации ExpressRoute.
6. Рекламировать локальные маршруты и принимать маршруты Azure.

Для Google Cloud с Partner Interconnect:

1. Заказать соединение Partner Interconnect через партнера-оператора.
2. В Google Cloud создать ресурс Interconnect Attachment.
3. Создать Cloud Router в сети, которая будет принимать локальные маршруты.
4. На Cloud Router настроить BGP-сессию, указав параметры из Interconnect Attachment.
5. На локальном маршрутизаторе настроить соответствующую BGP-сессию.

Критически важный шаг для всех провайдеров - проверка MTU. Для выделенных каналов часто требуется настроить MTU 1500 (или меньше, если используются дополнительные заголовки), чтобы избежать фрагментации пакетов. Также убедитесь, что IP-адресация локальной сети и облачных подсетей не пересекается, чтобы избежать конфликтов маршрутизации.

Стоимость и производительность: что выбрать для вашего сценария

Финансовые и эксплуатационные характеристики сильно влияют на выбор архитектуры.

Стоимость:

• AWS Transit Gateway: Фиксированная плата за каждый хаб (около $0.05/час) + плата за обработку данных ($0.02/GB для данных, проходящих через хаб). Плата за присоединение (Attachment) отсутствует.
• Azure VNet Peering: Бесплатно для пиринга внутри региона. Межрегиональный пиринг оплачивается по тарифам исходящего трафика между регионами (например, $0.01/GB из US West в US East).
• Google Cloud: Cloud Router стоит около $0.05/час за каждый экземпляр. Трафик между сетями в одном регионе оплачивается по стандартным тарифам ($0.01/GB). Межрегиональный трафик дороже.

Для сценария с 10 VPC в одном регионе и умеренным трафиком (100 GB/month) между ними, Transit Gateway может стоить около $50-70 в месяц (хаб + обработка данных), Azure VNet Peering будет практически бесплатным, а Google Cloud решение - около $40-50 (роутер + трафик). Однако для глобальной сети с множеством регионов Azure модель может стать дороже из-за межрегионального трафика.

Производительность:

• Задержка (Latency): Внутрирегиональный пиринг/Transit Gateway обеспечивает задержку менее 1-2 мс. Межрегиональный трафик зависит от расстояния между регионами провайдера и может составлять 20-100 мс.
• Пропускная способность: Site-to-Site VPN обычно ограничена пропускной способностью одного туннеля (до 1.25 Гбит/с). Выделенные каналы (Direct Connect, ExpressRoute, Interconnect) предоставляют гарантированную пропускную способность заказанного порта (1, 10 Гбит/с). Пропускная способность между VPC через пиринг или Transit Gateway ограничена общей пропускной способностью облачной сети провайдера и обычно очень высока.

Эти цифры являются ориентировочными. Актуальные тарифы и показатели производительности следует проверять на официальных сайтах провайдеров, так как они меняются.

Практические рекомендации: AWS, Azure или Google Cloud для вашей задачи

Выбор провайдера зависит от вашей текущей инфраструктуры, будущих требований к масштабированию и бюджета.

Если ваша архитектура требует централизованного управления трафиком для десятков или сотен VPC, строгой модели Hub-and-Spoke с единой точкой контроля безопасности и мониторинга, а также глубокой интеграции с гибридным подключением через Direct Connect - выбирайте AWS Transit Gateway.

Если вы строите глобальную распределенную сеть с множеством регионов, где необходима прямая связность между всеми сетями (mesh), и хотите минимизировать сложность управления транзитными шлюзами - Azure VNet Peering с его глобальным пирингом будет эффективным выбором.

Если ваша организация уже глубоко интегрирована в экосистему Google Cloud, использует Shared VPC для управления ресурсами нескольких проектов и требует детального контроля через IAM - оптимальным решением будет Google Cloud VPC с Cloud Router для динамической маршрутизации.

Для мультиоблачных конфигураций ни один из нативных сервисов провайдеров не предлагает прямого решения. Вам придется использовать сетевые виртуальные аппараты (NVA) с BGP или рассмотреть сторонние решения мультиоблачных транзитных хабов. Также учитывайте фактор vendor lock-in: глубокое внедрение специфичного сервиса одного провайдера увеличивает сложность будущей миграции на другую платформу. Чтобы лучше понять обязанности и компетенции при работе с разными облаками, полезно ознакомиться с материалом "DevOps в облаке 2026: ключевые обязанности и компетенции в AWS, Azure и GCP".

Взгляд в 2026: тренды и будущее облачной маршрутизации

Тенденции развития указывают на дальнейшую абстракцию и автоматизацию сетевого уровня. Конфигурация через декларативные инструменты, такие как Terraform или Crossplane, становится стандартом. Вы описываете желаемое состояние сети ("все VPC в регионе US-West должны быть связаны через Transit Gateway"), и инструмент создает и управляет ресурсами, поддерживая это состояние.

Интеграция с сервисами безопасности усиливается. Ожидается, что транзитные хабы, подобные AWS Transit Gateway, будут предлагать встроенные возможности сквозного inspection трафика, например, интеграцию с облачными firewall без необходимости прокладывать трафик через отдельные NVA.

Развитие eBPF и технологий на его основе, таких как Cilium, начинает трансформировать маршрутизацию внутри Kubernetes кластеров в облаке. Это позволяет определять сложные сетевые политики на уровне приложений, минуя традиционные механизмы маршрутизации на уровне сети.

Появление "мультиоблачных" транзитных хабов от независимых вендоров (например, от Aviatrix или Alkira) может упростить управление сетями, распределенными между AWS, Azure и Google Cloud. Эти решения предлагают единую плоскость управления для маршрутизации и безопасности across clouds.

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

Для автоматизации и управления такой инфраструктурой может быть полезен сервис AiTunnel, который предоставляет единый API для интеграции с множеством AI моделей, что может помочь в создании инструментов мониторинга и анализа сетевых политик.