TCO корпоративного VPN: облако vs on‑prem для 100, 500 и 1000 пользователей

Введение: почему тема актуальна и что вы узнаете

Корпоративный VPN остается основой удаленного доступа и межофисной связности даже в эпоху Zero Trust и SASE. Но на практике именно стоимость владения, а не технология как таковая, определяет архитектуру и выбор платформы. Какой TCO у облачного VPN и on-prem решений для 100, 500 и 1000 пользователей в 2026 году с учётом производительности, шифрования, резервирования, поддержки, соответствия требованиям и скрытых расходов на эксплуатацию? В этом руководстве мы последовательно рассчитаем полную стоимость владения для типовых сценариев, предложим проверяемые формулы и фреймворки, дадим пошаговые инструкции по оценке и оптимизации, покажем кейсы и типичные ловушки. Итогом станет ваша собственная модель TCO, которой можно доверять при планировании бюджета и технической архитектуры.

Основы: фундаментальные концепции TCO и архитектуры корпоративного VPN

Что такое TCO для VPN

TCO (Total Cost of Ownership) это совокупная стоимость владения за заданный срок (обычно 36–60 месяцев), включающая: CAPEX (оборудование, лицензии бессрочно, внедрение), OPEX (обслуживание, поддержка, подписки, электричество, стойко-место, трафик), а также цену рисков и простоев (штрафы по SLA, пропущенная выручка, репутационные и compliance-издержки). В VPN-проектах до 60 процентов TCO зачастую приходится на эксплуатацию и персонал, а технологические затраты зависят от выбранного протокола, архитектуры туннелирования и профиля трафика.

Ключевые архитектуры и термины

• Remote Access VPN: пользователи подключаются клиентами (WireGuard, OpenVPN, IKEv2, SSTP, L2TP) к концентратору доступа.
• Site-to-Site VPN: связность между площадками, дата-центрами и облаками.
• Полный туннель (full tunnel) vs разделенный туннель (split tunnel): в первом случае весь трафик пользователя идет через VPN, во втором в VPN отправляются только корпоративные подсети и приложения.
• Cloud VPN: развёрнут в IaaS или Managed VPN сервисе провайдера. Вы платите за вычислительные ресурсы, трафик, публичные IP и поддержку.
• On-prem: собственная инфраструктура в ЦОД или офисе: серверы или аппаратные шлюзы, каналы связи, питанием и эксплуатация на вашей стороне.
• Протоколы: WireGuard (современный, высокопроизводительный), OpenVPN (проверенная классика), IKEv2/IPsec (стандарт де-факто для S2S и enterprise-клиентов), SSTP и L2TP для совместимости.

Срок службы и амортизация

Для on-prem железа типично 3–5 лет амортизации. Для облака срок зависит от резервирования, оптимизации под пики и возможной миграции между инстансами. Планируя TCO, задайте горизонт в 36 месяцев и добавьте сценарий 60 месяцев для чувствительности. Это позволит увидеть, как повлияeт на выбор замена оборудования и эволюция нагрузки.

Глубокое погружение: драйверы стоимости, производительность и риски

Драйверы TCO

• Производительность и масштаб: количество одновременных подключений, криптографическая нагрузка, пропускная способность на пользователя, пиковые события (видеоконференции, обновления).
• Надежность и доступность: HA-кластеры, актив-актив или актив-пассив, георезервирование, RTO и RPO. Чем выше SLA, тем дороже лишние узлы и каналы.
• Безопасность и соответствие: MFA, PKI, HSM, аудит, журналы в SIEM, DLP, требования отраслевых регуляторов. Каждый контроль добавляет компоненты и OPEX.
• Операционная зрелость: автоматизация (IaC), мониторинг, обновления, тестирование отказов, документация и обучение. Снижает инциденты, но требует времени экспертов.
• Трафик и маршрутизация: split vs full tunnel радикально меняет стоимость egress в облаке и емкость каналов on-prem.
• Лицензии и поддержка: коммерческие стек-клиенты, поддержка вендора, премиум-планы облаков vs опенсорс плюс собственная экспертиза.

Моделирование нагрузки 2026: что изменилось

• Больше видеосвязи и интерактивных приложений, следовательно, выше пиковые требования к пропускной способности и jitter-чувствительность.
• Широкое принятие WireGuard за счёт лучшей производительности на ядро и упрощенной криптографии.
• Усиление требований к аудиту: хранение логов подключения 180–365 дней, корреляция с EDR и IdP, MFA по умолчанию.
• Рост доли гибридных топологий: часть пользователей идет через SASE, часть через корпоративный VPN (например, для доступа к системам второго контура).

Риск-ориентированный подход

В TCO заложите стоимость событий: простой VPN-концентратора на 2 часа в рабочий день может стоить десятки тысяч долларов упущенной продуктивности. Если компания продает онлайн-услуги, потеря транзакций увеличит цифру. Включайте это как ожидаемую стоимость: вероятность инцидента умножить на ущерб. Архитектурные меры (HA, актив-актив) снижают вероятность и/или ущерб, но увеличивают базовый TCO. Оптимум достигается балансом.

Метод 1. Фреймворк TCO: формулы, структура и шаги

Структура затрат

• CAPEX: оборудование (серверы, NIC, HSM), бессрочные лицензии, внедрение и миграция.
• OPEX: облачные инстансы, трафик egress, IP-адреса, стойко-место и электричество, каналы связи (DIA), поддержка вендора, подписки (MFA), резервирование, мониторинг и SIEM.
• PeopleEx: FTE на эксплуатацию (NOC, NetSec), on-call, обучение и документация.
• RiskEx: ожидаемые потери от простоев и инцидентов безопасности, штрафы compliance.

Формулы

TCO = (CAPEX/срок) + OPEX + PeopleEx + RiskEx. Для унификации переводим CAPEX в помесячную амортизацию. Unit Economics: CPUU cost per user per month = TCO / N пользователей. CPGb cost per Gbps capacity = (ежемесячная стоимость ресурсов)/предоставляемая пропускная способность. CPConn cost per concurrent connection = (стоимость)/макс. одновременных подключений.

Параметры нагрузки

• Конкурентность: 20–40 процентов пользователей одновременно активны (средняя оценка 30 процентов для белых воротничков). Пики следует закладывать 1.5–2.0x от среднего активного числа.
• Профиль трафика: split tunnel 10–20 ГБ на пользователя в месяц; full tunnel 40–80 ГБ. Возьмем базу: 15 ГБ и 60 ГБ соответственно.
• Пиковая скорость на активного пользователя: 2–5 Мбит/с для офисной работы, 5–8 Мбит/с при видеосвязи HD. Возьмем 5 Мбит/с для расчета пиков и 2.5 Мбит/с для headroom 50 процентов.

Чек-лист входных допущений

• Количество пользователей, требуемый SLA (например, 99.9 процентов), регуляторные требования.
• Split vs full tunnel, доля Mac/Windows/Linux, мобильные клиенты.
• Протоколы: WireGuard по умолчанию, OpenVPN/IKEv2 для совместимости.
• География и задержки: где находятся пользователи и приложения.
• Наличие существующих каналов связи и ЦОД.
• Уровень автоматизации и компетенции команды.

Метод 2. Расчет TCO: 100, 500 и 1000 пользователей (облако vs on-prem)

Общие допущения для сравнения

• Горизонт: 36 месяцев. Валюта: USD для нейтральности (конвертация по курсу региона при внедрении).
• MFA: 1 доллар на пользователя в месяц (часто считается корпоративной лицензией, но здесь учитываем как инкремент к проекту VPN).
• SIEM и аудит: 150–300 долларов в месяц в зависимости от масштаба (логов немного, но нужны ретенция и корреляция).
• Затраты на персонал: 100 тысяч долларов в год fully loaded cost на FTE сетевой безопасности (8333 доллара в месяц). На облаке FTE доля ниже благодаря меньшему физическому хозяйству.
• WireGuard как основной протокол для пропускной способности; OpenVPN и IKEv2 — для совместимости.
• Конкурентность: 30 процентов активных одновременно; коэффициент пика 2x на емкость.

Моделирование пропускной способности

• 100 пользователей: 30 активных. Пиковая нагрузка 30 × 5 Мбит/с × 2 = 300 Мбит/с (full). При split — 40 процентов нагрузки: около 120 Мбит/с.
• 500 пользователей: 150 активных. Пик 150 × 5 × 2 = 1500 Мбит/с (1.5 Гбит/с full). Split ~ 600 Мбит/с.
• 1000 пользователей: 300 активных. Пик 300 × 5 × 2 = 3000 Мбит/с (3 Гбит/с full). Split ~ 1200 Мбит/с.

Облако: помесячные затраты

Компоненты: вычислительные инстансы (HA 2–6 узлов), трафик egress (0.06 за ГБ с учетом дисконтов), IP и диск (20–80), поддержка провайдера (300–800), эксплуатация (0.2–0.6 FTE), MFA (1 на пользователя), SIEM (50–300). Предполагаем оптимизацию по инстансам и региональную близость к пользователю.

100 пользователей

• Инстансы: 2 × c-класс средних по 68 = 136.
• Трафик: split 1.5 ТБ ≈ 92; full 6 ТБ ≈ 369.
• IP и диск: 20.
• Поддержка: 300.
• Эксплуатация: 0.2 FTE ≈ 1667.
• MFA: 100.
• SIEM и аудит: 50.

Итог облако 100: split ≈ 2398 в месяц (≈ 24 за пользователя), full ≈ 2675 (≈ 26.8 за пользователя).

500 пользователей

• Инстансы: split 400, full 600 (больше узлов и/или классы).
• Трафик: split 7.5 ТБ ≈ 461; full 30 ТБ ≈ 1843.
• IP и диск: 50.
• Поддержка: 500.
• Эксплуатация: 0.4 FTE ≈ 3333.
• MFA: 500.
• SIEM: 150.

Итог облако 500: split ≈ 5361 (≈ 10.7 на пользователя), full ≈ 6943 (≈ 13.9).

1000 пользователей

• Инстансы: split 700, full 900.
• Трафик: split 15 ТБ ≈ 922; full 60 ТБ ≈ 3686.
• IP и диск: 80.
• Поддержка: 800.
• Эксплуатация: 0.6 FTE ≈ 5000.
• MFA: 1000.
• SIEM: 300.

Итог облако 1000: split ≈ 7802 (≈ 7.8 на пользователя), full ≈ 11766 (≈ 11.8).

On-prem: помесячные затраты

Компоненты: серверы/апплаиансы (амортизация 36 мес), каналы DIA (две линии ради отказоустойчивости), стойко-место и электричество, поддержка вендора, эксплуатация (0.4–1.0 FTE), MFA, SIEM, запасные части. Предполагаем опенсорс стек на commodity-серверах; если используются коммерческие лицензии на пользователя, добавляйте их отдельно.

100 пользователей

• Серверы: 2 × 2500 = 5000, амортизация 139 в месяц (с учетом 2000 на NIC и мелочи, итого 139).
• Каналы DIA: 2 × 500 Мбит/с ≈ 1200.
• Стойко-место и электричество: 480.
• Поддержка: 100.
• Эксплуатация: 0.4 FTE ≈ 3333.
• MFA: 100.
• SIEM и аудит: 150.
• Запас и мелкие расходы: 100.

Итог on-prem 100: ≈ 5479 в месяц (≈ 54.8 на пользователя).

500 пользователей

• Серверы: 2 × 4000 = 8000 плюс мелочи, амортизация ≈ 166.
• Каналы DIA: 2 × 1 Гбит/с ≈ 2400.
• Стойко-место и электричество: 500.
• Поддержка: 200.
• Эксплуатация: 0.6 FTE ≈ 5000.
• MFA: 500.
• SIEM: 250.
• Запас: 150.

Итог on-prem 500: ≈ 9166 (≈ 18.3 на пользователя).

1000 пользователей

• Серверы: 3 × 5000 = 15000 плюс мелочи, амортизация ≈ 300.
• Каналы DIA: 2 × 2 Гбит/с ≈ 4000.
• Стойко-место и электричество: 600.
• Поддержка: 300.
• Эксплуатация: 1.0 FTE ≈ 8333.
• MFA: 1000.
• SIEM: 400.
• Запас: 200.

Итог on-prem 1000: ≈ 15133 (≈ 15.1 на пользователя).

Вывод базового сравнения

• Для всех трех масштабов облако при split-туннеле оказывается дешевле on-prem, в особенности при 100 и 500 пользователях.
• Полный туннель в облаке всё ещё конкурентоспособен до 1000 пользователей благодаря экономии на FTE и отсутствию DIA-каналов в ЦОД, но становится заметно дороже по трафику egress.
• On-prem выигрывает только при наличии уже оплаченных DIA-каналов и ЦОД, высокой внутренней экспертизы и приращении админ-нагрузки не более 0.2–0.3 FTE. В этом случае его TCO для 1000 пользователей может опуститься к 9–11 долларов на пользователя в месяц.

Альтернативные сценарии чувствительности

• Если каналы DIA уже есть (затраты нулевые): on-prem 1000 пользователей падает до ≈ 11133 (≈ 11.1 на пользователя).
• Если FTE дороже (например, 140 тысяч в год): облако дорожает меньше, чем on-prem, потому что FTE доля в облаке ниже.
• Если включить лицензии коммерческого VPN (20–40 долларов на пользователя в год): on-prem и облако дорожают, но на объемах 500–1000 бьет по on-prem сильнее из-за еще и DIA.
• Если еgress в облаке дороже (0.09 за ГБ): полный туннель при 1000 пользователях добавит ≈ 1843 долларов к трафику и вплотную приблизится к on-prem.

Метод 3. Технико-экономическое нормирование: как правильно размерить инфраструктуру

Производительность протоколов

• WireGuard: линейно масштабируется по ядрам, 1–2 Гбит/с на vCPU на современных хостах с поддержкой крипто-ускорения. Отличный выбор для высокой плотности пользователей.
• OpenVPN: 200–400 Мбит/с на ядро с AES-NI и оптимизациями. Подходит для совместимости, но менее эффективен.
• IKEv2/IPsec: устойчив для S2S, производительность близка к WireGuard на аппаратуре с аппаратным ускорением.

Sizing пошагово

1. Определите конкурентность и пиковые Мбит/с на активного пользователя.
2. Рассчитайте пиковую емкость (активные × пик × headroom).
3. Выберите протокол. Для массовых клиентов предпочтителен WireGuard, для S2S — IKEv2/IPsec, для старых клиентов — OpenVPN.
4. Сопоставьте с профилем инстансов: начните с 2 vCPU и шагами масштабируйтесь до 4–8 vCPU, тестируя криптографическую производительность и контекст-переключения.
5. Запланируйте HA: минимум 2 узла актив-актив, для 500+ пользователей рационально 3–4 узла на регион.
6. Проверьте MTU и MSS, особенно при двойном инкапсулировании и S2S; это часто источник деградации производительности.
7. Заложите лимиты на хендшейки и rate limit на DoS против UDP-флуда.

Наблюдаемость и опыт пользователя

• Собирайте метрики: активные сессии, повторные рукопожатия, latency до приложений, PLR, пропускная способность на пользователя. Визуализируйте в Grafana.
• Включайте аномалитику: всплески egress, нехарактерные страны, множественные попытки логина — автоматизируйте SOC playbooks.
• Тестируйте деградации: отключения узлов, потеря региона, внезапный рост нагрузки на 30–50 процентов.

Метод 4. Построение калькулятора TCO: артефакты и шаблоны

Шаблон входных данных

• Пользователи, доля активных, split vs full, гигабайты на пользователя.
• Протоколы и доли по клиентам.
• Список регионов, задержки, требования к HA и DR.
• Цены на инстансы/каналы/стойко-место/электричество, ставки FTE.

Вычисляемые поля

• Пиковая емкость, количество узлов по региону, итоговая стоимость инстансов.
• Трафик egress и стоимость.
• CAPEX амортизация и OPEX.
• Персонал по долям FTE и on-call.
• RiskEx: вероятность × ущерб для 2–3 ключевых сценариев.

Пошаговая инструкция

1. Соберите baseline для 1 месяца на пилоте: активность пользователей, гигабайты, пиковые Мбит/с.
2. Примените коэффициенты роста (сезонность, найм, новые приложения).
3. Просчитайте 2 сценария: split 100 процентов и full 100 процентов — это верхние и нижние границы.
4. Добавьте HA и DR поверх расчетов узлов.
5. Распишите FTE: администрирование, автоматика, поддержка пользователей 1-й линии.
6. Проведите стресс-тест и скорректируйте sizing.
7. Соберите итоговую модель TCO 36 месяцев и unit-экономику на пользователя.

Метод 5. Практика внедрения: облако шаг за шагом

Цели и критерии

• SLA 99.9 процентов, RTO 15 минут.
• Split по умолчанию, full для привилегированных ролей и по политике.
• MFA и привязка к IdP (SAML/OIDC).

Шаги

1. Выберите регионы инстансов ближе к пользователям.
2. Разверните 2–4 узла WireGuard/OpenVPN в актив-актив, подключите балансировщики (L4/UDP-aware).
3. Автоматизируйте конфигурацию через IaC и шаблоны конфигов клиентов.
4. Настройте split-маршруты и политики по группам (HR, Dev, Finance).
5. Интегрируйте MFA и выставьте политику ротации ключей/сертификатов.
6. Включите централизованное логирование в SIEM, алерты по аномалиям.
7. Прогоните нагрузочное тестирование и ввод в эксплуатацию по канареечному принципу.

Контрольный список

• Тесты восстановления при падении узла и региона.
• Наличие процедур ключевой ротации и отзывов.
• Документация для L1/L2 службы поддержки.
• Регулярная проверка egress и Reserved/Committed Discounts.

Метод 6. Практика внедрения: on-prem шаг за шагом

Цели и критерии

• Низкая задержка до внутренних систем, контроль над каналами.
• Гибкость в применении HSM/PKI и соответствия отраслевым стандартам.

Шаги

1. Выберите площадку ЦОД и оформите 2 независимых DIA-подключения.
2. Закупите 2–3 сервера с поддержкой AES-NI, 10Г NIC, резервное питание.
3. Разверните WireGuard/IKEv2 на гипервизорах или bare metal, настройте актив-актив.
4. Реализуйте split-маршрутизацию, при необходимости route-based IPsec к внешним облакам.
5. Интегрируйте MFA, IdP, централизованное логирование и HSM/TPM для хранения ключей.
6. Постройте мониторинг и резервное копирование конфигураций.
7. Проведите тестирование отказов: обрыв одного DIA, отказ одного узла, деградация маршрутов.

Контрольный список

• Коммерческие и опенсорс лицензии, условия поддержки и сроки поставок.
• Наличие SLA с провайдерами каналов, договоренности о времени ремонта.
• Спайр-процедуры: запас NIC, запасной сервер, проверка совместимости прошивок.

Метод 7. Оптимизация TCO: 12 рычагов экономии

• Split tunnel по умолчанию и только определенные роли через full-туннель. Экономит egress и канальную емкость.
• WireGuard как базовый протокол: выше производительность на ядро, меньше CPU и меньше узлов.
• Geo-локализация узлов: уменьшение RTT повышает КПД соединения и снижает пиковые Мбит/с для тех же задач.
• Reserved/Committed Discounts на облачные инстансы и egress.
• Автоматическое масштабирование по пиковым часам.
• Маршрутизация трафика SaaS напрямую (локальный breakout) вместо гонки в дата-центр.
• Unified клиенты с конфигами по группам пользователей и политиками.
• Непрерывное тестирование производительности и MSS/MTU tuning.
• Снижение FTE за счет IaC, GitOps и готовых модулей развертывания.
• Агрегирование логов и разумная ретенция (хранить метаданные дольше, подробные логи — короче с архивом холодного хранения).
• Закупка каналов с возможностью burst и SLA на jitter/latency.
• Правильная настройка keepalive чтобы не держать соединения активными без необходимости.

Типичные ошибки: чего избегать при построении TCO и архитектуры

• Игнорирование конкуренции и пиков: расчет по средним значениям без санкционированного headroom приводит к перегрузке и простоям.
• Неправильный выбор протокола: использование OpenVPN там, где нужен WireGuard или IKEv2, влечет избыточные узлы и затраты.
• Full-туннель без причины: кратно растет egress и канальные издержки.
• Отсутствие HA или резервирования каналов: экономия десятков долларов оборачивается тысячами в простоях.
• Неучтенная эксплуатация: FTE и on-call всегда дороже, чем кажется. Документация и автоматизация окупаются.
• Коммерческая лицензия без TCO-рационала: оплата за пользователя вдвое увеличивает TCO там, где опенсорс и экспертиза решают задачу.
• Неоптимальная география: узлы далеко от пользователя увеличивают задержки и тянут за собой накладные расходы пропускной способности.

Инструменты и ресурсы: что использовать на практике

Стек протоколов и серверов

• WireGuard для производительного пользовательского доступа и S2S.
• OpenVPN для совместимости с устаревшими клиентами и специфичными прокси-сценариями.
• strongSwan/Libreswan для IKEv2/IPsec, особенно S2S и BGP-over-IPsec.
• SoftEther как вариант мультипротокола с продвинутой NAT-транверсией.

Управление и автоматизация

• Инфраструктура как код: Terraform/Ansible для развертывания узлов и политик.
• CI/CD для конфигураций: GitOps, ревью правил маршрутизации и ACLs.
• Мониторинг: Prometheus, Grafana, exporters для WireGuard/OpenVPN.
• Безопасность: центр сертификации (PKI), интеграция с IdP (AD/Entra, Okta, Keycloak), MFA как политика по умолчанию.
• Журналы: централизовать в SIEM, нормализовать форматы, отслеживать неуспешные логины и геоаноналии.

Практический вариант для пилотов и быстрых PoC

Когда нужно подтвердить гипотезу, обкатать split vs full, замерить реальную нагрузку и собрать baseline без долгих закупочных циклов, удобно использовать сервис уровня vpn.how. Это персональный VPN-сервер (не shared, у клиента отдельный IP), поддержка WireGuard, OpenVPN, IKEv2, L2TP, SSTP с выбором под задачу, география серверов охватывает Москву, Санкт-Петербург, Амстердам, Франкфурт, Лондон, Нью-Йорк, Сан-Хосе, Чикаго, Сингапур, Сидней, Мадрид, Хельсинки, Стокгольм, Варшаву, Копенгаген, Ставангер; принимаются карты РФ (включая Tinkoff и Озон), СБП, USDT/BTC; тарифы от 490 рублей за день и от 2490 рублей в месяц со скидками на длительные периоды; автозапуск за 5 минут после оплаты и отсутствие логов. На практике это хороший инструмент именно для пилотов и POC: быстро поднимаем узел, собираем метрики трафика, проверяем совместимость клиентов и политику маршрутизации. Для production на длительный горизонт разумно переходить на собственную инфраструктуру (облако или on-prem) или сертифицированные решения уровня ГОСТ-VPN, исходя из требований безопасности и compliance.

Кейсы и результаты: как цифры влияют на выбор

Кейс 1: 100 пользователей, распределенная команда разработки

Задача: безопасный доступ к Git, CI, staging. Требования: split-туннель, 99.9 процентов, WireGuard. Результат: облако 2398 долларов в месяц (24 за пользователя), on-prem 5479 (54.8). Выбор: облако с 2 узлами и IaC. Срок от пилота до production — 2 недели. Экономия 55 процентов против on-prem. Окупаемость автоматизации (Ansible + CI/CD конфигов) — 3 месяца засчет снижения FTE с 0.3 до 0.2.

Кейс 2: 500 пользователей, финтех, требование к полной фильтрации трафика

Задача: полный туннель через корпоративные контуры, инспекция и запись логов. Результат: облако 6943 долларов в месяц, on-prem 9166. Неожиданность: egress существенно вырос, но FTE все равно перевесил on-prem. Выбор: гибрид. 60 процентов пользователей идут по split (SaaS напрямую), 40 процентов — full через облако с инспекцией. Итоговая стоимость снизилась до ≈ 5600 долларов в месяц.

Кейс 3: 1000 пользователей, производственная компания, низкая латентность к MES

Задача: доступ к внутренним приложениям в ЦОД с минимальными задержками. Пилот: облако с узлами вблизи фабрик показал приемлемую производительность, но egress на full-туннеле для части пользователей сделал счет существенным. Результат: on-prem при наличии уже оплаченных DIA и стойко-месте снизил TCO до 11 долларов на пользователя. Выбор: on-prem с WireGuard и IKEv2 для S2S, гибридная модель для сотрудников в разъездах.

FAQ: глубокие вопросы

1. Можно ли считать TCO без учета простоев и рисков безопасности

Технически да, но это неверный ориентир: простой в пиковые часы может съесть годовую экономию от выбора более дешевого варианта. Включайте хотя бы два сценария риска с оценкой вероятности и ущерба.

2. Насколько критично выбирать протокол с точки зрения TCO

Существенно. WireGuard позволяет держать ту же нагрузку на меньшем числе ядер, что прямо снижает стоимость узлов и потребление. На масштабах 500+ пользователей экономия может достигать 20–30 процентов на compute.

3. Split-туннель безопасен ли для предприятий

Да, при корректной политике маршрутов, обязательном MFA, контроле устройств (MDM/EDR) и инспекции только корпоративного трафика. Full-туннель целесообразен для привилегированных ролей, админов и в сценариях жесткого комплаенса.

4. Что сильнее влияет на облачный TCO: compute или egress

До 500 пользователей — compute и FTE. После 500 при full-туннеле egress становится сравнимым или больше, особенно без скидок и оптимизации маршрутизации SaaS напрямую.

5. Когда on-prem точно выигрывает

Когда у вас уже есть оплаченные DIA-каналы и стойко-место, а также опытная команда, для которой увеличение нагрузки добавляет 0.2–0.3 FTE. Также, если комплаенс требует аппаратных модулей и строгой изоляции.

6. Как оценить требуемое число узлов

Отталкивайтесь от пиков по Мбит/с и целевой утилизации на узел (не выше 60–70 процентов), умножайте на фактор HA. Тестируйте на пилоте и закладывайте дополнительные 20 процентов на всплески.

7. Что по IPv6

Включение IPv6 полезно для стабильности и производительности в мобильных сетях, но увеличивает сложность маршрутов и политик. Убедитесь, что клиенты и серверы его корректно поддерживают, а ACL и SIEM знают про dual-stack.

8. Как учитывать лицензии коммерческих клиентов VPN

Считайте как инкремент на пользователя в месяц и сравните с опенсорс плюс затраты на поддержку. Часто коммерческие клиенты оправданы совместимостью и лучшей телеметрией.

9. Можно ли смешивать протоколы

Да, это норма. Примите WireGuard по умолчанию, оставьте OpenVPN для совместимости и IKEv2 для S2S и некоторых мобильных клиентов. Отражайте доли в калькуляторе TCO.

10. Как быстро понять, что мы переплачиваем за egress

Смотрите на гигабайты на пользователя в месяц. Если в full-туннеле среднее вышло за 80–100 ГБ без понятных причин, проверьте маршруты SaaS и кэширование контента, примените split для некритичных приложений.

Заключение: резюме и следующие шаги

Стоимость владения корпоративным VPN определяется не названием вендора, а архитектурой, протоколом и операционной зрелостью. На горизонте 36 месяцев облачные решения при split-туннеле оказываются экономнее on-prem на масштабах до 1000 пользователей благодаря сниженной доле FTE и отсутствию капитальных вложений. Full-туннель в облаке требует дисциплины по egress и маршрутам SaaS, иначе TCO быстро растет. On-prem выигрывает при наличии оплаченных каналов и собственной команды, а также при жестких требованиях к изоляции. Лучший путь — вынести гипотезы в пилот, собрать метрики и затем зафиксировать TCO на production-архитектуре с ясными SLA и процессами. Ваши следующие шаги: 1) за 1–2 недели собрать пилот, измерить конкуренцию, пиковую емкость и фактический egress; 2) построить калькулятор TCO по фреймворку из руководства; 3) выбрать стратегию split по умолчанию, WireGuard как базовый протокол и HA как обязательный атрибут; 4) спланировать оптимизацию через автоматизацию, мониторинг и разумную географию узлов. Так вы получите предсказуемый бюджет, управляемые риски и стабильный опыт для пользователей, а VPN перестанет быть черным ящиком и станет инструментом с понятной ценой и отдачей.