Содержание статьи +
- TL;DR
- Зачем эта статья
- Восемь строк стриминг-стека затрат
- Проработанная модель: 100 000 MAU, гибридный формат live + VOD
- Как кривая гнётся при изменении масштаба
- Build vs buy: точка переключения для каждой строки
- Подводные камни: три строки, которые большинство моделей интерпретируют неверно
- Чувствительность: что больше всего влияет на счёт?
- Частая ошибка: путать concurrent с MAU
- Где используется Фора Софт
- Ключевые выводы
- Что читать дальше
- CTA
TL;DR
Валовая маржа стриминг-продукта складывается не из одной статьи расходов, а из восьми: кодирование, упаковка, origin-серверы, доставка через CDN, multi-DRM, аналитика, real-time реле (TURN / SFU) и инженерная команда, поддерживающая всё это в рабочем состоянии. Большинство команд учитывают только расходы на CDN, удивляются счётам за аналитику и DRM, а реальную стоимость реагирования на инциденты видят впервые после первого крупного сбоя. В этой статье мы построим юнит-экономику с нуля: на входе – число зрителей, градация битрейтов, часы просмотра в месяц, доля DRM-защищённого контента и соотношение live и VOD; на выходе – стоимость в долларах за час просмотра, за одного месячного активного пользователя (MAU) и точка принятия решения «разработать самому или купить» по каждой статье. К концу статьи вы сможете взять прогноз аудитории, спрогнозировать счёт на следующий квартал с точностью ±15% и сказать поставщику, продаёт ли он подходящий счётчик для вашей нагрузки.
Зачем эта статья
CDN – самая заметная статья расходов, но редко именно она подтачивает валовую маржу. Отчёт Bitmovin Video Developer Report за 2025 год называет контроль затрат главной проблемой для 38% команд, работающих с видео – больше, чем любая техническая сложность. Причина в том, что счёт состоит не из одной, а из восьми позиций. Подписочный видеопродукт с 100 000 месячных активных пользователей может тратить на аналитику больше, чем на хранение, на DRM-ключи – больше, чем на исходящий трафик с origin, а на пропускную способность TURN – больше, чем на весь CDN, в зависимости от специфики продукта.
Целевая аудитория статьи – инженер или основатель, которому задали вопрос: «Сколько стоит воспроизвести один час видео?», и финансовый руководитель, которому нужно обосновать выбор «разрабатывать самому или покупать готовое» перед советом директоров. К концу статьи оба должны уметь читать инвойс поставщика построчно, рассчитывать стоимость одного часа просмотра для каждой из восьми статей расходов, прогнозировать общий бюджет при масштабировании в 10 раз и точно назвать две позиции, которые стоит оптимизировать в первую очередь.
Восемь строк стриминг-стека затрат
Прежде чем расставлять цифры, нужен полный перечень того, за что будет выставляться счёт. Заголовочная ставка – «мы платим CDN $X за гигабайт» – это лишь первый из восьми независимых счётчиков, и строки, которые кажутся самыми дешёвыми, при росте масштаба нередко становятся самыми дорогими.
Первая строка – кодирование: преобразование исходного mezzanine-файла (или live-контрибуции) в набор битрейтов, из которого плеер выбирает нужную версию. Тарифы на VOD-кодирование рассчитываются как стоимость минуты выхода, умноженная на количество рендиций. Для live-кодирования – это стоимость канала в час, умноженная на число входов и выходов. По данным на май 2026 года, AWS Elemental MediaConvert на тарифе professional берёт $0.0150 за минуту HD AVC и $0.0300 за минуту UHD; MediaLive – $0.7656 за час HD-входа и $1.7225 за час UHD, со скидкой до 75% при годовом reserved-коммите. Та же нагрузка на Bitmovin, Mux или собственной ферме на базе FFmpeg / SVT-AV1 даёт другие абсолютные цифры, но ту же структуру: оплата за минуту или за час, умноженная на «количество ступеней × кодеки».
Вторая строка – упаковка: обёртывание выходных данных энкодера в HLS, DASH, CMAF и любые форматы для прогрессивной загрузки, требуемые вашей матрицей клиентов. На большинстве современных стеков упаковка уже включена в стоимость энкодера (CMAF унифицирует HLS и DASH – один проход по CMAF генерирует оба манифеста), поэтому её предельные затраты минимальны. Эта строка становится значимой, когда добавляется multi-DRM с внедрением ключей на этапе упаковки, либо когда используется just-in-time-упаковка на origin, перекладывая нагрузку с энкодера на CPU origin. Мы выделяем её отдельно, чтобы команды, которые в будущем перейдут на JIT, могли видеть сдвиг: JIT не меняет общую сумму расходов, но перераспределяет их между статьями.
Третья строка – хранение и origin-egress: стоимость хранения каждого сегмента каждой рендиции каждого ассета в надёжном хранилище плюс расходы на передачу данных CDN при промахах кэша. Хранение относительно дёшево в пересчёте на гигабайт (S3 Standard – $0,023 за ГБ в месяц в мае 2026 года; более холодные уровни – до $0,0036 за ГБ в месяц на Glacier Instant Retrieval), но растёт линейно с размером библиотеки и количеством ступеней в цепочке доставки. Origin-egress – строка, которую многие команды игнорируют: если origin и CDN находятся в одном облаке – например, S3 + CloudFront или GCS + Cloud CDN – провайдер покрывает эти расходы. А вот если origin (например, S3) находится за пределами CDN (Cloudflare или Fastly) – каждый промах кэша вынуждает передавать данные из AWS по стандартной ставке egress, которая составляет $0,05–$0,09 за ГБ. Основные метрики со стороны CDN мы подробно разбирали в статье об экономике CDN; эта статья дополняет картину, добавляя origin-сторону в общий баланс.
Четвёртая строка – доставка через CDN: байты, которые CDN передаёт зрителям с edge-серверов. Именно эту строку все рассчитывают, и она – единственная, где применяется тариф за гигабайт. Pay-as-you-go-тариф CloudFront для регионов US/EU начинается с $0.085/ГБ после первого бесплатного терабайта, снижается до $0.020/ГБ на петабайтном объёме и примерно вдвое ниже при долгосрочных сделках с Akamai, Fastly или CDN-нативными стриминговыми провайдерами. Cloudflare и BunnyCDN предлагают более низкие цены с почти фиксированной ставкой. Полная механика – 95-й перцентиль, модель с фиксированным объёмом и переплатой, четыре счётчика на провайдера – описана в статье об экономике CDN.
Пятая строка – DRM: плата за лицензию за каждое решение о воспроизведении зашифрованного контента, которое принимают ваши плееры. Сам по себе механизм (Widevine, FairPlay, PlayReady) бесплатен на уровне технологии, но на практике вы платите multi-DRM-провайдеру (EZDRM, BuyDRM, DRMtoday, Castlabs, Axinom, Verimatrix, doverunner, DRM-аддон Mux) за хостинг серверов лицензирования и за «сертификатный танец» с Apple. Модели делятся на два типа. В моделях per-stream и per-license берётся небольшая сумма за каждый зашифрованный просмотр: DRM-аддон Mux – $100 в месяц + $0,003 за просмотр в мае 2026 года; doverunner – $299 + $0,06 на пользователя за первые 9 000 сверх базовой нормы и $0,04 на пользователя свыше этого. Подписочные модели предполагают ежемесячную плату с фиксированным объёмом просмотров: EZDRM – от $199,99 в месяц, BuyDRM – от $99 в месяц, DRMtoday – по пакетам. Три основных DRM-системы мы подробно рассмотрели в статье DRM 101 multi-DRM; эта статья ставит акцент на модели ценообразования.
Шестая строка – аналитика: QoE/QoS-телеметрия, которую плеер отправляет в SaaS-дашборд. Mux Data, Conviva, Bitmovin Analytics, Datazoom, NPAW (YOUBORA) – все тарифицируют по viewer-hour или по сессии, со ставками от примерно $0,0005 до $0,005 за viewer-hour в зависимости от объёма, длительности контракта и того, сколько «ИИ-ассистированного реагирования на инциденты» вы подключите дополнительно. Аналитика – это та строка, которая тихо обгоняет CDN в случае подписочного VOD с высокой вовлечённостью: viewer-hour, который обходится в $0,001 на CDN при больших объёмах, может стоить $0,002 на аналитике, если вы остаётесь на модели pay-per-hour. Сравнение вендоров – в статье о платформах аналитики; юнит-экономика – в этой.
Седьмая строка – real-time-реле: TURN-серверы, пробивающие NAT для WebRTC-трафика, и SFU, которые дублируют поток одного публикатора для нескольких подписчиков. Если ваш продукт – чистый HLS/DASH VOD, эта строка равна нулю. Если вы работаете с видеоконференциями, телемедициной, real-time-аукционами или любым интерактивным стримом, TURN может стать самой крупной статьёй расходов – ведь TURN-реле передаёт всю медиаполезную нагрузку в обе стороны, и один звонок one-to-many на 1 Мбит/с с десятью участниками генерирует через реле трафик в 10 Мбит/с. SFU-обработка трафика следует той же логике, но с более высокой удельной стоимостью, поскольку SFU выполняет дополнительную работу на CPU. В нашей модели мы объединяем TURN и SFU в одну строку, а детали архитектуры оставляем для отдельных статей: SFU vs MCU vs Mesh и сравнения mediasoup / Janus / LiveKit / Jitsi / Pion.
Восьмая строка – инженерная команда и операции: зарплаты сотрудников, поддерживающих семь предыдущих пунктов, плюс on-call-ротация, плюс мониторинговый стек, плюс неизбежная поддержка AWS. Эта строка – самая крупная в большинстве команд с аудиторией ниже ~100k MAU, вторая по объёму в командах с более чем 1M MAU и та, которую чаще всего упускают из виду в презентациях по «стоимости на час просмотра». Мы её учитываем, потому что именно она определяет точку выбора «разрабатывать самому или покупать» для всех остальных семи пунктов.
Проработанная модель: 100 000 MAU, гибридный формат live + VOD
Поставим цифры на каждую строку на конкретном примере. Продукт – гибридное стриминговое приложение: половина – VOD-библиотека, половина – расписанные live-события, плюс небольшой WebRTC-интерактив. Сто тысяч месячных активных пользователей. Входные данные:
- MAU: 100 000.
- Среднее число часов просмотра на MAU: 12 (медиана индустрии Bitmovin 2025 по гибридному OTT – тяжёлые пользователи смещают медиану).
- Средний битрейт рендиции (взвешенный по лесенке): 4.0 Mbps. Лесенка отгружает 240p / 360p / 480p / 720p / 1080p; ABR в продакшене оседает на 4.0 Mbps, если взвесить по микшу устройств зрителей и распределению Wi-Fi-vs-cellular.
- Доля live в часах просмотра: 30%.
- Доля DRM-защищённого просмотра: 70% (VOD-библиотека лицензирована студиями; live – неприкрытый промоконтент).
- WebRTC-интерактив: 5% от часов просмотра, средняя группа звонка – 4 участника.
- Размер библиотеки: 6 000 часов VOD.
- Live-каналы: 4 HD-канала, по 8 часов в день в среднем.
Сначала выводим суммарные часы просмотра – они драйверят почти все строки:
total_view_hours = MAU × hours_per_MAU
= 100 000 × 12
= 1 200 000 часов/месПоток в 4,0 Мбит/с потребляет 1,8 ГБ в час:
GB_per_hour = bitrate_Mbps × 3600s / 8000 (конверсия Mb→GB)
= 4.0 × 3600 / 8000
= 1.8 GBСуммарный спрос на egress за месяц:
egress_TB = 1 200 000 × 1.8 / 1024
= 2 109 TB/месЭти три числа (1.2M viewer-часов, 1.8 ГБ/час, 2 109 ТБ/мес) мы используем в каждой строке ниже. Теперь – по стеку.
Строка 1 – Кодирование
VOD-кодирование – разовая трата на ассет. Новый контент за месяц – скажем, 100 часов исходника, то есть 6000 минут – «лесенка» превращает примерно в пять рендиций, три из которых – HD-класса. По тарифу MediaConvert professional (май 2026: $0.0150/мин для HD, $0.0075/мин для SD, со скидками после 100 000 нормализованных минут в месяц) – 6000 × 5 × ~$0.0115 ≈ $345 в месяц. Переэнкод существующей библиотеки в новый кодек (AV1 в 2026) – батч-операция, амортизируется: 6000 × 60 × 5 × $0.0115 / 24 ≈ $863 в месяц амортизировано.
Live-кодирование – за канал-час:
live_channel_hours = 4 канала × 8 часов/день × 30 дней
= 960 канал-часов/месПо ставке on-demand MediaLive HD – $0.7656 в час за вход и около $0.50 в час за HD-выход (5-ступенчатая лесенка = фактически 2.5 HD-выхода после SD/HD-микширования) – стоимость одного часа канала составляет примерно $1.90. При скидке 75% по reserved-тарифу с обязательством на 12 месяцев цена снижается до ~$0.48. Выбираем reserved (steady-state):
live_encoding_cost = 960 × $0.48 ≈ $461/месКодирование итого, всё включено: ~$1 670/мес. На один час просмотра: $1 670 / 1,2 млн = $0,0014 / час.
Строка 2 – Упаковка
CMAF-упаковка включена в стоимость энкодера на любом современном стеке. Записываем $0/мес как отдельную строку. (В модели оставляем, чтобы команды, переходящие на JIT-упаковку, могли её исключить – JIT переносит стоимость с энкодера на CPU origin, не меняя общую сумму, но изменяя распределение.)
Строка 3 – Хранение и origin-egress
Размер библиотеки в байтах:
library_size_TB = 6 000 часов × 1.8 GB/ч × 5 рендиций / 1024
= 52.7 TBНа S3 Standard ($0.023/ГБ в месяц в мае 2026): 52 700 × $0.023 = $1 212/мес. При использовании lifecycle-политики, которая перемещает редко используемый контент в Standard-IA ($0.0125/ГБ в месяц) через 30 дней без обращений, средневзвешенная стоимость снижается до примерно $0.016/ГБ в месяц: 52 700 × $0.016 = $843/мес. Выбираем lifecycle.
Origin-egress при коэффициенте попаданий в кэш 92% (реальное значение для гибридной библиотеки с fat-head-распределением просмотров – то же, что и в нашей статье об экономике CDN):
origin_egress_TB = total_egress_TB × (1 − cache_hit_ratio)
= 2 109 × 0.08
= 169 TB/месЕсли CDN – CloudFront с S3 origin, AWS не берёт плату: $0. Если CDN – Cloudflare с S3 origin, AWS выставит счёт по in-region egress (путь S3 → Cloudflare через AWS PrivateLink идёт по $0.04/GB регионального исходящего трафика, а не по $0.09/GB интернет-трафика – в мае 2026 года; Cloudflare R2 origin полностью обнулил бы эти расходы). Моделируем основную конфигурацию CloudFront + резервный Fastly для multi-CDN, поэтому Fastly потребляет origin-egress: 0.5 × 169 ТБ × $0.04/ГБ × 1024 = $3 471/мес на резервный канал.
Хранение + origin итого: 843 $ + 3 471 $ = 4 314 $/мес. На viewer-hour: 0,0036 $ / час.
Строка 4 – доставка через CDN
Суммарный egress – 2 109 ТБ в месяц. При single-CDN коммите по $0,012 за ГБ (средневзвешенная ставка для среднего объёма коммита в 2026 году):
cdn_cost = 2 109 × 1024 × $0.012 = $25 915/месНа multi-CDN: 70% CloudFront (фиксированный объём) + 30% Fastly (фиксированный объём) по $0.014:
cdn_cost = 0.70 × 2 109 × 1024 × $0.012 + 0.30 × 2 109 × 1024 × $0.014
= $18 140 + $9 068 = $27 208/месMulti-CDN формально дороже, но экономия достигается за счёт других факторов: избежание переплат в пиковые месяцы, региональная оптимизация тарифов, надёжность (подробнее – в статье о multi-CDN-архитектуре). В расчётной модели используется $27 208/мес, при этом эквивалент single-CDN составляет $25 915, и разница имеет значение на таком масштабе. По стоимости на час просмотра: $0,0227 / час для multi-CDN и $0,0216 / час для single.
Строка 5 – DRM
70% часов просмотра – с DRM-защитой, но тарификация DRM идёт не за часы, а за запросы лицензий. Обычно один запрос лицензии приходится на один ассет при воспроизведении – а не на сегмент. В индустрии сложилось соотношение примерно 1 запрос лицензии на 30 минут (long-формат OTT) – до 1 на 5 минут (short-формат мобильные). Возьмём 1 на 30 минут для гибридного формата:
licenses_per_month = total_view_hours × DRM_share × 60мин/час / 30мин/license
= 1 200 000 × 0.70 × 60 / 30
= 1 680 000 лицензийПо репрезентативной ставке 2026 года для multi-DRM SaaS – $0.003 за лицензию (по данным Mux; EZDRM и BuyDRM при объёмных тарифах находятся в диапазоне $0.001–$0.0025):
drm_cost = 1 680 000 × $0.003 = $5 040/месДоговорённая годовая ставка в $0,0015 за лицензию даёт $2 520 в месяц. При использовании комбинированной ставки $0,002 – $3 360 в месяц. По viewer-hour (по всем часам, а не только защищённым): $0,0028 за час.
Строка 6 – Аналитика
QoE-аналитика тарифицируется по viewer-часу у всех крупных вендоров – различаются только ставки. Mux Data предлагает pay-as-you-go тарифы примерно по $0,0008 за viewer-минуту ($0,048 за час) на начальных уровнях, снижаясь до $0,0005 за минуту ($0,030 за час) на среднем уровне нагрузки; Conviva и Bitmovin Analytics находятся в той же ценовой категории, а в enterprise-сделках при больших объёмах стоимость падает до $0,0002 за минуту ($0,012 за час). На 1,2 млн viewer-часов при ставке Mux Data $0,030 за час получается:
analytics_cost = 1 200 000 × $0.030 = $36 000/месЭта цифра шокирует с первого взгляда – она превышает стоимость CDN. Поэтому подписочные продукты с высокой вовлечённостью не задерживаются на аналитике по модели pay-per-hour дольше первого года: либо переходят на годовой коммит (типичное снижение – 60–80%), либо мигрируют на self-hosted Prometheus + ClickHouse + Grafana, который обходится в фиксированные $3–5 тыс. в месяц независимо от объёма. Моделируем коммит по $0,008 за viewer-hour blended:
analytics_cost = 1 200 000 × $0.008 = $9 600/месНа час просмотра: 0,008 $ / час.
Строка 7 – Реальное время: реле (TURN + SFU)
5% времени просмотра приходится на WebRTC-интерактив, средняя продолжительность звонка – 4 минуты.
webrtc_user_hours = 0.05 × 1 200 000 = 60 000 user-hoursUser-час WebRTC на том же 4 Мбит/с blended даёт 1,8 ГБ медиа. Типичный уровень использования TURN-ретрансляции (доля WebRTC-сессий, которые не могут установиться напрямую и переходят через TURN) в 2026 году составляет около 15–20% из-за корпоративных файрволов и симметричных NAT. Возьмём 20%:
turn_GB = 60 000 × 1.8 GB × 0.20 = 21 600 GB = 21.6 TBПо репрезентативной ставке coturn на EC2 – $0.085 за 1 ГБ исходящего трафика (выход в интернет с EC2 обходится дорого) или около $0.06 за 1 ГБ при использовании приватного пирингового TURN:
turn_cost = 21 600 × $0.06 = $1 296/месSFU-полоса (80% не-TURN-трафика, который всё равно проходит через SFU для маршрутизации) тарифицируется по той же ставке $0.085 за гигабайт исходящего трафика, умноженной на коэффициент SFU fan-out – для встречи из четырёх человек fan-out равен 3 (каждый публикатор транслирует поток трём подписчикам):
sfu_GB = 0.80 × 60 000 × 1.8 GB × 3 = 259 200 GB = 259 TB
sfu_cost = 259 × 1024 × $0.085 = $22 548/месПлюс SFU-вычислений – 4-ядерный c6i.xlarge справляется с примерно 200 одновременными участниками в mediasoup или LiveKit. Для 5% от 1,2 млн часов / 730 часов в месяц / 4 участников на звонок:
concurrent_calls = (60 000 / 730) × (1 / 4) ≈ 21 одновременный звонок в пике
concurrent_participants ≈ 82
sfu_compute = ceil(82 / 200) × 1 сервер × $0.20/ч × 730 ≈ $146/месReal-time-реле итого: $1 296 + $22 548 + $146 ≈ $23 990/мес. На viewer-hour (по всем 1.2M часам, потому что cost-per-MAU – операционный взгляд): $0.020 / час. На WebRTC-user-hour специально: $0.40 / час – в 20–200 раз дороже сравнимого HLS-часа. Это соотношение – самое крупное «осторожно» в статье.
Строка 8 – Инженерная команда и операции
Команда, которая поддерживает и эксплуатирует семь строк кода на таком масштабе, включает как минимум: одного backend / streaming-инженера, одного DevOps / SRE, одного frontend / player-инженера, а также четверть штатной ставки продакт-менеджера и четверть штатной ставки дизайнера. Затраты на одного сотрудника (loaded cost) на рынке senior-уровня в Северной Америке или Западной Европе составляют $200–280 тыс. в год; на качественном nearshore-рынке Восточной Европы – $80–120 тыс. Используем усреднённую стоимость $140 тыс. на FTE (типичная для гибридного стиля распределения в Фора Софт):
fte_cost = (1 + 1 + 1 + 0.25 + 0.25) × $140 000 / 12
= 3.5 × $11 667 = $40 833/месПлюс мониторинговый стек (Datadog – $3 500 в месяц на такой объём), инструменты для работы с инцидентами, AWS Business Support – 10% от расходов на AWS с минимальным платёжом $5 000 в месяц, и резерв на один инцидент в продакшене в течение 90 дней (~$4 000 инженерного времени + обращения за партнёрскими кредитами) – около $1 300 в месяц амортизировано. Итого по инженерной линии: ~$50 000/мес. На один viewer-hour: $0,042 в час.
Суммарный счёт
Складываем восемь строк:
| Строка | $/мес | $/viewer-hour | % счёта |
|---|---|---|---|
| 1. Кодирование | $1 670 | $0.0014 | 1.3% |
| 2. Упаковка | $0 | $0 | 0% |
| 3. Хранение + origin-egress | $4 314 | $0.0036 | 3.5% |
| 4. CDN-доставка | $27 208 | $0.0227 | 21.9% |
| 5. DRM | $3 360 | $0.0028 | 2.7% |
| 6. Аналитика | $9 600 | $0.0080 | 7.7% |
| 7. Real-time-реле | $23 990 | $0.0200 | 19.3% |
| 8. Инженерия и операции | $50 000 | $0.0417 | 40.3% |
| Итого | $124 142 | $0.1035 / час | 100% |
На MAU: $124 142 / 100 000 = $1,24 на MAU в месяц, или $14,90 на MAU в год. Если продукт продаётся по $7,99 в месяц с целевой маржой 10% (потолок расходов – 90%, то есть $7,19), то cost-per-MAU должен снизиться примерно на 14%, чтобы экономика заработала – то есть продукт либо установлен на неправильном тарифе, либо имеет неиспользованный потенциал для upsell, либо требует конкретной оптимизации трёх самых крупных статей расходов: инженерия (40%), CDN (22%) и real-time-реле (19%). Именно ради этого и пишется XL-статья.
Как кривая гнётся при изменении масштаба
Ключевой вопрос любой cost-презентации: как будет выглядеть тот же продукт при 10k MAU, при 1 млн и при 10 млн? Разные статьи расходов масштабируются по-разному, поэтому кривая роста выглядит неочевидно.
Кодирование примерно линейно по объёму библиотеки, линейно по новым live-канал-часам и почти не зависит от MAU. Библиотека объёмом 6 000 часов исходного контента требует того же энкодер-ресурса при увеличении аудитории в 10 раз – стоимость кодирования на один зрительский час снижается в 10 раз.
Хранение – плоское по MAU, линейное по размеру библиотеки. Та же форма, что у кодирования: на фиксированной библиотеке cost-per-viewer-hour падает с ростом пользователей.
Origin-egress – линейно зависит от объёма egress-трафика, с демпфированием по коэффициенту попаданий в кэш. При росте cache-hit-коэффициента в 10 раз (когда long-tail-контент становится «теплее» за счёт большего числа одновременных зрителей, делящих один и тот же горячий набор) origin-egress на viewer-hour снижается примерно на 25% при переходе с 100 тыс. до 1 млн MAU.
CDN-доставка – линейная по отгруженным байтам, но цена за GB падает по тирам. На 1M MAU с тем же профилем вовлечённости спрос на egress становится 21 000 TB/мес. CloudFront-публичная сетка перевалит $0.020/GB на петабайтном масштабе, а commit-контракт на таком объёме сядет около $0.006/GB blended. Cost-per-viewer-hour CDN падает примерно в 2 раза при переходе 100k → 1M MAU – но только если перезаключить контракт.
DRM – линейный по защищённым license-запросам с тир-дисконтами. На 1M MAU и 16.8M лицензиях/мес тарифицированная SaaS-ставка садится около $0.0008/license; строка масштабируется суб-линейно. На viewer-hour падает примерно на 60%.
Аналитика – линейная по viewer-hours с тир-скидками. При коммите на 12 млн viewer-hours в месяц цена составляет $0,003 за час; стоимость одного viewer-hour снижается примерно на 60%. Эта строка чаще всего меняется из «шокирующей» при 100 тыс. MAU в «скучную» при 1 млн MAU.
Real-time-реле – линейные по WebRTC-user-hours, без тир-дисконтов, если не торговать IP-transit напрямую. Эта строка масштабируется хуже всех, потому что cost доминирован пропускной способностью, а bandwidth на масштабе падает только если строить собственный peering. На viewer-hour остаётся примерно плоской.
Инженерия – примерно логарифмическая по MAU: команда, обслуживающая 10 тыс. MAU, и команда, обслуживающая 1 млн MAU, – это те же 5–8 человек при правильной архитектуре, и только при достижении 10 млн MAU она удваивается. На один viewer-hour приходится почти в 10 раз меньше ресурсов между 100 тыс. и 1 млн MAU. Именно поэтому стоимость на viewer-hour резко падает в диапазоне от 100 тыс. до 1 млн MAU, а затем выравнивается.
| MAU | Месячный счёт | $/viewer-hour | $/MAU | $/MAU/год |
|---|---|---|---|---|
| 10 000 | $58 200 | $0.485 | $5.82 | $69.84 |
| 100 000 | $124 142 | $0.103 | $1.24 | $14.90 |
| 1 000 000 | $580 000 | $0.048 | $0.58 | $6.96 |
| 10 000 000 | $4 400 000 | $0.037 | $0.44 | $5.28 |
«Локоть» кривой живёт в диапазоне от 100 тыс. до 1 млн MAU – там, где коммиты CDN, DRM и аналитики достигают нелинейных скидок, а инженерная инфраструктура ещё амортизируется на небольшой базе пользователей. Продукт за 5 долларов в месяц должен преодолеть этот «локоть», чтобы юнит-экономика стабилизировалась; продукт за 20 долларов в месяц может остаться ниже него, если аудитория остаётся нишевой. Форма этой кривой – важнее любого другого фактора – определяет, можно ли запустить стриминговый стартап на венчурных деньгах.
Build vs buy: точка переключения для каждой строки
У каждой из восьми строк есть опция «купить» (buy), опция «разработать» (build) и пороговый уровень MAU, после которого вариант «разработать» обычно становится выгоднее. Решение зависит от двух соотношений: какая часть нагрузки общая (её амортизирует SaaS-провайдер за счёт множества клиентов), а какая – специфична для продукта (работу всё равно выполняет ваша инженерная команда), и сколько FTE реально стоит путь «разработать».
Кодирование. Используйте SaaS-решения (MediaConvert, Bitmovin Encoding, Mux Encoding), пока объём кодируемого контента не превысит ~5 000 часов в месяц или количество одновременных live-каналов не превысит 30. При больших нагрузках переходите на Kubernetes-оркестрированную ферму на основе FFmpeg и SVT-AV1, запущенную на spot-инстансах – это дешевле на 60–80% по стоимости за байт, но потребует дополнительных 1,5–2,0 FTE инженеров. Переход обойдётся примерно в $25 000 в месяц на SaaS-кодирование.
Упаковка. Покупайте готовые решения. Собственный CMAF-упаковщик не экономит реальных денег и добавляет редкие, но болезненные баги – на границах сегментов, с init-сегментами и при встраивании DRM-ключей.
Origin. Используйте управляемые решения (S3, Cloud Storage, Wasabi, Backblaze B2) на любом масштабе. Самостоятельное хостинг-решение экономит лишь однозначные проценты, но требует десятки FTE-часов в квартал на оперативное устранение инцидентов.
CDN. Покупайте коммерческий CDN, пока расходы на него не превысят ~200 000 долларов в месяц – после этого собственный кэширующий слой поверх bare-metal-нод в 3–4 дата-центрах начинает окупаться. Даже тогда большинство команд такого масштаба используют гибридную модель: коммерческий CDN как третий уровень, а кастомный edge – для контента с высокой нагрузкой. Переход на собственную инфраструктуру целесообразен при годовых расходах на CDN около 2 млн долларов.
DRM. Buy SaaS до ~10 млн лицензий в месяц. При большем объёме триплет Widevine / FairPlay / PlayReady начинает окупаться, однако «сертификатный танец» с Apple и регуляторные требования по FairPlay остаются операционно затратными. Переход: ~$30 000 в месяц на DRM-SaaS.
Аналитика. Покупка SaaS-решений для аналитики выгодна до ~200 000 долларов в месяц. После этой отметки самохостинг на базе Prometheus, ClickHouse и Grafana окупается. Команда поддержки стека требует 0,5–1 штатной единицы постоянно, пока система работает; вендоры при умеренных объёмах дают более низкие оценки. Переход на self-hosted происходит при объёме ~200 000 долларов в месяц – это значительно выше, чем ожидают большинство команд.
Real-time-реле. На малом масштабе используйте управляемые решения (Twilio, LiveKit Cloud, Daily, 100ms, Mux Real-Time). На умеренном масштабе переходите к самостоятельному развёртыванию (coturn на EC2 + self-hosted mediasoup или LiveKit), потому что наценка SaaS над чистым трафиком составляет 5–10×, а в WebRTC основная нагрузка – это пропускная способность. Порог перехода относительно низок: ~$10 000 в месяц за управляемый real-time сервис.
Инженерия. Это ответ на вопрос «Должны ли мы строить остальные семь?» – не просто выбор между покупкой и разработкой. Предполагается, что вы можете нанять и удержать штатных сотрудников по указанной полной стоимости (loaded cost); если это невозможно, все переходы сдвигаются вверх.
| Строка | Переход (SaaS $/мес) | Окупаемость build (FTE-мес) |
|---|---|---|
| Кодирование | $25 000 | 12–18 |
| Упаковка | n/a – никогда не build | n/a |
| Origin / хранение | n/a – никогда не build | n/a |
| CDN | $200 000 | 24–36 |
| DRM | $30 000 | 9–12 (плюс регуляторика) |
| Аналитика | $200 000 | 9–12 |
| Real-time-реле | $10 000 | 6–9 |
| Инженерия | n/a | n/a |
Подводные камни: три строки, которые большинство моделей интерпретируют неверно
Если модель утверждает, что какая-то строка дороже CDN, это стоит перепроверить – а затем ей довериться. На слайде три строки выглядят компактно, но в счёте превращаются в огромную сумму.
Подводный камень 1 – Mismatch счётчика аналитики. Подписочный продукт с пятью часами вовлечённости на MAU в месяц платит за аналитику в 5 раз больше, чем ad-supported продукт с одним часом при тех же MAU. Ошибка – прогнозировать аналитику исходя из MAU, а не из viewer-часов. Всегда моделируйте аналитику на основе кривой вовлечённости.
Подводный камень 2 – Origin-egress в multi-CDN. Переход с CloudFront-on-S3 на Cloudflare-on-S3 позволяет сэкономить на edge-egress, но при этом может привести к появлению новой статьи расходов – origin-egress на сумму $5 000–$30 000 в месяц, которой не было в исходной квоте CloudFront. Решение: либо развернуть origin-shield, либо перенести origin к провайдеру облачного хранилища с пиринговым подключением (например, R2, если вы используете Cloudflare; B2 – при наличии сделки с Backblaze и Fastly; Wasabi – при соответствующем договоре), либо договориться о размещении origin внутри облака с основным CDN.
Подводный камень 3 – WebRTC-bandwidth на масштабе. 5% WebRTC-трафика на 100k-MAU-приложении – это 19% счёта в проработанной модели. 10% WebRTC на том же приложении – 30%. Команды, которые «строят небольшой интерактивный фичер поверх VOD-библиотеки», регулярно отгружают более дорогой продукт, чем чисто-конференционный, потому что VOD-библиотека маскировала, сколько на самом деле стоит WebRTC-строка на пользователя. Всегда моделируйте WebRTC-трафик отдельной строкой, не как разновидность CDN-трафика – и цельтесь в TURN-relay-hit-ratio ниже 15%, инвестируя в калькулятор TURN-bandwidth до запуска, а не после.
Чувствительность: что больше всего влияет на счёт?
Если оптимизировать одну ручку, чтобы снизить счёт – какую? Tornado-диаграмма по модели 100k MAU показывает: средний битрейт рендеринга. Снижение на 25% среднего битрейта (отгрузка AV1 и отключение ступени 1080p high quality) экономит $6 800 в месяц напрямую на CDN – это 5,5% от всего счёта, при этом ничего больше не меняется. Это зона per-title encoding; техника описана в статье о per-title и per-shot градации битрейтов.
Вторая по эффективности мера – снижение ставки аналитики: переход с тарифа pay-as-you-go по $0,030/час на committed-use по $0,008/час даёт экономию в $26 400 в месяц при данном объёме. Третья – фиксированная ставка CDN за гигабайт. Четвёртая – коэффициент использования WebRTC TURN (каждое снижение на 5% экономит около $1 000 в месяц на real-time-реле).
Ручки, которые дают наименьший эффект: storage-тир (единицы долларов на процент), оптимизация упаковки (уже достигнуто ноль) и смена DRM-провайдера на этом объёме (в лучшем случае – несколько процентов).
Частая ошибка: путать concurrent с MAU
Самая частая ошибка моделирования – смешивать пиковый concurrent с monthly active. Продажи CDN ориентируются на пиковый concurrent (поскольку он определяет 95-ю перцентильную нагрузку и требования к burst-ёмкости). Продуктовые команды и финансы строят прогнозы на основе MAU (так как именно MAU влияет на выручку). Эти две метрики связаны моделью вовлечённости и распределения активности во времени: типичный пик concurrent составляет 5–15% от MAU для продуктов с акцентом на прямые трансляции и 0,5–2% – для VOD-only, в зависимости от распределения активности по дням недели и времени суток.
Для 100k-MAU-модели с 30% live-долей и субботне-вечерним пиком, накладывающимся на один hero-матч, пиковый concurrent – 4 000–8 000. Burst-capacity CDN должен быть посчитан на 4 000 × 4 Mbps = 16 Gbps, хотя средняя утилизация ближе к 6 Gbps. Если контракт coммитит на среднюю, вы платите overage каждый пик; если коммитит на пиковую, вы платите за headroom, который не используете большую часть месяца. Правильный контракт коммитит чуть ниже средней и аккуратно структурирует overage – покрыто в статье об экономике CDN.
Где используется Фора Софт
Мы строим и эксплуатируем стриминговые продукты в этом режиме с 2005 года – в видеоконференциях, OTT, телемедицине, e-learning, видеонаблюдении и AR/VR – и восьмистрочная модель выше – это та модель, которой мы руководствовались при проектировании архитектуры и переговорах с вендорами на большинстве из более чем 250 реализованных проектов. Обычно команды обращаются к нам на пике cost-кривой: продукт, достигший 50 000–100 000 MAU, начинает ощущать давление со стороны аналитики и счетов CDN и нуждается в архитектурном аудите, который может привести к пересмотру контрактов, смене стратегии масштабирования или решению о выборе между разработкой с нуля и покупкой готовых решений для реального времени. Мы не продаём SaaS-компоненты этой модели – мы команда, которая помогает выбрать и эффективно использовать их, и направляем на страницу сервиса по видеостримингу для тех, кому нужен партнёр по архитектуре end-to-end.
Ключевые выводы
- Валовая маржа стриминг-продукта складывается из восьми статей расходов, а не одной – CDN важен, но не всегда самый затратный.
- Кривая стоимости на одного зрителя в час резко меняется в диапазоне от 100 тыс. до 1 млн активных пользователей в месяц; ниже этого порога доминируют затраты на инженерию, выше – на CDN.
- На продуктах с подпиской и высокой вовлечённостью аналитика по модели pay-per-hour-счётчика постепенно обгоняет CDN по влиянию на расходы – стоит заранее перейти на модель с фиксированным обязательством.
- Выходной трафик с origin – скрытая статья расходов при переходе с облачного CDN на сторонний – может стоить от $5 до $30 тыс. в месяц.
- Трафик WebRTC обходится в 20–200 раз дороже на час использования на пользователя, чем HLS – никогда не моделируйте его как обычную нагрузку на CDN.
- Наиболее эффективный инструмент оптимизации – средний битрейт кодирования: каждый 25%-ный срез снижает общие затраты на 5–7%.
- Пороговые значения для выбора между разработкой и покупкой различаются: системы реального времени переходят на покупку при $10 тыс. в месяц, CDN – при $200 тыс. в месяц.
Что читать дальше
- Экономика CDN: 95-й перцентиль, commit, overage, transit – подробный разбор самой громкой строки этой модели.
- Построение лесенки битрейтов: классическая Netflix-лесенка, per-title, per-shot – самый мощный инструмент для настройки чувствительности.
- DRM 101: почему три системы и почему отгружаются все три – операционная логика строки с DRM.
CTA
- Поговорите с инженером стриминга. Принесите свой восьмистрочный счёт – мы подскажем, какие две строки стоит оптимизировать в следующем квартале.
- Посмотрите наши кейсы. Реальные архитектуры, построенные на основе модели, описанной в этой статье.
- Скачайте рабочий лист. Streaming Cost Model – One-Page Worksheet – восьмистрочный шаблон, конвертер единиц и таблица чувствительности на одном листе.