Сеть в AWS — это не «галочки где-то в консоли», а то, что определяет главный вопрос: кто до кого может достучаться. От неё зависит и безопасность (не смотрит ли база наружу?), и работоспособность (видит ли приложение базу?). Хорошая новость: вся модель строится из нескольких понятных кирпичиков, и собрать её в голове можно за один заход.

Представьте, что AWS — это огромное здание дата-центра, а вы арендуете в нём собственный изолированный этаж со своей разводкой проводов. Никто чужой на ваш этаж не попадёт, а вы сами решаете, какие двери открыть наружу. Этот «личный этаж» и есть VPC. Если базовые понятия облака ещё не на руках, начните с основ AWS, а сюда возвращайтесь за сетевой моделью целиком.

Что такое VPC

VPC (Virtual Private Cloud) — это ваша изолированная виртуальная сеть внутри AWS. У неё есть свой диапазон IP-адресов, который задаётся через CIDR — запись вида 10.0.0.0/16. Цифра после слэша говорит, сколько адресов в диапазоне: /16 — это около 65 тысяч адресов, /24 — около 256. Чем меньше число, тем больше адресов.

Внутри VPC ничего чужого нет: это ваше адресное пространство, и трафик между двумя VPC не ходит, пока вы это явно не разрешите. Создаётся VPC одной командой, а дальше вы наполняете её подсетями.

aws ec2 create-vpc --cidr-block 10.0.0.0/16

Подсети: public и private

Большой диапазон VPC разрезают на куски поменьше — подсети (subnet). Каждая подсеть живёт ровно в одной зоне доступности (availability zone — отдельный физический дата-центр внутри региона). Это важно для надёжности: если положить всё в одну зону, авария в ней унесёт весь сервис.

Главное деление подсетей — на public и private. Разница только в одном: есть ли у подсети дорога в интернет.

  • Public-подсеть имеет маршрут наружу. Сюда ставят то, что должно быть доступно из интернета: балансировщик нагрузки, иногда bastion-хост для входа по SSH.
  • Private-подсеть прямого выхода в интернет не имеет. Сюда ставят приложения, базы данных, кэши — всё, до чего снаружи не должно быть доступа.

Аналогия: public-подсеть — это ресепшен в офисе, куда заходят посетители с улицы. Private-подсеть — кабинеты внутри, куда с улицы не попасть.

Типовая схема почти любого приложения выглядит так: балансировщик в public-подсети, приложение и база — в private, и всё это продублировано в нескольких зонах доступности ради отказоустойчивости.

aws ec2 create-subnet --vpc-id vpc-0abc --cidr-block 10.0.1.0/24 --availability-zone eu-central-1a
aws ec2 create-subnet --vpc-id vpc-0abc --cidr-block 10.0.2.0/24 --availability-zone eu-central-1b

Маршрутизация: куда уходит трафик

Подсеть сама по себе не «знает», public она или private. За это отвечает таблица маршрутов (route table) — простой список правил вида «пакеты на такие-то адреса отправляй туда-то». К каждой подсети привязана одна таблица маршрутов.

Internet Gateway — это дверь VPC в интернет. Подсеть становится public именно потому, что её таблица маршрутов содержит строку 0.0.0.0/0 (то есть «весь остальной интернет»), указывающую на Internet Gateway. У private-подсети такой строки просто нет — отсюда и нет выхода наружу.

Но часто private-сервису всё-таки нужен исходящий доступ: скачать обновление, дёрнуть чужой API, отправить событие в платёжку. Входящий при этом не нужен — никто снаружи не должен инициировать соединение. Для этого служит NAT Gateway.

NAT Gateway работает как односторонний турникет: трафик изнутри наружу — пожалуйста, снаружи внутрь по своей инициативе — нельзя. Важная деталь, которую часто путают новички: сам NAT Gateway стоит в public-подсети, потому что ему нужен выход в интернет. А таблица маршрутов private-подсети направляет исходящий трафик 0.0.0.0/0 не на Internet Gateway, а на этот NAT Gateway. Так сервис ходит наружу, оставаясь невидимым снаружи.

aws ec2 create-route --route-table-id rtb-public --destination-cidr-block 0.0.0.0/0 --gateway-id igw-0abc
aws ec2 create-route --route-table-id rtb-private --destination-cidr-block 0.0.0.0/0 --nat-gateway-id nat-0abc

Security groups против NACL

Когда трафик уже доехал до подсети и ресурса, его фильтруют. В AWS два уровня фильтрации, и их постоянно путают.

Security group — фаервол на уровне конкретного ресурса (виртуальной машины, контейнера, эндпоинта базы). У него две ключевые особенности:

  • он stateful («с памятью»): если вы разрешили входящее соединение, ответ на него уйдёт автоматически — отдельное правило на выход писать не нужно;
  • в нём бывают только разрешающие правила. Запретить что-то явно нельзя — всё, что не разрешено, и так закрыто.

Network ACL (NACL) — фаервол на уровне целой подсети. Его особенности противоположные:

  • он stateless («без памяти»): правила нужны отдельно на вход и отдельно на выход. Разрешили входящий запрос — не забудьте разрешить и исходящий ответ, иначе соединение повиснет;
  • в нём бывают и разрешающие, и запрещающие правила.

На практике основной рабочий инструмент — security groups: они точечные и привязаны к ресурсу. NACL берут реже, для грубой блокировки на уровне подсети (например, забанить диапазон адресов целиком).

Очень удобный приём: ссылаться одной security group на другую. Вместо того чтобы прописывать IP-адреса (которые меняются), правило «приложению можно ходить в базу» формулируют так: security group базы принимает трафик от security group приложения.

aws ec2 authorize-security-group-ingress \
  --group-id sg-database \
  --protocol tcp --port 5432 \
  --source-group sg-application

Связь между сетями

Реальные системы редко помещаются в одну VPC: разные команды, разные окружения, разные аккаунты. Связать сети можно несколькими способами.

  • VPC peering — прямое соединение двух VPC. Важный нюанс: оно не транзитивное. Если A связана с B, а B связана с C, это не значит, что A видит C. Каждую пару нужно соединять отдельно — при росте числа сетей это превращается в паутину связей.
  • Transit Gateway — центральный хаб, к которому подключают много VPC (и даже локальную сеть офиса). Вместо россыпи peering-связей все ходят через один узел. Это спасает, когда сетей становится много.
  • PrivateLink и VPC endpoints — доступ к сервису по приватной сети, без выхода в интернет вообще. Через VPC endpoint private-подсеть может, например, обращаться к объектному хранилищу S3 или к Secrets Manager, не открывая при этом интернет-маршрут. Трафик не покидает сеть AWS.

VPC endpoints — почти всегда правильный ответ на вопрос «как private-сервису безопасно достучаться до управляемого сервиса AWS».

Где это применяется

Сеть AWS — это фундамент, на котором стоит всё остальное. Балансировщик в public-подсети, приложение и база в private, NAT для исходящих вызовов, security groups, описывающие «кто до кого» — эту схему вы встретите практически в любом боевом развёртывании. Когда трафик распределяют между несколькими зонами доступности, как в материале про масштабирование и доступность, под капотом работает ровно эта сетевая модель.

Типичные ошибки новичков, которые стоит запомнить заранее:

  • поставить базу в public-подсеть — она оказывается доступна из интернета, это прямая дыра в безопасности;
  • ждать выхода наружу из private-подсети без NAT Gateway — исходящие вызовы будут молча зависать;
  • поставить NAT Gateway в private-подсеть — он сам не получит выход в интернет и работать не будет;
  • забыть про stateless-природу NACL — разрешить вход, но не разрешить ответный выход, и соединение не установится;
  • прописывать IP-адреса вместо ссылок между security groups — адреса меняются, и правила ломаются.

Что учить дальше: сеть отвечает на вопрос «кто куда может дойти», а кто и что имеет право делать с ресурсами — это уже IAM, второй слой безопасности. Дальше полезно посмотреть, где именно живут ваши сервисы — на виртуальных машинах из раздела про вычисления или в бессерверной модели. А чтобы не настраивать всё это руками каждый раз, изучите подход «инфраструктура как код»: начните с основ IaC, затем — Terraform или CloudFormation. Если приложение едет в Kubernetes, сетевая модель кластера ложится поверх VPC — об этом в разделе про основы Kubernetes.