VPC (Virtual Private Cloud) звучит как термин из мира больших облаков. Когда читаешь документацию AWS или Google Cloud, складывается впечатление, что это для компаний с десятками микросервисов и отдельной командой по безопасности.

Поэтому небольшие команды часто пропускают этот пункт мимо. Кажется, что для проекта из двух-трёх сервисов хватит обычного VPS с открытыми портами и парой firewall-правил.

На практике — наоборот. Чем меньше команда, тем сильнее VPC экономит время. Не потому что без неё ничего не работает, а потому что с ней не нужно вручную решать задачи, которые VPC закрывает по умолчанию.

Разберём, что это такое, какие задачи реально решает и почему стоит включать её сразу, а не «когда-нибудь, когда вырастем».

Что такое VPC простыми словами

VPC — это изолированная виртуальная сеть для ваших ресурсов внутри облака.

Удобная аналогия: офис со своим внутренним Wi-Fi. Внутри офиса все компьютеры, принтеры и серверы видят друг друга по локальным адресам. Снаружи в этот Wi-Fi никто не заходит — он защищён периметром. Если нужно опубликовать что-то наружу (например, сайт компании), вы делаете это явно, через одну точку выхода.

VPC устроена так же. Внутри — все ваши ресурсы:

  • backend-приложения;
  • базы данных;
  • виртуальные машины;
  • microVM;
  • serverless-функции;
  • воркеры и фоновые задачи.

Они общаются друг с другом по приватным адресам, не выходя в интернет. Снаружи доступно только то, что вы явно опубликовали — обычно это frontend и публичный API.

Главное отличие от модели «сервер в интернете»: ресурсы по умолчанию закрыты. Чтобы что-то стало публично доступным, нужно явное действие.

Проблема, которую решает VPC

Чтобы понять ценность VPC, проще всего посмотреть, что происходит без неё — на типичном сценарии «всё на одном VPS» или «несколько VPS с публичными IP».

В такой модели по умолчанию все сервисы видны из интернета. Даже те, которые публиковать не нужно.

База данных слушает публичный порт. Чтобы backend подключался к PostgreSQL на соседнем сервере, проще всего открыть порт 5432 наружу. База защищена только паролем. Каждый день логи показывают тысячи попыток брутфорса от ботов, которые сканируют диапазоны IP в поисках открытых баз. Один слабый пароль или утёкший в репозиторий .env — и проект скомпрометирован.

Сервисы общаются через интернет, даже когда стоят в одном датацентре. Backend и API крутятся на двух VPS у одного провайдера. Физически они в одной стойке. Но обращаются друг к другу по публичным IP — потому что иначе их не связать. Каждый запрос выходит в интернет, проходит через провайдера и возвращается на соседний сервер. Это лишняя задержка, лишние точки отказа и лишний публичный трафик.

Каждый открытый порт — потенциальная точка атаки. Чем больше сервисов, тем больше публичных интерфейсов. Redis на одном сервере, RabbitMQ на другом, Elasticsearch на третьем — и каждый из них регулярно появляется в новостях про утечки данных, потому что кто-то забыл поставить пароль или оставил дефолтный.

Любая утечка credentials — прямой доступ снаружи. Если токен или пароль попал в git history, в публичный канал в Slack или в скриншот в чате — атакующий может использовать их немедленно. Сервис открыт в интернете, ничего больше не нужно.

В мире VPS все эти проблемы решаются вручную: firewall-правила, IP whitelist, VPN между серверами, WireGuard, ssh-туннели. Каждое из решений — отдельная инфраструктурная задача, которую нужно настроить и поддерживать.

VPC закрывает большинство этих задач по умолчанию.

Что меняется с VPC: четыре практические задачи

1. База данных, недоступная из интернета

Самое большое и самое недооценённое улучшение.

Backend подключается к базе по приватному адресу внутри VPC. Снаружи база не имеет публичного IP вообще — её невозможно найти сканированием диапазонов, нельзя брутфорсить, нельзя случайно подключиться по утёкшим credentials, потому что атакующий банально не сможет добраться до сервера.

Это убирает целый класс атак, который для open-to-internet баз является основным.

2. Сервисы общаются между собой по приватным адресам

Backend → API, backend → worker, frontend → backend, любой сервис → база. Внутри VPC всё это происходит по внутренним адресам.

Что это значит на практике:

  • не нужно выставлять порты между сервисами в интернет;
  • не нужно настраивать IP whitelist между собственными серверами;
  • не нужны токены и подписи запросов между внутренними сервисами (хотя они могут быть как defense-in-depth);
  • внутренний трафик не выходит в публичную сеть, что и быстрее, и дешевле, и надёжнее.

Если у вас Telegram-бот, который вызывает API, который ходит в базу — это три ресурса в одном VPC, общающихся по приватным адресам. Снаружи виден только webhook бота, и больше ничего.

3. Чёткая граница «что наше, что наружу»

С VPC появляется явная архитектурная граница: есть публичный периметр и есть всё внутреннее.

Публичный периметр — это то, что должно быть доступно из интернета: сайт, публичный API, webhook’и. Всё остальное живёт внутри VPC и снаружи невидимо.

Эта граница важна не только для безопасности. Она упрощает аудит: вы точно знаете, какие сервисы у вас экспонированы, и не нужно бегать по конфигам в попытках вспомнить, что ещё открыто. И она упрощает мышление: при добавлении нового сервиса ясный вопрос — «он публичный или внутренний», без промежуточных состояний.

4. Разные типы ресурсов в одном контуре

В небольшом проекте редко всё построено на одном типе ресурса. Часто это смесь:

  • frontend как статический сайт;
  • backend в Docker;
  • база данных;
  • пара serverless-функций для webhook’ов;
  • виртуальная машина под специфичный сервис;
  • microVM под изолированную задачу.

Без VPC связать всё это в единый контур — отдельная инженерная работа. Нужен либо WireGuard между серверами, либо общий VPN, либо настройка cloud-вендора с десятками страниц документации.

В VPC все эти ресурсы — просто узлы одной сети. Подключили — стали видеть друг друга по приватным адресам. Без отдельной настройки маршрутизации, без VPN-клиентов, без ручного управления ключами.

Почему это особенно полезно для небольших проектов

Главный контр-интуитивный момент. Принято считать, что VPC — для крупных компаний, а маленьким хватит VPS с firewall.

На практике — ровно наоборот.

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

VPC даёт корректную изоляцию из коробки. Не нужно становиться сетевым инженером, чтобы получить базовую гигиену: приватные адреса, закрытые наружу базы, изолированный внутренний трафик. Это включается на уровне платформы, без отдельных конфигов.

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

Проект растёт без переезда. Добавление сервиса — это не переархитектура сети, а просто добавление ресурса в существующий VPC. Решили вынести часть логики в отдельный сервис — он сразу видит базу и backend по приватным адресам, без перенастройки чего-либо.

Когда VPC точно нужна

Простые триггеры. Если хотя бы один из пунктов про вас — VPC стоит включать сразу.

  • В проекте больше одного сервиса.
  • Есть база данных.
  • Есть фоновые задачи, воркеры или очереди.
  • Есть Telegram-бот, который дёргает API.
  • Есть админка отдельно от публичного фронта.
  • Используются managed-сервисы, к которым подключается несколько приложений.
  • Планируете добавлять сервисы в ближайшие месяцы.

Когда без VPC можно обойтись

Чтобы не было ощущения, что VPC нужна всем — несколько случаев, когда она ничего не даст.

  • Один статический сайт без backend и базы. Раздача файлов и так не требует приватной сети.
  • Одиночный сервис без зависимостей, который сам себе и frontend, и backend, и хранилище.
  • Полностью stateless приложение, которое не общается ни с какими внутренними ресурсами.

Если ваш проект попадает в один из этих случаев — VPC можно не включать. Но как только появляется второй сервис, база или внешняя зависимость, картина меняется.

Как это устроено в TatNet

В TatNet VPC — это сетевая сущность, которая создаётся в кабинете и в которую подключаются ресурсы платформы.

Что входит в один VPC:

  • виртуальные машины;
  • microVM;
  • backend-приложения на Docker;
  • serverless-функции;
  • базы данных.

Все ресурсы внутри одного VPC видят друг друга по приватным адресам. Снаружи доступно только то, что вы явно опубликовали — например, frontend на публичном домене или API за HTTPS.

На практике рабочий сценарий выглядит так:

  1. Создаёте VPC в кабинете.
  2. Подключаете backend, базу данных и serverless-функции в одну сеть.
  3. Backend получает приватный адрес базы и подключается без выставления портов в интернет.
  4. Serverless-функции тоже видят базу и backend по приватным адресам.
  5. Снаружи опубликован только публичный домен с HTTPS, который ведёт на frontend и API.

Никаких WireGuard, IP whitelist’ов, ssh-туннелей и ручных firewall-правил — это работа платформы.

Создать VPC в TatNet →

Итог

VPC — это не enterprise-фича и не «то, что нужно настраивать, когда вырастем». Это базовая инфраструктурная гигиена для любого проекта из нескольких компонентов.

Один раз создали, подключили в неё ресурсы — и дальше можно расти, не переделывая сеть. Добавление нового сервиса — это просто ещё один узел в существующем VPC, а не переархитектура.

Если у вас в проекте есть база данных и хотя бы один backend — стоит вынести их в VPC прямо сейчас. Это не отнимет времени, и сразу закрывает большую часть типовых проблем безопасности и связности, которые иначе придётся решать вручную.

Создать VPC в TatNet →