Ви підписалися на план Starter за 49 доларів і заклали в бюджет саме цю суму. А потім другий рахунок приходить удвічі більшим, і ніщо у вашій панелі керування не пояснює чому. Ціна плану ніколи не була ціною. Нею були байти, що залишають хмару. Synadia Cloud вимірює кожен гігабайт, який ваші застосунки витягують із її сервісу NATS, і саме перевищення перетворює фіксовану підписку на змінний рахунок, що масштабується разом із вашим трафіком.
Час має значення. NATS випущено з CNCF 10 листопада 2026 року — з понад 400 мільйонами завантажень і понад 2 000 компаній, що його використовують. Хвиля команд зараз переходить із self-hosted 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 egress: 9 центів за GiB
- Gateway egress: 2 центи за GiB
- Route ingress і egress: 1 цент за GiB
Зверніть увагу, чого немає в цьому списку. Публікація в хмару не вимірюється. Лічильник працює на байтах, що витікають, а це означає, що fan-out є множником на кожному рахунку Synadia. Одне повідомлення, опубліковане один раз і доставлене десятьом споживачам, — це десять доставок egress, а не одна.
Клієнтський і leaf egress за 9 центів за GiB
Це тариф, який домінує в реальних рахунках, і він охоплює два способи споживання даних вашими системами. Клієнтський egress — це кожен байт, доставлений із хмари вашим застосункам: доставки підписникам, відповіді request-reply і читання потоків. Leaf egress — це та сама ідея, поширена на edge. Leaf-вузол — це сервер NATS у вашій власній мережі, який набирає з'єднання до хмарного хаба й з'єднує інтерес до суб'єктів через це посилання, тож цех заводу або роздрібний магазин за фаєрволом може публікувати й підписуватися без жодного вхідного правила фаєрвола.
Наслідок для рахунків: edge не безкоштовний. Кожен байт, який хмара пересилає вниз leaf-посиланням, — це egress за найвищим тарифом. Leaf-підписка, обмежена вузьким суб'єктом на кшталт orders.created, тягне саме цей суб'єкт. Лінива підписка на все тягне весь потік через 9-центове посилання. Обмеження інтересу на edge — це контроль витрат, а не просто добра гігієна.
Gateway egress за 2 центи за GiB
Gateway об'єднують кластери в суперкластер, зазвичай між регіонами, щоб робоче навантаження в одному регіоні могло дістатися суб'єктів в іншому. Gateway egress — це трафік реплікації та міжрегіональний трафік між цими кластерами, що вимірюється за 2 центи за GiB.
Два центи звучать незначно, доки не згадаєте, що вони накладаються поверх власних плат за передачу хмарного провайдера. Власні операційні настанови Synadia позначають високе співвідношення gateway-трафіку як проблему, варту виправлення, зазначаючи, що передача між зонами доступності сама по собі коштує близько цента за гігабайт у кожному напрямку. Команда, що інтенсивно реплікує між регіонами, платить провайдеру за передачу й лічильнику Synadia за gateway на тих самих байтах. Тримайте видавців, потоки та споживачів в одному регіоні, якщо архітектура справді не потребує георозподілу.
Route-трафік за 1 цент за GiB
Routes — це внутрішньокластерні посилання між серверами NATS, що несуть службовий трафік маршрутизації та реплікації, який підтримує цілісність кластера. За цент за GiB в обох напрямках це найдешевший лічильник на сторінці — так задумано. Він існує, щоб запуск стійкої багатосерверної топології не карав вас. Якщо route-трафік колись стане помітною статтею у вашому рахунку, щось структурно не так, бо потрібно в дев'ять разів більше обсягу, щоб зрівнятися з доларом клієнтського egress.
Скільки це коштує за реальних обсягів
Тарифи за гігабайт мають сенс лише перемножені, тож ось три реалістичні конфігурації.
Пет-проєкт із кількома сервісами вкладається в 100 GiB Starter без жодних думок. Десять тисяч невеликих повідомлень на день, кожне доставлене двом споживачам, переміщує приблизно 20 GiB на місяць. Рахунок — 49 доларів фіксовано, нуль перевищення, а ефективний тариф на включені дані — близько 49 центів за GiB. Помилка на цьому масштабі — оновлення до Pro заради запасу, який вам не потрібен: на 150 доларів на місяць більше, щоб тримати гігабайти, яких ви ніколи не торкаєтеся.
SaaS-платформа середнього розміру, що стрімить події замовлень і сповіщень своїм воркерам і двом edge leaf-вузлам, виштовхує близько 1,2 TiB клієнтського та leaf egress на місяць. На Starter це приблизно 1 129 GiB перевищення за 9 центів, або близько 102 доларів понад базові 49 доларів, — рахунок 151 долар. Усе ще дешевше за 199 доларів Pro, і точка беззбитковості далі, ніж більшість команд думає: крок у 150 доларів зі Starter до Pro окуповується лише за рахунок мережевих даних тільки після приблизно 1,6 TiB місячного перевищення. Нижче цієї межі ви оновлюєтеся заради з'єднань, потоків чи сховища, але ніколи заради блоку даних. Виконайте це ділення, перш ніж натиснути «оновити».
Тепер додайте геореплікацію. Та сама платформа дзеркалить потоки між регіонами для аварійного відновлення, додаючи 500 GiB gateway egress, і сумарний клієнтський egress сягає трохи менше 2 TiB на плані Pro. Клієнтське перевищення — 960 GiB понад включений терабайт за 9 центів, або 86,40 доларів. Перевищення gateway — 500 GiB за 2 центи, або 10 доларів. Рахунок — 199 плюс 96,40, тобто 295,40 доларів, і дві третини перевищення походять від топології реплікації, яку ніхто не оцінював, коли її малювали на дошці. Це повторювана форма несподіваного рахунку Synadia: не одне велике число, а fan-out і реплікація, що множать маленький тариф.
Чому продакшн-меседжинг — це змінні COGS, а не накладні витрати
Меседжинг, що доставляє ваш продукт платним клієнтам, — це прямий витрати доходу. Він масштабується разом із використанням, зникає, коли нічого не продається, і інвестори очікують бачити його вище лінії валової маржі разом із обчисленнями, базою даних, сховищем і пропускною здатністю для продакшену.
Стандарти бухгалтерського обліку залишають тут простір: загальноприйняті принципи не дають точного визначення собівартості продажів, і практика валової маржі SaaS заповнює прогалину тестом на прямі витрати. Запитайте, чи існують витрати, щоб обслуговувати клієнтів у продакшені. Потоки, що несуть події замовлень, доставки, що розгалужуються до клієнтських воркерів, і leaf-посилання, що живлять edge-локації, які обслуговують клієнтів, — усі проходять. Staging-акаунт, що відтворює минулотижневий трафік, тема для навантажувального тестування й підписки в пісочниці розробника — ні. Вони належать до досліджень і розробок або загальних накладних витрат.
Межа продакшену — це вся гра. Один рахунок Synadia змішує кожен акаунт і кожен тип трафіку разом, тож розділяйте його щомісяця, використовуючи використання по акаунтах із панелі керування. Команди, що пропускають розділення, зазвичай помиляються в прикрашальному напрямку, ховаючи інфраструктуру в накладних витратах і звітуючи валову маржу, яку їхня юніт-економіка не може захистити. Перевірка під час due diligence перекласифікує це за один день, і перерахована маржа ніколи не буває вищою.
Обліковуйте чисту суму, яку ви фактично платите. Невикористані включені дані не є активом, а безкоштовний рівень Personal не є доходом, тож немає чого збільшувати чи переносити вперед. Якщо ви хочете бачити запас, відстежуйте спожиті проти включених гігабайтів у своїх метриках, а обліковий запис тримайте за грошовою вартістю.
Як обліковувати це, щоб ваша маржа відображала правду
Дайте меседжингу власний рахунок собівартості продажів, а не змішуйте його із загальною статтею хмари чи програмного забезпечення. Виділений рахунок, наприклад cloud messaging, дозволяє поділити місячні витрати на місячні гігабайти egress і побачити вашу справжню вартість за GiB — саме це число підказує, чи зростання fan-out з'їдає маржу.
Платіж Synadia проходить після кінця місяця, тож нараховуйте його. Оцініть продакшн-частину за метриками egress на закритті, скоригуйте до рахунку, коли він надійде, і тримайте непродакшн-частину поза собівартістю продажів. Ось повний цикл для січня, коли продакшн оцінювався у 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Звіряйте нараховану суму з мережевим використанням по акаунтах у панелі керування принаймні щомісяця, з клієнтським, gateway- і route-трафіком як окремими рядками, щоб сплеск в одному не ховався за пласким трендом інших. Якщо ви ведете облік у plain text, патерни відстеження витрат у документації природно поширюються на розподіл меседжингу за типами трафіку.
Одна класифікаційна пастка, якої слід уникати: аддони, як-от додаткові leaf-вузли, пакети підключення та сховище, — це все ще витрати на меседжинг, коли вони обслуговують продакшн, але аддон Remote System, що з'єднує вашу власну self-hosted систему NATS, — це вибір гібридної архітектури. Якщо це посилання існує, щоб підтримувати життя застарілої on-premises системи, а не щоб обслуговувати поточних клієнтів, воно належить туди, де живуть витрати цієї системи, а не до собівартості продажів.
П'ять контролів, що не дають egress з'їсти маржу
Почніть із дисципліни fan-out і розміру корисного навантаження. Разом вони адресують множник і множене, і обидва — виправлення на один день.
1. Ставтеся до кожної доставки як до покупки
Кожна доставка підписнику — це окремо виміряний egress, тож перевіряйте, хто що отримує. Прикріплюйте вузькі області суб'єктів, щоб кожен споживач отримував лише ті події, які він обробляє, і видаляйте мертві підписки від виведених із експлуатації воркерів. Нефільтрований fan-out платить за доставку повідомлень, які споживач відкидає на прибутті. Це чисте марнотратство з виправленням в один рядок на підписку.
2. Посадіть корисне навантаження на дієту
Тримайте події легкими. Зберігайте повний документ у об'єктному сховищі й надсилайте посилання з ідентифікаторами, які потрібні споживачу, — патерн claim-check. Видаляйте вбудовані блоби, дубльовані записи клієнтів і багатослівний контекст налагодження з гарячого шляху. Кожен гігабайт, який ви прибираєте, економить 9 центів на кожній доставці кожного повідомлення, що його ніс, — ось чому розмір корисного навантаження зазвичай перемагає вибір плану як важіль економії.
3. Жорстко обмежуйте інтерес leaf-вузлів
Leaf-посилання пересилає лише суб'єкти, до яких є інтерес з іншого боку, що робить edge-підписку клапаном на 9-центовій трубі. Переглядайте кожну leaf-підписку щокварталу й підтверджуйте, що кожна досі обслуговує робоче навантаження в edge. Одна забута підписка-«catch-all» в одному магазині може тихо протягнути весь простір суб'єктів через найдорожче посилання в рахунку.
4. Тримайте потоки поблизу їхніх споживачів
Розміщуйте видавців, потоки та споживачів в одному регіоні, де дозволяє архітектура. Міжрегіональна реплікація платить перевищення gateway плюс базову передачу провайдера за ті самі байти, тож вважайте кожен гігабайт gateway винним, доки не доведено необхідність. Якщо аварійне відновлення справді потребує другого регіону, реплікуйте найменший набір суб'єктів, що задовольняє ціль відновлення, а не весь акаунт.
5. Підбирайте план за розміром і стежте за швидкістю витрат
Відстежуйте спожиті проти включених гігабайтів щотижня, а не щомісяця, бо перевищення накопичується тихо до закриття циклу. Пам'ятайте про точку беззбитковості 1,6 TiB, перш ніж оновлювати Starter до Pro з причин, пов'язаних із даними, і пам'ятайте про обрив Personal в інший бік: команди, що прототипують на безкоштовному рівні, мають оновитися до будь-якого сплеску трафіку, який їм важливий, бо Personal відповідає на перевищення скиданням з'єднань, а не рахунком.
Контрольний список кінця місяця для витрат на меседжинг
Закривайте цикл однаково щомісяця, щоб числа залишалися надійними:
- Беріть гігабайти egress за типом трафіку з панелі керування, а не логічні кількості повідомлень із журналів застосунку.
- Діліть витрати кожного типу на його гігабайти й порівнюйте з орієнтирами 9, 2 і 1 цент.
- Обчислюйте fan-out доставок на суб'єкт, ділячи доставки на публікації; усе, що перевищує ваш проєктний коефіцієнт, заслуговує на перегляд підписок.
- Розділяйте продакшн від staging і пісочниці по акаунтах і підтверджуйте, що до собівартості продажів потрапив лише продакшн.
- Скоригуйте нарахування минулого місяця до розрахованого рахунку й переносьте відхилення вперед у своїй оцінці.
- Перевіряйте gateway-трафік як частку загального egress і підтверджуйте, що кожен міжрегіональний потік досі має архітектурну причину.
- Підтверджуйте, що кожен новий акаунт, потік і leaf-вузол, створений протягом місяця, успадкував тегування продакшену й вузькі області суб'єктів.
Витягніть мережеві рядки Synadia за цей місяць із панелі керування сьогодні й порівняйте сумарні гігабайти egress із включеним блоком. Якщо перевищення зростає швидше за клієнтське використання, fan-out або реплікація множать тариф, і ваша найдешевша перемога в маржі — менше корисне навантаження й тугіші підписки, а не більший план.
