Налаштування мережевого сегментування: 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 з мінімальним вікном.

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