Принципы сетевой маршрутизации в AWS, Azure и GCP: от VPC до централизованных решений

Сетевая маршрутизация определяет, как трафик перемещается между ресурсами в вашей облачной инфраструктуре. Без корректной настройки таблиц маршрутизации, шлюзов и правил пиринга даже простейшие сервисы не смогут общаться друг с другом или с интернетом. В этой статье мы сравним реализацию базовых принципов маршрутизации в трех основных публичных облаках - Amazon Web Services (AWS), Microsoft Azure и Google Cloud Platform (GCP) - и перейдем к централизованным решениям для масштабирования.

Вы получите конкретные, проверенные инструкции для каждой платформы, готовые фрагменты кода Terraform и узнаете, когда стандартного пиринга VPC недостаточно и стоит переходить на AWS Transit Gateway или Azure Virtual WAN. Эта информация сэкономит часы на сопоставлении документации и снизит риск ошибок конфигурации в рабочей среде.

Базовые принципы: как устроена маршрутизация в облачных VPC

В модели общей ответственности за облако провайдер обеспечивает физическую сетевую инфраструктуру, а клиент управляет логической маршрутизацией внутри своих виртуальных сетей. Ключевые сущности для этого - виртуальная частная облачная сеть (VPC/VNet), таблица маршрутизации (Route Table) и различные типы шлюзов (Gateway).

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

Таблица маршрутов: главный диспетчер трафика в вашей VPC

Таблица маршрутов состоит из записей, где каждой целевой сети (Destination CIDR) соответствует Next Hop Target. Например, запись 0.0.0.0/0 → igw-0a123456 отправляет весь трафик в интернет через Internet Gateway.

По умолчанию в новой VPC создается главная таблица маршрутов (main route table). Ее ключевая особенность - автоматическая привязка ко всем новым подсетям, если явно не указать другую. В AWS она содержит только локальный маршрут для самой VPC (например, 10.0.0.0/16 → local). В Azure новая таблица маршрутов пуста, но системные маршруты (включая локальный) существуют неявно. В GCP каждая сеть получает системные маршруты по умолчанию, а пользовательские создаются отдельно.

Приоритет маршрута определяется по принципу наиболее специфичного префикса (Longest Prefix Match). Маршрут 10.0.1.0/24 имеет приоритет над 10.0.0.0/16 для трафика в сеть 10.0.1.5. Если в таблице нет подходящего маршрута, трафик отбрасывается.

Проблема «инстанс в приватной подсети не видит интернет» часто возникает из-за отсутствия маршрута 0.0.0.0/0 через NAT Gateway. Вместо этого таблица может содержать только локальный маршрут или маршрут через Internet Gateway, который не поддерживает входящие соединения из интернета в приватные подсети.

Типы шлюзов: выход в интернет и подключение к внешним сетям

Выбор шлюза зависит от требований к доступности и стоимости.

Стоимость варьируется: например, AWS NAT Gateway в июле 2026 стоит около $0.045 за час работы плюс $0.045 за каждый гигабайт обработанного трафика. Azure VPN Gateway базового поколения (Basic) стоит примерно $0.041 в час. В GCP Cloud NAT имеет фиксированную ставку за обработку NAT и оплату за гигабайт переданных данных.

Практическое сравнение: настраиваем пиринг между VPC на AWS, Azure и GCP

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

Мы настроим пиринг между двумя сетями: VPC A (10.0.0.0/16) и VPC B (172.16.0.0/16). Убедитесь, что блоки CIDR не пересекаются - это обязательное условие для успешного пиринга.

Шаг за шагом: пример настройки в AWS с Amazon VPC

1. В консоли AWS перейдите в сервис VPC → Peering Connections → Create Peering Connection.
2. Укажите имя, выберите Requester VPC (VPC A) и Accepter VPC (VPC B). Регион должен быть одинаковым.
3. После создания соединения его статус будет «pending acceptance». Перейдите в аккаунт, которому принадлежит VPC B (или в той же консоли, если VPC в одном аккаунте), и примите запрос.
4. Теперь нужно добавить маршруты в таблицы маршрутов обеих VPC. Для таблицы VPC A добавьте маршрут: Destination 172.16.0.0/16, Target - ID созданного пиринга (pcx-abc123). Для таблицы VPC B добавьте маршрут: Destination 10.0.0.0/16, Target - тот же ID пиринга.
5. Проверьте связность, запустив ping с инстанса EC2 в VPC A (10.0.1.10) на инстанс в VPC B (172.16.1.10). Предварительно настройте Security Groups, разрешающие ICMP трафик.

Автоматизация через AWS CLI:

PEERING_ID=$(aws ec2 create-vpc-peering-connection \
    --vpc-id vpc-12345 \
    --peer-vpc-id vpc-67890 \
    --output text --query 'VpcPeeringConnection.VpcPeeringConnectionId')

aws ec2 accept-vpc-peering-connection --vpc-peering-connection-id $PEERING_ID

aws ec2 create-route --route-table-id rtb-12345 \
    --destination-cidr-block 172.16.0.0/16 \
    --vpc-peering-connection-id $PEERING_ID

Шаг за шагом: пример настройки в Azure с Virtual Network

В Azure пиринг настраивается как двунаправленная операция, но требует явного разрешения трафика.

1. В Azure Portal откройте одну из виртуальных сетей (VNet A). Перейдите в раздел «Peerings» и нажмите «+ Add».
2. Задайте имя пиринга (например, «VNetA-to-VNetB»). В поле «Remote virtual network» выберите VNet B из того же региона.
3. Важно настроить оба направления: «Allow forwarded traffic» и «Allow gateway transit» в зависимости от архитектуры. Для базового сценария достаточно разрешить трафик («Allow forwarded traffic» = Enabled).
4. Повторите операцию из VNet B, создав пиринг «VNetB-to-VNetA».
5. Проверьте, что Network Security Groups (NSG), привязанные к подсетям или сетевым интерфейсам виртуальных машин, разрешают трафик между CIDR блоками (10.0.0.0/16 и 172.16.0.0/16). В отличие от AWS, правила NSG в Azure могут блокировать трафик даже при корректных маршрутах.
6. Проверьте связность между виртуальными машинами, расположенными в разных VNet.

В Azure маршруты добавляются автоматически при создании пиринга, что упрощает процесс по сравнению с AWS.

Шаг за шагом: пример настройки в GCP с Google VPC

Ключевое отличие GCP - глобальность таблиц маршрутов и необходимость явного создания пользовательских маршрутов для пиринга.

1. В Google Cloud Console откройте VPC Network → VPC network peering.
2. Создайте пиринг из сети A в сеть B. Укажите имя, выберите свою сеть (A) и сеть для пиринга (B). Если сети принадлежат разным проектам, укажите ID проекта сети B.
3. Повторите операцию, создав пиринг из сети B в сеть A. Пиринг в GCP не транзитивен и требует двусторонней настройки.
4. Теперь необходимо создать пользовательские маршруты (Custom Routes). В каждой сети добавьте маршрут, где Next hop будет «VPC peering». Для сети A: Destination 172.16.0.0/16, Next hop - имя пиринга (например, «peer-ab»). Для сети B: Destination 10.0.0.0/16.
5. Проверьте связность между тестовыми виртуальными машинами в разных сетях. Убедитесь, что правила брандмауэра GCP разрешают внутренний трафик между IP-адресами.

Ограничение: пиринг в GCP запрещает транзитивную маршрутизацию. Если сеть A пирится с сетью B, а сеть B пирится с сетью C, то сети A и C не будут связаны между собой.

Автоматизация инфраструктуры: готовые примеры на Terraform

Использование Infrastructure as Code (IaC) обеспечивает воспроизводимость конфигураций и снижает человеческие ошибки. Ниже приведены фрагменты Terraform для типовых задач. Убедитесь, что у вас настроены провайдеры AWS, Azure и GCP с корректными аутентификационными данными.

Пример 1: Создание VPC в AWS с публичной и приватной подсетями, а также NAT Gateway для исходящего трафика из приватной подсети.

# Создание VPC
resource "aws_vpc" "main" {
  cidr_block = "10.0.0.0/16"
  tags = {
    Name = "main-vpc"
  }
}

# Публичная подсеть для NAT Gateway
resource "aws_subnet" "public" {
  vpc_id     = aws_vpc.main.id
  cidr_block = "10.0.1.0/24"
  availability_zone = "us-east-1a"
  map_public_ip_on_launch = true
}

# Приватная подсеть для рабочих нагрузок
resource "aws_subnet" "private" {
  vpc_id     = aws_vpc.main.id
  cidr_block = "10.0.2.0/24"
  availability_zone = "us-east-1a"
}

# Internet Gateway
resource "aws_internet_gateway" "igw" {
  vpc_id = aws_vpc.main.id
}

# NAT Gateway в публичной подсети
resource "aws_eip" "nat" {
  domain = "vpc"
}
resource "aws_nat_gateway" "ngw" {
  allocation_id = aws_eip.nat.id
  subnet_id     = aws_subnet.public.id
}

# Таблица маршрутов для публичной подсети
resource "aws_route_table" "public" {
  vpc_id = aws_vpc.main.id
  route {
    cidr_block = "0.0.0.0/0"
    gateway_id = aws_internet_gateway.igw.id
  }
}

# Таблица маршрутов для приватной подсети
resource "aws_route_table" "private" {
  vpc_id = aws_vpc.main.id
  route {
    cidr_block = "0.0.0.0/0"
    nat_gateway_id = aws_nat_gateway.ngw.id
  }
}

# Ассоциация таблиц маршрутов с подсетями
resource "aws_route_table_association" "public" {
  subnet_id      = aws_subnet.public.id
  route_table_id = aws_route_table.public.id
}
resource "aws_route_table_association" "private" {
  subnet_id      = aws_subnet.private.id
  route_table_id = aws_route_table.private.id
}

Пример 2: Создание VPN-шлюза для гибридного подключения в Azure с использованием Terraform.

# Создание Resource Group
resource "azurerm_resource_group" "network" {
  name     = "rg-network-prod"
  location = "East US"
}

# Создание Virtual Network
resource "azurerm_virtual_network" "vnet" {
  name                = "vnet-prod"
  address_space       = ["10.1.0.0/16"]
  location            = azurerm_resource_group.network.location
  resource_group_name = azurerm_resource_group.network.name
}

# Создание подсети для VPN Gateway
resource "azurerm_subnet" "gateway" {
  name                 = "GatewaySubnet"
  resource_group_name  = azurerm_resource_group.network.name
  virtual_network_name = azurerm_virtual_network.vnet.name
  address_prefixes     = ["10.1.255.0/27"]
}

# Создание Public IP для VPN Gateway
resource "azurerm_public_ip" "vpngw" {
  name                = "vpngw-pip"
  location            = azurerm_resource_group.network.location
  resource_group_name = azurerm_resource_group.network.name
  allocation_method   = "Dynamic"
}

# Создание VPN Gateway (используется поколение VpnGw1)
resource "azurerm_virtual_network_gateway" "vpngw" {
  name                = "vpngw-prod"
  location            = azurerm_resource_group.network.location
  resource_group_name = azurerm_resource_group.network.name
  type     = "Vpn"
  vpn_type = "RouteBased"
  sku      = "VpnGw1"
  ip_configuration {
    name                          = "vpngw-config"
    public_ip_address_id          = azurerm_public_ip.vpngw.id
    private_ip_address_allocation = "Dynamic"
    subnet_id                     = azurerm_subnet.gateway.id
  }
}

Масштабирование: когда базового пиринга недостаточно. Централизованные решения

Прямой пиринг «каждая с каждым» (full-mesh) становится неуправляемым при росте числа VPC. Для N сетей потребуется N*(N-1)/2 пиринговых соединений. Например, для 10 VPC это 45 отдельных подключений. Проблемы включают сложность управления маршрутами, отсутствие транзитивности (трафик из сети A не может пройти через сеть B в сеть C) и высокие операционные издержки.

Решение - архитектура «звезда» (Hub-and-Spoke), где множество периферийных сетей (Spokes) подключаются к центральному хабу. Хаб обеспечивает транзитивную маршрутизацию и служит единой точкой управления. AWS предлагает для этого AWS Transit Gateway, а Azure - Azure Virtual WAN.

AWS Transit Gateway: хаб для всей вашей облачной сети

AWS Transit Gateway (TGW) - это региональный управляемый сервис. Вы подключаете к нему VPC, VPN-соединения и Direct Connect через ресурсы типа Attachment. Каждое Attachment ассоциируется с одной или несколькими таблицами маршрутов внутри самого Transit Gateway.

Маршруты могут распространяться статически или динамически через BGP (в случае VPN или Direct Connect Attachment). TGW поддерживает до 5000 VPC Attachment на регион (лимит на июль 2026) и обеспечивает пропускную способность до 50 Гбит/с на один VPN Attachment.

Пример настройки подключения двух VPC к Transit Gateway с помощью Terraform:

resource "aws_ec2_transit_gateway" "tgw" {
  description = "Central transit gateway"
}

resource "aws_ec2_transit_gateway_vpc_attachment" "vpc1" {
  subnet_ids         = [aws_subnet.vpc1_tgw.id]
  transit_gateway_id = aws_ec2_transit_gateway.tgw.id
  vpc_id             = aws_vpc.vpc1.id
}

resource "aws_ec2_transit_gateway_vpc_attachment" "vpc2" {
  subnet_ids         = [aws_subnet.vpc2_tgw.id]
  transit_gateway_id = aws_ec2_transit_gateway.tgw.id
  vpc_id             = aws_vpc.vpc2.id
}

# Таблица маршрутов в Transit Gateway
resource "aws_ec2_transit_gateway_route_table" "tgw_rt" {
  transit_gateway_id = aws_ec2_transit_gateway.tgw.id
}

# Ассоциация Attachment с таблицей маршрутов
resource "aws_ec2_transit_gateway_route_table_association" "vpc1_assoc" {
  transit_gateway_attachment_id  = aws_ec2_transit_gateway_vpc_attachment.vpc1.id
  transit_gateway_route_table_id = aws_ec2_transit_gateway_route_table.tgw_rt.id
}
resource "aws_ec2_transit_gateway_route_table_association" "vpc2_assoc" {
  transit_gateway_attachment_id  = aws_ec2_transit_gateway_vpc_attachment.vpc2.id
  transit_gateway_route_table_id = aws_ec2_transit_gateway_route_table.tgw_rt.id
}

# Добавление маршрутов
resource "aws_ec2_transit_gateway_route" "route_to_vpc2" {
  destination_cidr_block         = "10.2.0.0/16"
  transit_gateway_attachment_id  = aws_ec2_transit_gateway_vpc_attachment.vpc2.id
  transit_gateway_route_table_id = aws_ec2_transit_gateway_route_table.tgw_rt.id
}

Более подробное сравнение архитектур централизованной маршрутизации вы найдете в статье о динамической маршрутизации в облаках 2026.

Azure Virtual WAN: единая точка входа для гибридной сети

Azure Virtual WAN - это более высокоуровневая абстракция по сравнению с Transit Gateway. Он объединяет возможности подключения (Site-to-Site VPN, ExpressRoute, удаленных пользователей через Point-to-Site VPN) и продвинутые сервисы безопасности (например, Azure Firewall) в единую управляемую службу.

Ключевые компоненты:

• Hub: региональный виртуальный хаб, развертываемый автоматически. В нем размещаются шлюзы VPN, ExpressRoute и другие сервисы.
• VPN sites: представления ваших локальных сетевых устройств (VPN-концентраторов).
• ExpressRoute circuits: выделенные каналы подключения к Azure.

Virtual WAN хорошо подходит для крупных распределенных предприятий, которым нужна глобальная сеть с интеграцией партнерских SD-WAN решений. В отличие от AWS Transit Gateway, который больше ориентирован на управление маршрутизацией между VPC, Azure Virtual WAN охватывает более широкий спектр гибридных сценариев.

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

Частые ошибки и лучшие практики сетевой маршрутизации

Ошибки конфигурации - основная причина проблем со связностью. Вот список типичных проблем и способы их устранения.

1. Конфликт IP-адресов. Пересекающиеся блоки CIDR в пирингуемых VPC/VNet делают пиринг невозможным или нарушают маршрутизацию. Решение: использовать уникальные блоки адресов для всех сетей в рамках организации (например, 10.0.0.0/16 для AWS, 172.16.0.0/16 для Azure, 192.168.0.0/16 для локальной сети). Документируйте схему IP-адресации.
2. Забытые маршруты. После создания пиринга маршрут в таблицу маршрутов удаленной сети добавлен только на одной стороне. Трафик достигает целевой сети, но ответный трафик не имеет пути назад. Решение: всегда проверяйте таблицы маршрутов на обеих сторонах соединения. Используйте Terraform для одновременного создания пиринга и маршрутов.
3. Блокировка трафика сетевыми ACL или Security Groups. Особенно актуально для Azure, где Network Security Groups (NSG) могут блокировать трафик между подсетями даже внутри одного VNet. В AWS Security Groups по умолчанию запрещают весь входящий трафик. Решение: настройте правила, разрешающие трафик между CIDR блоками пирингуемых сетей. Для диагностики временно установите разрешающее правило для всего трафика (0.0.0.0/0), проверьте связность, а затем ужесточите правила.
4. Отсутствие транзитивности в базовом пиринге. Если сеть A пирится с сетью B, а сеть B пирится с сетью C, то между сетями A и C прямой связи нет. Трафик не будет маршрутизироваться транзитивно. Решение: используйте централизованные решения - AWS Transit Gateway или Azure Virtual WAN, которые обеспечивают транзитивность по умолчанию.

Методы отладки:

• Traceroute: Запустите traceroute (Linux) или tracert (Windows) с исходного хоста до целевого IP. Это покажет, на каком хопе трафик останавливается.
• Проверка таблиц маршрутов на инстансе: В Linux используйте ip route show, в Windows - route print. Убедитесь, что маршрут к целевой сети существует и Next Hop указан корректно.
• Flow Logs: Включите VPC Flow Logs в AWS или NSG Flow Logs в Azure. Они записывают информацию о принятых и отклоненных пакетах, что помогает определить, блокирует ли трафик сетевая ACL или Security Group.

Лучшие практики:

• Применяйте Infrastructure as Code (Terraform, CloudFormation, ARM Templates) для всех сетевых ресурсов. Это гарантирует воспроизводимость и позволяет отслеживать изменения через систему контроля версий.
• Реализуйте сегрегацию сетей по назначению (например, отдельные VPC для продакшена, разработки и DMZ) и используйте централизованные решения для их соединения.
• Регулярно проводите аудит сетевых конфигураций на предмет неиспользуемых таблиц маршрутов, пиринговых соединений и шлюзов, чтобы сократить издержки.
• Для гибридных сценариев рассмотрите возможность использования динамической маршрутизации через BGP (при подключении через VPN или Direct Connect/ExpressRoute) для автоматического обмена маршрутами при изменениях в сети. Подробнее о протоколах динамической маршрутизации читайте в статье про OSPF, BGP и EIGRP.

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