Перейти к основному содержимому

Исходящий трафик превыше всего: учёт помигабайтной тарификации исходящего трафика NATS в Synadia Cloud как переменных затрат на инфраструктуру в себестоимости

Опубликовано 12 мин чтенияMike ThriftMike Thrift
Исходящий трафик превыше всего: учёт помигабайтной тарификации исходящего трафика NATS в Synadia Cloud как переменных затрат на инфраструктуру в себестоимости
Содержание страницы

Вы оформили подписку на план Starter за 49 долларов и заложили в бюджет ровно эту сумму. А потом второй счёт приходит вдвое больше, и ничто в вашей панели управления не объясняет почему. Цена плана никогда не была ценой. Ценой были байты, покидающие облако. Synadia Cloud измеряет каждый гигабайт, который ваши приложения вытягивают из его сервиса NATS, и именно превышение превращает фиксированную подписку в переменный счёт, масштабирующийся вместе с вашим трафиком.

Время имеет значение. NATS получил статус graduated в CNCF 10 ноября 2026 года, имея более 400 миллионов загрузок и более 2 000 компаний, использующих его. Прямо сейчас волна команд переходит с самостоятельно развёрнутого NATS на управляемое облако, обменивая операционную рутину на счётчик, за которым они никогда раньше не следили. В этой статье объясняется, как Synadia Cloud тарифицирует сетевые данные, сколько это стоит при реалистичных объёмах, почему продакшн-обмен сообщениями относится к себестоимости продаж, а не к накладным расходам, и как его учитывать, чтобы ваша валовая маржа говорила правду.

Как Synadia Cloud тарифицирует сетевые данные​

Synadia применяет планы к командам, и каждая команда начинает с бесплатного плана Personal. Платная лестница коротка: Starter за 49 долларов в месяц, Pro за 199 долларов в месяц и Enterprise по индивидуальному контракту. Каждый уровень включает блок сетевых данных наряду с лимитами на подключения, стримы и хранилище. Personal включает 10 GiB, Starter — 100 GiB, Pro — 1 TiB, Enterprise — 2 TiB.

Включённый блок — это вся суть, потому что то, что происходит после него, зависит от вашего плана. На бесплатном плане Personal оплаты за превышение нет вообще. Если команда превышает 10 GiB, активные и новые клиентские подключения сбрасываются до следующего расчётного цикла или до повышения плана. Ваш всплеск трафика в день демо на Personal не стоит денег. Он стоит доступности.

На каждом платном плане превышение измеряется и списывается в конце расчётного цикла по тарифам, зависящим от типа трафика. Три ставки, различающиеся почти на порядок:

  • Клиентский и leaf-исходящий трафик: 9 центов за GiB
  • Исходящий трафик через шлюзы: 2 цента за GiB
  • Входящий и исходящий трафик маршрутов: 1 цент за GiB

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

Клиентский и leaf-исходящий трафик по 9 центов за GiB​

Это ставка, которая доминирует в реальных счетах, и она охватывает два способа, которыми ваши системы потребляют данные. Клиентский исходящий трафик — это каждый байт, доставленный из облака в ваши приложения: доставки подписчикам, ответы на запросы и чтение стримов. Leaf-исходящий трафик — та же идея, распространённая на периферию. Leaf-узел — это сервер NATS в вашей собственной сети, который исходящим соединением подключается к облачному хабу и связывает интерес к субъектам через этот канал, так что цех завода или розничный магазин за файрволом может публиковать и подписываться без какого-либо входящего правила файрвола.

Следствие для выставления счетов таково: периферия не бесплатна. Каждый байт, который облако передаёт вниз по leaf-каналу, — это исходящий трафик по верхней ставке. Leaf-подписка, ограниченная узким субъектом вроде orders.created, тянет ровно этот субъект. Ленивая подписка на всё тянет весь поток данных через 9-центовый канал. Ограничение интереса на периферии — это контроль затрат, а не просто хорошая практика.

Исходящий трафик через шлюзы по 2 цента за GiB​

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

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

Трафик маршрутов по 1 центу за GiB​

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

Сколько это стоит при реальных объёмах​

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

Побочный проект с парой сервисов укладывается во включённые 100 GiB плана Starter, не задумываясь об этом. Десять тысяч небольших сообщений в день, каждое доставляется двум потребителям, — это примерно 20 GiB в месяц. Счёт — 49 долларов фиксированно, без превышения, а эффективная ставка на включённые данные составляет около 49 центов за GiB. Ошибка в этом масштабе — переход на Pro ради запаса, который вам не нужен: 150 долларов в месяц дополнительно за гигабайты, к которым вы никогда не притронетесь.

Средняя SaaS-платформа, стримящая события заказов и уведомлений своим воркерам и двум периферийным leaf-узлам, генерирует около 1,2 TiB клиентского и leaf-исходящего трафика в месяц. На Starter это примерно 1 129 GiB превышения по 9 центов, или около 102 долларов сверх базовых 49 долларов, то есть счёт в 151 доллар. Это всё ещё дешевле 199 долларов у Pro, и точка безубыточности дальше, чем думает большинство команд: шаг в 150 долларов от Starter к Pro окупается только на сетевых данных лишь после примерно 1,6 TiB месячного превышения. Ниже этой черты вы переходите на更高的 план ради подключений, стримов или хранилища, но никогда ради блока данных. Выполните это деление, прежде чем нажимать кнопку повышения плана.

Теперь добавьте георепликацию. Та же платформа зеркалирует стримы между регионами для аварийного восстановления, добавляя 500 GiB исходящего трафика через шлюзы, и суммарный клиентский исходящий трафик составляет чуть менее 2 TiB на плане Pro. Клиентское превышение — это 960 GiB сверх включённого терабайта по 9 центов, или 86,40 доллара. Превышение по шлюзам — 500 GiB по 2 цента, или 10 долларов. Счёт — 199 плюс 96,40, то есть 295,40 доллара, и две трети превышения происходят из топологии репликации, которую никто не оценил, когда её рисовали на доске. Это повторяющаяся картина неожиданного счёта Synadia: не одно большое число, а fan-out и репликация, умножающие маленькую ставку.

Почему продакшн-обмен сообщениями — это переменные затраты в себестоимости, а не накладные расходы​

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

Стандарты бухгалтерского учёта оставляют здесь пространство для манёвра: общепринятые принципы не дают точного определения себестоимости продаж, и практика валовой маржи SaaS заполняет пробел тестом на прямые затраты. Спросите, существует ли расход, чтобы обслуживать клиентов в продакшне. Стримы, несущие события заказов, доставки, расходящиеся к клиентским воркерам, и leaf-каналы, питающие периферийные точки, обслуживающие клиентов, — все проходят тест. Staging-аккаунт, воспроизводящий трафик прошлой недели, топик для нагрузочного тестирования и подписки в песочнице разработчика — нет. Они относятся к исследованиям и разработке или к общим накладным расходам.

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

Учитывайте чистую сумму, которую вы фактически платите. Неиспользованные включённые данные не являются активом, а бесплатный уровень Personal не является выручкой, поэтому нечего доначислять или переносить. Если вы хотите видеть запас, отслеживайте потреблённые и включённые гигабайты в своих метриках, а в учёте оставляйте проводку по фактической стоимости.

Как это учесть, чтобы ваша маржа говорила правду​

Выделите обмену сообщениями собственный счёт себестоимости продаж, вместо того чтобы смешивать его с общей строкой облака или ПО. Отдельный счёт вроде cloud messaging позволяет разделить расходы за месяц на гигабайты исходящего трафика за месяц и увидеть вашу истинную стоимость за GiB — именно это число говорит вам, съедает ли рост fan-out маржу.

Списание Synadia происходит после конца месяца, поэтому начисляйте его. Оцените продакшн-часть по метрикам исходящего трафика на момент закрытия, скорректируйте до фактического счёта, когда он придёт, и держите непроизводственную часть вне себестоимости продаж. Вот полный цикл для января, когда продакшн дал оценочно 291,20 доллара против фактического счёта в 295,40 доллара, с отдельной командой Starter за 49 долларов для разработки:

2026-01-01 open Assets:Cash:Operating USD
2026-01-01 open Expenses:CostOfSales:Cloud-Messaging USD
2026-01-01 open Expenses:Research:Cloud-Sandbox USD
2026-01-01 open Liabilities:Accrued:Synadia USD
 
2026-01-31 * "Synadia" "January prod estimate, Pro base plus client-leaf and gateway overage"
  Expenses:CostOfSales:Cloud-Messaging  291.20 USD
  Liabilities:Accrued:Synadia  -291.20 USD
 
2026-02-03 * "Synadia" "January invoice settles at 295.40 plus 49.00 dev team"
  Liabilities:Accrued:Synadia  291.20 USD
  Expenses:CostOfSales:Cloud-Messaging  4.20 USD
  Expenses:Research:Cloud-Sandbox  49.00 USD
  Assets:Cash:Operating  -344.40 USD

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

Одна ловушка классификации, которой стоит избегать: дополнительные опции вроде дополнительных leaf-узлов, пакетов подключения и хранилища всё ещё являются затратами на обмен сообщениями, когда они обслуживают продакшн, но дополнение Remote System, связывающее вашу собственную самостоятельно развёрнутую систему NATS, — это выбор гибридной архитектуры. Если эта связь существует, чтобы поддерживать жизнь устаревшей локальной системы, а не обслуживать текущих клиентов, она относится туда, где живут затраты этой системы, а не в себестоимость продаж.

Пять мер контроля, которые не дают исходящему трафику съесть маржу​

Начните с дисциплины fan-out и размера полезной нагрузки. Вместе они воздействуют на множитель и множимое, и оба — задачи на один день.

1. Рассматривайте каждую доставку как покупку​

Каждая доставка подписчику — это отдельно тарифицируемый исходящий трафик, поэтому проверяйте, кто что получает. Прикрепляйте узкие области субъектов, чтобы каждый потребитель получал только те события, которые он обрабатывает, и удаляйте мёртвые подписки от выведенных из эксплуатации воркеров. Нефильтрованный fan-out платит за доставку сообщений, которые потребитель отбрасывает при получении. Это чистые потери с исправлением в одну строку на подписку.

2. Посадите полезную нагрузку на диету​

Держите события лёгкими. Храните полный документ в объектном хранилище и отправляйте ссылку с идентификаторами, которые нужны потребителю, — шаблон claim-check. Уберите встроенные блобы, дублирующиеся записи клиентов и многословный отладочный контекст из горячего пути. Каждый гигабайт, который вы убираете, экономит 9 центов на каждой доставке каждого сообщения, которое его несло, поэтому размер полезной нагрузки обычно обгоняет выбор плана как рычаг экономии.

3. Жёстко ограничивайте интерес leaf-узлов​

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

4. Держите стримы рядом с их потребителями​

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

5. Подбирайте план по размеру и следите за скоростью сжигания​

Отслеживайте потреблённые и включённые гигабайты еженедельно, а не ежемесячно, потому что превышение накапливается незаметно до закрытия цикла. Помните о точке безубыточности в 1,6 TiB, прежде чем повышать Starter до Pro по причинам, связанным с данными, и помните об обрыве Personal в другую сторону: команды, прототипирующие на бесплатном уровне, должны повышать план до любого значимого для них всплеска трафика, потому что Personal отвечает на превышение сбросом подключений, а не счётом.

Чек-лист закрытия месяца по затратам на обмен сообщениями​

Закрывайте цикл одинаково каждый месяц, чтобы цифры оставались достоверными:

  1. Берите гигабайты исходящего трафика по типу трафика из панели управления, а не количество логических сообщений из логов приложений.
  2. Разделите расходы каждого типа на его гигабайты и сравните с ориентирами в 9, 2 и 1 цент.
  3. Вычислите fan-out доставок по субъекту, разделив доставки на публикации; всё, что выше вашего проектного коэффициента, заслуживает пересмотра подписок.
  4. Разделите продакшн, staging и использование песочницы по аккаунтам и подтвердите, что в себестоимость продаж попал только продакшн.
  5. Скорректируйте начисление прошлого месяца до фактического счёта и перенесите расхождение вперёд в свою оценку.
  6. Проверьте трафик шлюзов как долю общего исходящего трафика и подтвердите, что у каждого межрегионального потока всё ещё есть архитектурная причина.
  7. Подтвердите, что каждый новый аккаунт, стрим и leaf-узел, созданные за месяц, унаследовали маркировку продакшна и узкие области субъектов.

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

Источник: https://beancount.io/ru/blog/2026/11/11/synadia-cloud-nats-egress-pricing-variable-cogs-guide

Опубликовано: 11 ноября 2026 г.

11 мин чтения

Правило фрагментации по 64 КБ: как учитывать оплату за запросы AWS SQS/SNS как переменную себестоимость

SQS и SNS тарифицируют каждый фрагмент по 64 КБ за вызов API, поэтому сообщение…

cost-of-goods-sold
cloud-services
13 мин чтения

Поминутная тарификация, а не по сообщениям: сверка счетов CloudAMQP за время работы инстансов как инфраструктурная себестоимость

CloudAMQP тарифицирует время работы инстансов по секундам с оплатой в конце…

cost-of-goods-sold
cloud-services
12 мин чтения

Не места, а представления признаков: учёт биллинга потребляемых кредитов Tecton как COGS по ASC 606 для ML-платформы

Tecton выставляет счёт за потребляемые кредиты плюс облачные расходы в вашем…

cost-of-goods-sold
machine-learning
11 мин чтения

Распределение облачных затрат для небольших SaaS-команд: практическое руководство по шоубэку

30-дневный план шоубэка для небольших SaaS-команд — определите аналитические…

saas
cloud-services
12 мин чтения

Ваш счёт за вебхуки — это себестоимость, а не накладные расходы: учёт событийного SaaS на Svix и Hookdeck

Счета Svix и Hookdeck — это себестоимость выручки, а не накладные расходы:…

saas
cost-of-goods-sold