VPC и сетевая изоляция

В 2019 году Capital One потеряла данные 100 млн клиентов из-за misconfigured WAF на EC2 в AWS. Уязвимость: EC2 имела IAM-роль с избыточными правами, а сетевая изоляция не ограничивала metadata endpoint. Правильная VPC-архитектура с NACLs и Security Groups могла существенно ограничить ущерб.

• **PCI DSS compliance:** оплата картами требует изоляции cardholder data environment - отдельный VPC или subnet с жёсткими NACLs
• **Multi-account AWS:** каждый аккаунт имеет свой VPC; Transit Gateway объединяет production, staging, shared-services
• **Hybrid cloud:** VPN или Direct Connect подключает on-premise сеть к VPC как ещё один subnet

Subnets и CIDR

Когда AWS запустила EC2 в 2006 году, все инстансы жили в одной общей сети - любой мог попробовать достучаться до чужого сервера. В 2009 году появился VPC: виртуальная частная сеть, которую каждый аккаунт получает в полное владение. IP-диапазон, subnets, таблицы маршрутизации - полный контроль.

**CIDR (Classless Inter-Domain Routing)** - нотация для IP-диапазонов. 10.0.0.0/16 означает: первые 16 бит фиксированы (10.0), оставшиеся 16 бит свободны - это 65,536 адресов. Subnet делит VPC на меньшие блоки: 10.0.1.0/24 - 256 адресов в одной зоне доступности.

**Subnet привязана к одной AZ.** Для отказоустойчивости нужен один и тот же тип subnet (public/private) в каждой AZ. ALB требует minimum 2 public subnets в разных AZ.

Security Groups vs NACLs

AWS предоставляет два уровня файрвола. **Security Group** - stateful файрвол на уровне инстанса (EC2, RDS, Lambda). **Network ACL (NACL)** - stateless файрвол на уровне subnet. Большинство архитектур используют Security Groups как основной инструмент, NACL как дополнительный слой.

**Stateful vs stateless** - ключевое различие. Security Group помнит: если входящий пакет разрешён, ответный трафик автоматически пропускается без явного правила. NACL не помнит: для ответного трафика нужно явное правило в обоих направлениях.

NAT Gateway и маршрутизация

Инстанс в private subnet не имеет публичного IP. Но ему нужен доступ в интернет: скачать обновления пакетов, обратиться к внешнему API, отправить логи. Для этого служит **NAT Gateway**: он находится в public subnet, имеет Elastic IP, и транслирует адреса из private subnet во внешний трафик.

**Таблица маршрутизации (Route Table)** определяет, куда идут пакеты из subnet. Каждая subnet ассоциирована с одной route table. Правила: local (трафик внутри VPC идёт напрямую), 0.0.0.0/0 через Internet Gateway (для public), 0.0.0.0/0 через NAT Gateway (для private).

**NAT Gateway vs NAT Instance:** NAT Gateway - managed сервис AWS (высокодоступный, масштабируется автоматически, до 45 Gbps). NAT Instance - обычный EC2 с IP forwarding (дешевле для малых объёмов, требует управления). Для production - всегда NAT Gateway.

VPC Peering и Transit Gateway

Компания растёт. Теперь три VPC: production, staging, shared-services (мониторинг, CI/CD). Как им общаться? **VPC Peering** - прямое соединение между двумя VPC через AWS backbone (без интернета). Трафик идёт внутри AWS, задержка минимальная.

Проблема peering: оно **нетранзитивное**. VPC-A подключена к VPC-B, VPC-B к VPC-C. Но VPC-A и VPC-C не видят друг друга. При 10 VPC нужно 45 peering соединений. Решение: **Transit Gateway** - центральный хаб, к которому подключаются все VPC через одно соединение.

**Стоимость:** VPC Peering - только за трафик ($0.01/GB inter-AZ). Transit Gateway - $0.05/час за attachment + $0.02/GB. При небольшом числе VPC peering дешевле. При 5+ VPC Transit Gateway выгоднее операционно.

VPC и сетевая изоляция

• VPC - изолированная виртуальная сеть; CIDR задаёт диапазон IP; subnet = диапазон в одной AZ
• Public subnet имеет маршрут к Internet Gateway; private - только через NAT Gateway
• Security Group - stateful файрвол на уровне инстанса; NACL - stateless на уровне subnet
• NAT Gateway транслирует исходящий трафик из private subnets; входящий из интернета блокируется
• VPC Peering - прямое нетранзитивное соединение; Transit Gateway - централизованный хаб для N VPC

Связанные темы

VPC - основа для размещения любых cloud-ресурсов в изолированной сети.

• Managed Databases: RDS, Cloud SQL — RDS всегда размещается в VPC private subnet - Security Groups контролируют доступ
• Load Balancing и Auto Scaling — ALB размещается в public subnets; EC2 Auto Scaling группы - в private subnets
• Serverless: Lambda, Cloud Functions — Lambda в VPC требует ENI в private subnet для доступа к RDS и внутренним сервисам

Вопросы для размышления

• Почему RDS в production всегда должна быть в private subnet, даже если Security Group ограничивает доступ?
• Когда оправдан отдельный NAT Gateway в каждой AZ, несмотря на дополнительные расходы?
• Как архитектура VPC влияет на возможность выполнения требований PCI DSS или HIPAA?

Связанные уроки

• net-50-cloud-networking