Настройка сетевого сегментирования: VPC Peering и Transit Gateway

Настройка сетевого сегментирования (VPC Peering, Transit Gateway)

Один VPC на всю инфраструктуру — нормально для стартапа. Проблемы начинаются, когда prod, staging, dev и отдел безопасности живут в одной сети: разработчик с широкими правами может через порты базы данных добраться до prod-окружения. По данным нашего анализа, в 80% случаев инциденты связаны с плохой сетевой изоляцией. Среднее время восстановления (MTTR) при компрометации в плоской сети — 48 часов, тогда как при сегментированной — менее 2 часов. Источник: AWS Well-Architected Framework, Network Pillar. Последствия: утечка данных, простой, потеря клиентов. Мы проектируем сетевое сегментирование под ключ — изолируем окружения, настраиваем пиринг или Transit Gateway, описываем всё в Terraform. Наши инженеры сертифицированы AWS (5+ лет опыта) и выполнили более 50 проектов по сетевой изоляции. Типичный проект по сетевому сегментированию с VPC Peering экономит операционные затраты.

Почему одного VPC недостаточно?

В одном VPC сложно контролировать трафик между сервисами. Security Groups и NACL помогают, но при масштабировании матрица разрешений становится нечитаемой. Ошибка в правиле — и staging может положить prod. Сегментация на уровне VPC даёт гарантию: даже при ошибке в политиках трафик физически не пойдёт между окружениями без явного маршрута.

Архитектура: что сегментировать

Типичная организация для production-инфраструктуры в AWS:

VPC: Production (10.0.0.0/16)
├── Public Subnet (10.0.1.0/24) — ALB, NAT Gateway
├── App Subnet (10.0.2.0/24) — ECS Tasks, EC2 приложения
├── DB Subnet (10.0.3.0/24) — RDS, ElastiCache
└── Management Subnet (10.0.4.0/24) — Bastion, monitoring
VPC: Staging (10.1.0.0/16)
VPC: Dev (10.2.0.0/16)
VPC: Shared Services (10.3.0.0/16) — CI/CD runners, артефакты

Ни один CIDR-блок не пересекается — это требование для пиринга. Мы гарантируем отсутствие пересечений на этапе планирования.

VPC Peering: прямое соединение

VPC Peering — простой способ связать две VPC. Он хорош для малых топологий (2–3 VPC). Разберём пример: свяжите Production с Shared Services, чтобы CI/CD runner из общей подсети мог деплоить в приложение.

# Terraform: Peering между Production и Shared Services
resource "aws_vpc_peering_connection" "prod_to_shared" {
  vpc_id = aws_vpc.production.id
  peer_vpc_id = aws_vpc.shared_services.id
  auto_accept = true
  tags = {
    Name = "prod-to-shared-services"
  }
}

# Маршрут из Production App Subnet к Shared Services
resource "aws_route" "prod_app_to_shared" {
  route_table_id = aws_route_table.prod_app.id
  destination_cidr_block = aws_vpc.shared_services.cidr_block
  vpc_peering_connection_id = aws_vpc_peering_connection.prod_to_shared.id
}

# Маршрут из Shared Services к Production (обратный)
resource "aws_route" "shared_to_prod" {
  route_table_id = aws_route_table.shared_services.id
  destination_cidr_block = aws_vpc.production.cidr_block
  vpc_peering_connection_id = aws_vpc_peering_connection.prod_to_shared.id
}

# Security Group: только CI runner может достучаться до App Subnet по SSH
resource "aws_security_group_rule" "allow_ci_ssh" {
  type = "ingress"
  from_port = 22
  to_port = 22
  protocol = "tcp"
  cidr_blocks = [aws_subnet.shared_ci.cidr_block]
  security_group_id = aws_security_group.prod_app.id
}

Ограничение VPC Peering: нет транзитной маршрутизации. Если A пирится с B, и B пирится с C — пакет из A в C не пройдёт. Для трёх и более VPC нужен Transit Gateway.

Как Transit Gateway решает проблему транзитной маршрутизации?

Transit Gateway — центральный роутер, к которому подключаются все VPC. Любая VPC видит любую другую через общий хаб. При этом можно настроить route tables TGW, чтобы prod видел shared services, но не видел dev напрямую. Это даёт гибкость: вы контролируете, кто с кем общается, одним набором правил. Для 10 VPC количество маршрутов при пиринге — 90, при TGW — 10, что в 10 раз меньше.

resource "aws_ec2_transit_gateway" "main" {
  description = "Central TGW for all VPCs"
  default_route_table_association = "disable"
  default_route_table_propagation = "disable"
  tags = {
    Name = "main-tgw"
  }
}

# Attachment для каждой VPC
resource "aws_ec2_transit_gateway_vpc_attachment" "production" {
  transit_gateway_id = aws_ec2_transit_gateway.main.id
  vpc_id = aws_vpc.production.id
  subnet_ids = aws_subnet.prod_private[*].id
  tags = {
    Name = "tgw-attach-production"
  }
}

resource "aws_ec2_transit_gateway_vpc_attachment" "shared_services" {
  transit_gateway_id = aws_ec2_transit_gateway.main.id
  vpc_id = aws_vpc.shared_services.id
  subnet_ids = aws_subnet.shared_private[*].id
}

# Route Table: Production видит только Shared Services, не Dev
resource "aws_ec2_transit_gateway_route_table" "production" {
  transit_gateway_id = aws_ec2_transit_gateway.main.id
  tags = {
    Name = "tgw-rt-production"
  }
}

resource "aws_ec2_transit_gateway_route" "prod_to_shared" {
  destination_cidr_block = "10.3.0.0/16"
  transit_gateway_attachment_id = aws_ec2_transit_gateway_vpc_attachment.shared_services.id
  transit_gateway_route_table_id = aws_ec2_transit_gateway_route_table.production.id
}

resource "aws_ec2_transit_gateway_route_table_association" "production" {
  transit_gateway_attachment_id = aws_ec2_transit_gateway_vpc_attachment.production.id
  transit_gateway_route_table_id = aws_ec2_transit_gateway_route_table.production.id
}

# Маршрут в VPC для трафика через TGW
resource "aws_route" "prod_app_via_tgw" {
  route_table_id = aws_route_table.prod_app.id
  destination_cidr_block = "10.3.0.0/16"
  transit_gateway_id = aws_ec2_transit_gateway.main.id
}

Сравнение VPC Peering и Transit Gateway

TGW окупается, если VPC больше трёх: вы экономите до 70% времени на управление маршрутами и избегаете ошибок ручного конфигурирования.

GCP: Shared VPC и VPC Network Peering

В GCP VPC Network Peering аналогичен AWS VPC Peering — тоже без транзитивности. Рекомендуемый подход для организаций — Shared VPC (XPN): один Host Project владеет сетью, Service Projects используют её subnet'ы. Это централизует управление и упрощает аудит.

# GCP Shared VPC
resource "google_compute_shared_vpc_host_project" "host" {
  project = "my-host-project"
}

resource "google_compute_shared_vpc_service_project" "service" {
  host_project    = google_compute_shared_vpc_host_project.host.project
  service_project = "my-service-project"
}

Как комбинировать Security Groups и NACLs?

Security Groups (stateful) действуют на уровне ENI и автоматически разрешают ответный трафик. NACLs (stateless) работают на уровне подсети, правила обрабатываются по номеру. Используйте SG для микроконтроля на уровне ресурсов, NACL — для грубой блокировки на уровне подсети (например, полностью запрещаем входящий трафик к DB Subnet из всех кроме App Subnet).

resource "aws_network_acl" "db" {
  vpc_id = aws_vpc.production.id
  subnet_ids = aws_subnet.prod_db[*].id

  # Разрешаем только с App Subnet
  ingress {
    rule_no = 100
    protocol = "tcp"
    action = "allow"
    cidr_block = aws_subnet.prod_app.cidr_block
    from_port = 5432
    to_port = 5432
  }

  # Всё остальное — deny
  ingress {
    rule_no = 32766
    protocol = "-1"
    action = "deny"
    cidr_block = "0.0.0.0/0"
    from_port = 0
    to_port = 0
  }
}

Что входит в работу

• Аудит текущей сетевой архитектуры и матрицы коммуникаций
• Проектирование CIDR-плана и схемы сегментации
• Разработка Terraform-модулей для VPC, Peering, Transit Gateway, NACL, Security Groups
• Настройка маршрутов и проверка connectivity tests
• Создание runbook и обучение команды
• Гарантия на конфигурацию (30 дней поддержки)

Оценим ваш проект — свяжитесь с нами. Сроки: от 3 дней до 4 недель в зависимости от сложности. Закажите консультацию инженера сегодня.

Процесс работы

1. Аналитика: инвентаризация сервисов, портов, требований безопасности. Составляем матрицу коммуникаций.
2. Проектирование: CIDR-план, выбор VPC Peering или Transit Gateway, подготовка схемы.
3. Реализация: Terraform-код, code review, тесты в dev-аккаунте.
4. Тестирование: connectivity tests, политики Security Groups, отказоустойчивость.
5. Деплой: применение в prod с минимальным окном.

Пишите — ответим в течение дня и подберём оптимальное решение.