Egress-трафик: статья счёта, о которой узнают на третий месяц

MAATRIX

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

Что такое egress и почему это не «просто трафик»

В облачном биллинге трафик делится на входящий (ingress) и исходящий (egress) относительно границы дата-центра или виртуальной сети провайдера. Входящий — это всё, что попадает внутрь: загрузка файлов пользователями, приём вебхуков, репликация данных из внешних источников, импорт бэкапов. Исходящий — всё, что покидает инфраструктуру провайдера и уходит во внешний интернет: отдача статики, ответы API, стриминг видео, скачивание пользователями своих файлов, отправка событий во внешние системы.

Асимметрия в том, что ingress почти всегда бесплатен или стоит копейки, а egress тарифицируется по мере роста, часто с прогрессивной шкалой (первые несколько сотен гигабайт бесплатно или дёшево, дальше — по нарастающей ставке за гигабайт). При этом трафик между сервисами внутри одного региона одного провайдера обычно тоже бесплатен или дёшев — это ещё один нюанс, который путает при первой оценке: тестируя продукт внутри одной инфраструктуры, вы просто не видите настоящей стоимости выхода наружу.

Важно не путать egress с пропускной способностью канала (bandwidth). Пропускная способность — это скорость, с которой данные могут передаваться (мегабиты в секунду), она обычно фиксирована тарифным планом или конфигурацией сети. Egress — это объём переданных данных за период (гигабайты или терабайты в месяц), и именно объём, а не скорость, ложится в основу счёта у большинства облачных провайдеров.

Почему провайдеры тарифицируют именно так

Асимметричное ценообразование ingress/egress — не случайность и не техническое ограничение, а осознанная экономическая конструкция, у которой есть вполне рациональное обоснование сразу с нескольких сторон.

Себестоимость действительно асимметрична, но не радикально. У любого дата-центра есть аплинки к магистральным операторам и точки обмена трафиком (IX). Передача гигабайта наружу через транзитного оператора обходится дороже, чем через пиринг, а пиринговые соглашения провайдер выстраивает годами и не с каждым партнёром. Исходящий трафик почти всегда идёт «в последнюю милю» через цепочку операторов, где каждый берёт свою маржу; входящий проще — он дошёл до дата-центра, и дальше провайдеру нужно только принять и записать данные.

Бесплатный ingress — это экономический стимул «заезда». Провайдеру выгодно, чтобы вы завезли к нему как можно больше данных: чем больше данных внутри инфраструктуры, тем выше стоимость переезда к конкуренту. Это классический приём снижения издержек переключения (switching costs), только реализованный через ценовую асимметрию, а не техническое ограничение. Загрузить терабайты в облако — бесплатно и просто. Выгрузить обратно — платно, и чем больше накопилось, тем дороже одномоментный «выезд».

Платный egress создаёт барьер для мультиоблачности. Если бы исходящий трафик стоил столько же, сколько входящий, компаниям было бы выгоднее держать распределённые архитектуры сразу на нескольких провайдерах, свободно перемещая данные между ними. Плата за выход делает такие схемы дороже и подталкивает клиента концентрировать нагрузку у одного провайдера — там, где ingress уже бесплатно наполнил хранилище.

Egress — статья с высокой маржинальностью и низкой заметностью на старте. Выбирая облако, команда почти никогда не моделирует трафик всерьёз — внимание уходит на инстансы, диски, базы данных. Стоимость egress становится заметна только постфактум, когда продукт уже развёрнут и переезд стоит времени и риска: провайдер знает паттерн заранее, клиент — только через два-три месяца эксплуатации.

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

Где реально накапливается egress в типичном продукте

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

• Отдача статических файлов и медиа — изображения, видео, документы, экспорт отчётов. Если контент отдаётся напрямую с origin-сервера, а не через CDN с эффективным кэшированием, каждый повторный просмотр одного и того же файла разными пользователями — отдельный полный egress.
• API-ответы — особенно у продуктов с богатыми JSON-ответами (вложенные объекты, списки, base64-вложения в теле ответа). Одна и та же логическая операция может отдавать килобайты или сотни килобайт в зависимости от того, насколько экономно спроектирован формат.
• Скачивание пользователями собственных данных — экспорт, выгрузка бэкапов, «скачать всё». Часто разовое, но объёмное действие: пользователь, который раз в месяц выгружает архив на несколько гигабайт, создаёт скачок в биллинге, не соответствующий его повседневной активности.
• Межрегиональная репликация и синхронизация — если у вас несколько регионов или резервный контур в другом облаке, трафик между ними в большинстве случаев тоже тарифицируется как egress, причём межрегиональная ставка иногда даже выше обычной.
• Вебхуки и события, отправляемые вовне — уведомления, интеграции с внешними CRM и аналитикой. По отдельности незаметно, но при высокой частоте событий на большую базу набегает ощутимый объём.
• Резервное копирование во внешнее хранилище — если бэкапы уходят не в то же облако, а в другое место (что часто правильно с точки зрения отказоустойчивости), сам факт их выгрузки — это egress, причём регулярный.

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

Почему именно третий месяц: механика скрытого роста

Заголовок про «третий месяц» — не преувеличение, а типичный паттерн жизненного цикла продукта в облаке, который стоит разобрать по стадиям.

Месяц 1 — разработка и внутреннее тестирование. Трафик генерируют разработчики и QA, пользователей почти нет. Egress исчезающе мал, часто укладывается в бесплатный порог тарифа.

Месяц 2 — запуск и первые пользователи. Появляется реальный, но ещё небольшой поток. Команда фокусируется на стабильности, метриках конверсии, багах — трафик как статья расходов ещё не в фокусе внимания, тем более что счёт за этот период часто приходит уже после начала третьего месяца.

Месяц 3 — рост вовлечённости. Ранние пользователи возвращаются, начинают активнее пользоваться продуктом: смотрят больше контента, выгружают отчёты, синхронизируют данные между устройствами. Именно вовлечённость, а не просто количество аккаунтов, двигает egress — активный пользователь, который скачивает контент каждый день, создаёт на порядок больше исходящего трафика, чем зарегистрировавшийся и забывший про продукт.

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

Похожая, но не идентичная история — с ростом счёта без роста нагрузки: причины там чаще в неоптимальных конфигурациях, а не в органическом росте трафика, разбор — в статье про то, почему счёт за облако вырос вдвое без роста нагрузки.

Как оценить потенциальный счёт за egress заранее

Оценка «на глаз» почти всегда занижает реальный расход, потому что интуитивно люди считают средний случай, а egress формируется по хвосту распределения — активными пользователями, которые скачивают много. Рабочая методика строится не на угадывании точных цифр, а на построении формулы с параметрами, которые можно уточнять по мере поступления реальных данных.

Базовая формула для оценки:

Месячный egress ≈ (Число активных пользователей)
                 × (Среднее число сессий на пользователя в месяц)
                 × (Средний объём исходящих данных за сессию)
                 + (Разовые операции: экспорт, бэкап, синхронизация)

Порядок действий на практике:

1. Определите тип продукта и его «тяжёлые» сценарии. Текстовый API-сервис и видеохостинг находятся в принципиально разных весовых категориях по объёму egress на пользователя — разница может быть в тысячи раз. Сформулируйте для своего продукта 3–5 самых частых и самых объёмных пользовательских сценариев.
2. Измерьте объём данных на одно действие ещё на этапе разработки. Не гадайте — включите логирование размера ответа на каждый ключевой эндпоинт и посчитайте медиану и 95-й процентиль (хвост важнее медианы, потому что именно хвостовые сценарии — скачивание архива, полная синхронизация — двигают счёт).
3. Заложите не текущее, а прогнозное число активных пользователей — то, на которое рассчитан следующий этап роста, а не текущий MVP-трафик. Если планируете вырасти в 10 раз за полгода, egress вырастет примерно пропорционально DAU, но нелинейно от общего числа регистраций.
4. Отдельно посчитайте разовые и периодические объёмные операции — полные экспорты, миграции, резервные выгрузки. Они часто не входят в «типичную сессию», но регулярно повторяются (ежемесячный экспорт для бухгалтерии, еженедельный бэкап у B2B-клиента).
5. Заложите запас на пиковые периоды. Активность распределена неравномерно: акции, рассылки, сезонность резко поднимают egress именно тогда, когда его труднее контролировать вручную.
6. Сравните полученную оценку с бесплатным порогом и ступенями тарифа провайдера, а не с общей суммой счёта — прогрессивные тарифы означают, что превышение даже одной ступени может дать непропорциональный скачок стоимости.

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

Как снижать и контролировать egress на практике

Полностью убрать исходящий трафик нельзя — продукт существует, чтобы отдавать данные пользователям. Но объём и, что важнее, его стоимость можно уменьшать системно.

Кэширование и CDN на границе сети. Каждый ответ, отданный из кэша на edge-узле, а не с origin-сервера, — это egress, который либо не тарифицируется вовсе, либо тарифицируется по значительно более низкой ставке, чем прямой egress из вычислительного региона. Для статики и часто запрашиваемого контента это самый эффективный рычаг: правильно настроенный кэш способен сократить исходящий трафик origin-сервера в разы.

Сжатие ответов. Включённый gzip или brotli для текстовых ответов (JSON, HTML, CSS, JS) снижает объём передаваемых данных без потери информации. Для уже сжатых форматов (видео, изображения в современных кодеках, архивы) повторное сжатие бессмысленно и иногда даже увеличивает нагрузку на CPU без выигрыша в объёме — это стоит проверять отдельно для каждого типа контента.

Пересмотр формата API-ответов. Отдача только нужных полей вместо полного объекта (частичные ответы, пагинация, отказ от избыточной вложенности), а также отказ от base64-кодирования бинарных данных прямо в JSON — база64 увеличивает объём примерно на треть по сравнению с бинарной передачей того же файла.

Разделение горячих и холодных данных. Данные, которые скачиваются часто, стоит держать ближе к пользователю и за CDN; данные, которые скачиваются редко (архивные экспорты, старые бэкапы), можно отдавать напрямую без кэша — избыточное кэширование редко запрашиваемого контента не окупается.

Ограничение и алертинг. Настройте мониторинг объёма исходящего трафика по эндпоинтам и по клиентам с оповещением при превышении ожидаемого диапазона — это не снижает сам egress, но превращает сюрприз через два месяца в сигнал, замеченный через два дня.

Выбор модели тарификации под профиль нагрузки. У гипермасштабируемых облачных провайдеров исходящий трафик почти всегда тарифицируется постранично, по объёму, без верхнего предела расходов. У аренды VPS и выделенных серверов модель часто другая: включённый пакет трафика на тариф или тарификация по 95-му процентилю используемой полосы — при стабильно высокой, но предсказуемой отдаче контента это может оказаться дешевле и предсказуемее постраничного egress. Для продуктов с постоянным объёмным трафиком — видео, файловый хостинг, тяжёлые API — сравнение обеих моделей стоит закладывать ещё на этапе выбора инфраструктуры, а не постфактум.

Архитектурное разделение по регионам. Если у продукта есть выраженная география аудитории, размещение вычислительных мощностей ближе к основной массе пользователей сокращает не только задержку, но и путь трафика через дорогие транзитные участки — это снижает и себестоимость, и в некоторых случаях тарифную ставку egress.

Частые вопросы