Гигабайт на своём сервере против облачного egress: разница в разы

MAATRIX

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

Почему трафик — это не мелкий пункт в счёте

Compute (CPU, RAM, диск) — предсказуемая статья расходов и на арендованном сервере, и в облаке: цена не скачет от того, сколько запросов обработал сервер. Трафик — другое дело: единственный ресурс, объём которого напрямую зависит от поведения пользователей и растёт нелинейно — у сервиса с видео или файлообменом рост аудитории в два раза может дать рост исходящего трафика в три-четыре раза.

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

Как считают трафик: включённый лимит сервера против egress-тарифа облака

Модели принципиально разные, и путать их — источник большинства ошибок в прогнозах бюджета.

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

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

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

У кого разница ощутима: профиль нагрузки с высоким исходящим трафиком

Не для всех проектов это вообще имеет значение. Ключевой параметр — соотношение исходящего трафика к остальной нагрузке.

Где разница минимальна:

• Обычный сайт-визитка или блог с преимущественно текстовым и HTML-контентом, за CDN или без него — исходящий трафик в единицы-десятки гигабайт в месяц.
• Внутренний B2B-сервис с редкими, короткими API-ответами (JSON на несколько килобайт).
• Проект на раннем этапе с небольшой аудиторией — счёт за egress в обеих моделях будет незаметен на фоне остальных расходов.

Где разница становится критичной:

• Видеосервисы и стриминг. Каждое воспроизведение — это мегабайты или гигабайты исходящего трафика на пользователя. При тысячах просмотров в день объём легко достигает десятков терабайт в месяц.
• Файлообменники, облачные хранилища, бэкап-сервисы. Пользователи не только загружают, но и постоянно скачивают файлы — синхронизация клиента, шаринг ссылками, восстановление из бэкапа генерируют исходящий трафик кратно объёму самого хранилища.
• API с большими ответами. Экспорт данных, выгрузка отчётов, эндпоинты, отдающие изображения или медиафайлы напрямую (не через отдельный CDN), генерация PDF и отдача его клиенту — всё это тяжёлые исходящие ответы, которые в сумме за месяц дают заметный объём.
• Игровые серверы и системы с частой синхронизацией состояния — трафик небольшой на одно сообщение, но частота передач компенсирует размер.

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

Методика: измеряем реальный объём исходящего трафика приложения

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

Способ 1 — счётчики интерфейса на самом сервере. Самый быстрый способ получить общую картину по исходящему трафику интерфейса:

# Установка (Debian/Ubuntu)
apt install vnstat

# Трафик по месяцам, отдельно rx (входящий) и tx (исходящий)
vnstat -m

# То же самое в машиночитаемом виде
vnstat --json m

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

Способ 2 — разбор логов веб-сервера, если нужна не общая цифра, а разбивка по эндпоинтам или типам контента. В nginx для этого удобно завести отдельный log_format с явным полем размера ответа:

log_format traffic '$time_local $body_bytes_sent $request_uri';
access_log /var/log/nginx/traffic.log traffic;

Дальше суммируем размер ответов за нужный период:

awk '{sum += $2} END {print sum/1024/1024/1024 " GB"}' /var/log/nginx/traffic.log

Этот же лог легко превратить в разбивку по URI (awk '{sum[$3]+=$2} END {for (u in sum) print sum[u]/1024/1024, u}'), чтобы увидеть, какая часть приложения формирует основной объём — обычно 80–90% трафика даёт небольшая доля эндпоинтов (раздача файлов, видео, экспортов).

Способ 3 — биллинг самого облака, если приложение уже там: раздел использования у любого облачного провайдера показывает фактический egress по месяцам и обычно с разбивкой по сервису и направлению (внутри региона, между регионами, в интернет). Это самая точная цифра, потому что именно её умножают на тариф — не нужно ничего пересчитывать из логов.

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

Собранная за 2–3 месяца цифра — с поправкой на сезонность и рост — и есть та T (трафик в гигабайтах), которую дальше подставляем в расчёт стоимости.

Считаем эффективную стоимость гигабайта и сравниваем модели

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

Эффективная стоимость на арендованном сервере. Если трафик укладывается в лимит тарифа (или тариф безлимитный), предельная стоимость каждого дополнительного гигабайта равна нулю — вы уже заплатили за него в фиксированной цене аренды. Формально эффективную стоимость гигабайта можно посчитать как:

Цена_гб_сервер = Стоимость_тарифа_в_месяц / Фактический_трафик_в_месяц_ГБ

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

Эффективная стоимость в облаке. Здесь она считается напрямую — это и есть тариф провайдера за egress, с поправкой на ступенчатую шкалу:

Стоимость_трафика_облако = Σ (объём_в_ступени × ставка_ступени)
Цена_гб_облако = Стоимость_трафика_облако / Фактический_трафик_ГБ

Сравнение имеет смысл проводить не по абстрактной "цене за гигабайт", а по итоговому счёту при одинаковой нагрузке. Шаблон для собственного расчёта:

Подставьте свои A, B, L, T и E (последние два — из расчётов выше и из тарифной сетки провайдера) — и разница видна сразу, без вымышленных цифр. На практике при высоком T (десятки-сотни терабайт в месяц для видео или файлового сервиса) слагаемое T × E в облаке начинает доминировать над стоимостью compute настолько, что итоговый счёт оказывается кратно выше эквивалентного по мощности арендованного сервера — именно это и стоит за формулировкой "разница в разы": она не универсальна, а линейно растёт вместе с объёмом трафика. Подробный разбор того, как формируется ставка за гигабайт и почему её редко считают заранее, есть в статье про цену гигабайта трафика.

Нюансы и подводные камни простого сравнения

Прямое сравнение выше — честная отправная точка, но не вся картина. Несколько оговорок, которые ломают слишком простые выводы в любую сторону.

• "Безлимитный" трафик не всегда буквально безлимитный. У многих провайдеров есть политика добросовестного использования (fair use) — аномально высокий трафик может привести к ограничению скорости порта. Условия стоит уточнять перед миграцией тяжёлого по трафику проекта, а не полагаться на слово "безлимит" в маркетинге.
• Даже щедрый лимит конечен. Если трафик стабильно растёт, стоит заранее прикинуть, когда он упрётся в потолок тарифа и что происходит при превышении — доплата за ГБ, ограничение скорости или переход на другой тариф.
• Внутренний трафик дата-центра тоже может тарифицироваться — как в облаке между зонами доступности, так и у части хостеров при обмене между собственными серверами. При архитектуре из нескольких серверов с интенсивным обменом это отдельная статья расчёта.
• CDN перед источником меняет картину в обеих моделях. Кеширующий слой снижает трафик, реально уходящий с origin-сервера, — разница между моделями становится менее выраженной, потому что отдача идёт из кеша CDN, а не с оплачиваемого egress-канала. Считать нужно именно трафик origin, а не весь объём, отданный пользователям.
• Облако даёт то, чего нет у голой аренды — эластичность под пиковую нагрузку, managed-сервисы, встроенную геораспределённость. Если это реально нужно продукту, цена за гигабайт — не единственный критерий, но для стабильно высокой отдачи трафика этот аргумент часто перевешивается счётом за egress.
• Миграция данных из облака тоже стоит денег — это тот же egress, только разовый и в большом объёме. Если план — переехать с накопленными данными позже, эту статью расходов стоит прикинуть заранее; подробнее — в статье о неожиданном счёте за egress-трафик.

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

Практический план: как выбрать модель под свой трафик

1. Измерьте фактический трафик способами из раздела выше — минимум за 2–3 месяца, с учётом сезонности и растущей траектории, а не по одному замеру.
2. Посчитайте порог, при котором стоимость трафика в облаке сравняется со стоимостью аренды эквивалентного по compute сервера — используйте таблицу и формулы выше со своими цифрами A, B, T, E.
3. Сравните траекторию роста, а не только текущее состояние: если трафик растёт быстрее выручки или аудитории, посчитайте эффект через 6–12 месяцев — иногда именно скорость роста определяет выбор модели. Общий подход к такому прогнозу — в статье про расчёт порога, когда трафик растёт быстрее выручки.
4. Рассмотрите гибрид, если часть нагрузки тяжёлая по трафику, а часть — нет: тяжёлые по отдаче компоненты (видео, файлы, статика) держать на арендованном сервере с включённым трафиком, эластичные вычисления — в облаке. Это часто даёт лучший баланс, чем выбор одной модели для всего.
5. Не забудьте про CDN как отдельный рычаг: он снижает исходящий трафик origin-сервера в обеих моделях и может сам по себе изменить решение, если планируете тяжёлый по трафику проект.
6. Заложите запас, а не считайте впритык — трафик исторически растёт рывками (вирусный контент, сезонный пик, рекламная кампания), и именно тогда разница между включённым и оплачиваемым трафиком ощущается больнее всего. Более широкий взгляд на TCO — в статье TCO выделенного сервера против облака за три года.

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