VPC
Virtual Private Cloud — логически изолированная виртуальная сеть внутри публичного облака, где вы сами задаёте адресацию и правила доступа.
Что такое VPC
VPC (Virtual Private Cloud, «виртуальное частное облако») — логически изолированный сетевой сегмент внутри публичного облака. Внутри VPC вы сами задаёте диапазон адресов, режете его на подсети, настраиваете маршруты и решаете, что доступно из интернета, а что нет.
Физически ваши серверы стоят на том же железе и в тех же коммутаторах, что и чужие. VPC делает так, что сетевой уровень этого не замечает: трафик тенантов разделён инкапсуляцией (VXLAN/GENEVE), и соседи не видят ваши пакеты, даже если адреса у вас совпадают.
Смысл: без VPC каждый сервер торчал бы в интернет голым. С VPC наружу смотрит только то, что должно, — остальное живёт в приватных подсетях.
Из чего состоит
| Компонент | Зачем нужен |
|---|---|
| CIDR-блок | Диапазон адресов сети, например 10.0.0.0/16 — см. маска подсети и CIDR |
| Подсети (subnets) | Деление на публичные и приватные, привязка к зонам доступности |
| Internet Gateway | Выход в интернет для публичных подсетей |
| NAT Gateway | Приватные машины ходят наружу за пакетами, но снаружи недоступны |
| Таблицы маршрутизации | Куда идёт трафик из каждой подсети |
| Security groups | Правила доступа на уровне сервера, с состоянием |
| Network ACL | Правила на уровне подсети, без состояния |
| Peering, VPN | Связь с другими VPC и с офисной сетью |
Адресация берётся из приватных диапазонов RFC 1918: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16. Выбор — не формальность: если планируете VPN или peering, диапазон не должен пересекаться с офисной сетью и чужими VPC, иначе маршрутизация не сойдётся, а переадресовать работающую сеть уже нельзя.
Типовая схема
Internet → Internet Gateway
│
VPC 10.0.0.0/16
├── Публичная 10.0.1.0/24 → load balancer, bastion, NAT Gateway
├── Приватная 10.0.10.0/24 → GPU-серверы, backend (без белых IP)
└── Приватная 10.0.20.0/24 → PostgreSQL, Redis (только из 10.0.10.0/24)
Правило, ради которого всё это строится: база данных не должна иметь публичного IP. Доступ к ней — только из приватной подсети приложения. Административный вход — через bastion-хост или VPN, а не через открытый наружу SSH на каждой машине.
Security groups и NACL
Два уровня фильтрации, которые часто путают:
| Security group | Network ACL | |
|---|---|---|
| Уровень | Сетевой интерфейс сервера | Подсеть целиком |
| Состояние | Stateful: разрешили входящий — ответ уйдёт сам | Stateless: нужно правило и на ответный трафик |
| Правила | Только разрешающие | Разрешающие и запрещающие |
| Порядок | Все правила разом | По номерам, до первого совпадения |
| Типичная роль | Основной инструмент | Грубая отсечка на подсеть |
Частая ошибка при отладке: открыли входящий порт в NACL и удивляются, почему соединение висит — ответный трафик заблокирован, потому что NACL не помнит сессию. В security group такой проблемы нет.
VPC и GPU-инфраструктура
Для ML-инфраструктуры приватная сеть — не бюрократия, а прямая необходимость:
- GPU-серверы не нужны в интернете. JupyterLab или vLLM, открытые наружу без аутентификации, находят сканерами за часы. Держите их в приватной подсети, наружу выставляйте только балансировщик с TLS.
- Данные не выходят из контура. Датасеты и веса ходят между серверами и object storage по внутренней сети — быстрее и без платы за исходящий трафик.
- Обучение чувствительно к сети. Межузловой обмен в GPU-кластере должен идти по выделенной внутренней сети, а не через шлюз.
В OpenStack за это отвечает компонент Neutron: приватные сети, роутеры, floating IP и группы безопасности собираются из тех же кирпичей.
Связанные термины
- Маска подсети и CIDR — как считаются диапазоны VPC
- NAT — выход приватных машин в интернет
- IaaS — модель, частью которой VPC является
- Межсетевые экраны / WAF — фильтрация на периметре
- VPN — связь VPC с офисной сетью
- Мультитенантность — почему изоляция сети вообще нужна
Готовы запустить GPU-задачу?
Запустить GPU-сервер