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

Облачная сеть и подсети

Облачная сеть (cloud network) — ваша изолированная виртуальная сеть внутри Yandex Cloud, что-то вроде арендованного этажа в дата-центре: чужой на него не попадёт, а вы решаете, какие двери открыть наружу. В терминах AWS это аналог VPC.

Сеть разрезают на подсети (subnets). Ключевая особенность Yandex Cloud: одна подсеть живёт ровно в одной зоне доступности и имеет свой диапазон адресов — CIDR вида 10.0.1.0/24 (число после слэша говорит, сколько адресов в диапазоне: /24 — около 256). Чтобы сервис работал в трёх зонах ради надёжности, вы создаёте по подсети в каждой зоне — ru-central1-a, ru-central1-b, ru-central1-d.

yc vpc network create --name my-net
yc vpc subnet create --name subnet-a --network-name my-net --zone ru-central1-a --range 10.0.1.0/24
yc vpc subnet create --name subnet-b --network-name my-net --zone ru-central1-b --range 10.0.2.0/24

Ресурсы одной облачной сети видят друг друга по внутренним адресам, даже если стоят в разных зонах. Обычно на проект хватает одной облачной сети — в отличие от AWS, здесь редко плодят много сетей и соединяют их между собой; связь с локальной сетью офиса делают через VPN или Cloud Interconnect.

Публичный и внутренний IP

Здесь модель Yandex Cloud проще, чем «public/private-подсети» в AWS. Деление проходит не по подсети, а по ресурсу: получит ли виртуальная машина публичный IP-адрес.

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

Правило простое: серверы и базы держат без публичного IP, а наружу смотрят только балансировщики и точки входа. Публичный IP базе данных «чтобы удобно подключаться с ноутбука» — прямая дыра: её тут же начнут сканировать и перебирать пароли.

Выход в интернет: NAT-шлюз

Часто внутреннему сервису всё-таки нужен исходящий доступ — скачать обновление, дёрнуть чужой API, отправить событие в платёжку. Входящий при этом не нужен: никто снаружи не должен инициировать соединение. Для этого служит NAT-шлюз (NAT gateway).

NAT-шлюз работает как односторонний турникет: изнутри наружу — пожалуйста, снаружи внутрь по своей инициативе — нельзя. Подключается он через таблицу маршрутизации (route table): вы создаёте шлюз, заводите таблицу с маршрутом «весь интернет 0.0.0.0/0 → NAT-шлюз» и привязываете её к подсети. После этого машины без публичного IP из этой подсети ходят наружу, оставаясь невидимыми снаружи.

yc vpc gateway create --name egress-gw --nat
yc vpc route-table create --name rt-egress --network-name my-net \
  --route "destination=0.0.0.0/0,gateway-name=egress-gw"

Группы безопасности

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

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

В отличие от AWS, отдельного файрвола на уровне целой подсети (NACL) в Yandex Cloud нет — группы безопасности закрывают эту задачу. Очень удобный приём: ссылаться одной группой на другую. Вместо IP-адресов (которые меняются) правило «приложению можно ходить в базу» формулируют так: группа безопасности базы принимает трафик на порт 5432 от группы безопасности приложения.

yc vpc security-group create --name sg-db --network-name my-net \
  --rule "direction=ingress,port=5432,protocol=tcp,security-group-id=<sg-app-id>"

Важная грабля: если к ресурсу привязана группа безопасности, а нужных разрешающих правил в ней нет, соединения будут молча не проходить. Пустая группа означает «запретить всё».

Точки входа: балансировщики

Чтобы пустить пользователей к приложению, перед ним ставят балансировщик нагрузки. В Yandex Cloud их два вида:

  • Network Load Balancer — балансирует на уровне соединений (L4), быстрый и простой; раздаёт трафик по группе виртуальных машин.
  • Application Load Balancer — работает на уровне HTTP (L7): умеет маршрутизацию по путям и хостам, терминацию TLS, проверки здоровья. Именно он обычно стоит публичной точкой входа, а сами приложения прячутся во внутренней сети.

Как балансировщик распределяет нагрузку между зонами и держит сервис живым при сбоях — в статье про масштабирование и доступность.

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

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

Типичные ошибки новичков:

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

Что учить дальше: сеть отвечает на вопрос «кто куда может дойти», а кто и что имеет право делать с ресурсами — это уже Cloud IAM, второй слой безопасности. Дальше полезно посмотреть, где запускать сервис. А чтобы не настраивать всё это руками каждый раз, изучите подход «инфраструктура как код»: Terraform в Yandex Cloud. Многое здесь устроено так же, как в сети AWS — модель переносима.