В классической SaaS-модели вендор держит у себя всё: приложение, данные, сеть и операции. BYOC сдвигает эту границу: рабочая нагрузка, данные, сетевые правила, аудит-логи и часто биллинг остаются в облаке клиента, а вендор при этом обеспечивает managed-продукт. На практике BYOC — это не один сценарий, а спектр моделей: от обычного вендорского SaaS до полностью изолированных сред. Между ними — BYOC-Account, BYOC-VPC, BYOC-K8s и air-gapped доставка.
Клиентам разные варианты нужны по разным причинам. Одним важна data residency и суверенитет данных: всё должно лежать в конкретном регионе, аккаунте или юрисдикции. Другим — контроль безопасности: приватные сети, свои ключи, аудит, политики через собственные системы identity и governance. Третьи хотят задействовать уже оплаченные облачные квоты, резервы или GPU-резервации. Для AI- и data-heavy нагрузок решает data gravity: перетаскивать большие объёмы логов и embeddings в SaaS-окружение дорого и медленно. Платформенные команды часто требуют стандартизации: вендор должен вписаться в их VPC-паттерны, Kubernetes-кластеры, сервисные mesh, CI/CD и observability. А регулируемые среды требуют полностью автономной доставки без доступа в интернет.
BYOC-Account — самый простой и частый сценарий. Клиент создаёт отдельный облачный аккаунт, вендор через scoped IAM-роли и агента разворачивает туда свой data plane. Получается чистое разделение ответственности: клиент владеет аккаунтом, биллингом и регионом, вендор занимается жизненным циклом продукта.
BYOC-VPC глубже: софт обязан работать внутри одобренной клиентом сети. Нужно интегрироваться с существующими VPC/VNet, подсетями, маршрутами, DNS, firewall-политиками, приватными эндпоинтами и egress-контролем. Никаких публичных эндпоинтов, только приватные подключения вроде AWS PrivateLink.
BYOC-K8s означает, что клиент даёт Kubernetes-рантайм. Вендор ставит Helm-чарты, операторы, CRD и контейнеры в кластер, которым управляет клиент. Платформенная команда сохраняет контроль над политиками, сканерами, secret-менеджментом и GPU-планированием. Но вендор уже не контролирует substrate: версия кластера, CNI, storage-драйверы и настройки узлов могут различаться. В традиционных on-prem средах это особенно тяжело.
Air-gapped — самый жёсткий вариант, естественное расширение BYOC. Софт работает без прямого доступа к интернету. Вендор отдаёт подписанные артефакты, клиент их сканирует, одобряет и импортирует офлайн. Нельзя рассчитывать на живую телеметрию, онлайн-проверку лицензий и автоматические pull-загрузки. Обновления, образы и зависимости приходится зеркалировать.
Безопасность должна быть заложена с самого начала: least-privilege права, end-to-end шифрование, zero-inbound доступ, egress allowlists, приватные каналы связи, интеграция со supply-chain клиента и аудит. Это совпадает с zero-trust из NIST SP 800-207.
Главная проблема — портируемость. BYOC обязан работать в AWS, Azure, Google Cloud, sovereign cloud, neocloud, GPU-облаках, Kubernetes, OpenShift, on-prem, edge и air-gapped средах. Это не облачная задача, а задача портируемости.
Самое сложное — day two. Нужен полный жизненный цикл: provision, deploy, configure, govern, upgrade, meter, observe, operate. Terraform для этого не хватает — нужен отдельный BYOC control plane. Плюс metering и биллинг, интеграция со Stripe и маркетплейсами, офлайн-лицензии, observability без утечки данных и day-2 автоматизация: бэкапы, ротация ключей, failover.
BYOC — это не скрипт для установки, а целая продуктовая архитектура. Её обещание простое: клиент сохраняет контроль над инфраструктурой, данными и compliance, но при этом получает managed-опыт от вендора.