Ваш план CloudAMQP каже $99 на місяць, але в рахунку стоїть $82.33, а наступного місяця — $114.07, і ви нічого не змінювали, окрім зміни розміру інстанса у вівторок. Усе гаразд. CloudAMQP не продає повідомлення. Він продає час роботи інстансів посекундно, виставляє рахунок через місяць і пропорційно розподіляє кожну зміну плану до тієї самої секунди, коли вона відбулася. Ціна за прайс-листом — це обмеження швидкості, а не обіцянка. Допоки ваш облік не почне трактувати рахунок як показник лічильника, а не як підписку, ваші інфраструктурні витрати будуть дрейфувати, нарахування проминатимуть ціль, а валова маржа тихо поглинатиме різницю.
У цій статті пояснюється, як CloudAMQP насправді обліковує та виставляє рахунки, як виглядають реалістичні рахунки, чому продакшн-брокер належить до собівартості продажів і як звіряти рахунки за час роботи інстансів, щоб кожен долар потрапляв на правильний рахунок.
Як CloudAMQP обліковує: час, а не повідомлення
CloudAMQP — це керований хостинг RabbitMQ і LavinMQ, який веде 84codes. Ви обираєте брокер, план і регіон, і отримуєте інстанс або кластер. Модель оплати прив'язана до інстанса, а не до трафіку, що через нього проходить, — це протилежність сервісам обміну повідомленнями з оплатою за запит, де розмір навантаження визначає рахунок. Тут два питання, що визначають ваш рахунок: наскільки великий інстанс ви запускали і скільки секунд.
Спільні плани мають квоти, виділені плани мають потужність
Спільні багатоорендні плани — єдине місце, де взагалі з'являється кількість повідомлень. Loyal Lemming безкоштовний із місячною квотою 2 мільйони повідомлень і 40 з'єднаннями, а Elegant Ermine коштує $19 на місяць із квотою 20 мільйонів повідомлень і 200 з'єднаннями. Вони підходять для розробки, прототипів і хобі-проєктів. Квота — це стеля, а не лічильник: ви не платите за повідомлення в її межах.
Виділені плани повністю відмовляються від підрахунку повідомлень. Ви отримуєте власний брокер або мульти-AZ кластер із них, і кожен виділений план запускає той самий рушій з тією самою швидкістю. Ви обираєте рівень за тим, скільки вміщує ваша система: з'єднання, черги та збережені повідомлення. Ланка однонодових LavinMQ тягнеться від Passionate Puffin за $49 на місяць через Playful Penguin за $99, Lively Lynx за $199 і Wild Wolverine за $499, з більшими рівнями вище. Конфігурації кластерів на один, три та п'ять нод обмінюють ціну на доступність. Передача даних включена в межах допустимого обсягу добросовісного використання, який сторінка цін визначає як безкоштовну передачу, що дорівнює 30 відсоткам місячних витрат вашої команди. Якщо ви його перевищите, у вас є 30 днів, щоб усунути перевищення, перш ніж плата за трафік почне з'являтися в наступних рахунках.
Практичний наслідок: ваш обсяг повідомлень може подвоїтися, не зрушивши рахунок ні на цент, доки інстанс ще вміщує з'єднання, черги та накопичення. І навпаки, перехід на більший рівень через те, що одна межа затиснула вас, переоцінює кожну секунду з цього моменту, навіть якщо трафік незмінний. Планування потужності, а не прогнозування трафіку, — це навичка, що керує цим рахунком.
Кожна секунда на рахунку, а рахунок приходить із місячним запізненням
Усі плани виставляються посекундно. Наприкінці кожного місяця ваш рахунок відображає точний час, протягом якого кожен інстанс був доступний для використання, тож інстанс, створений посеред місяця, видалений посеред місяця або змінений у розмірі посеред місяця, дає пропорційну плату, а не повний місяць чи нуль. Ви можете змінювати плани будь-коли без простою, і автомасштабування між рівнями має той самий ефект: кожен відрізок місяця оцінюється за рівнем, що діяв протягом тих секунд.
Оплата відбувається через місяць після надання послуги. Власний FAQ CloudAMQP каже це прямо: оплата пропорційна, клієнти платять лише за час, протягом якого послуга була їм доступна, і ви отримуєте перший рахунок на початку наступного місяця, а не під час реєстрації. Цей ритм із оплатою через місяць — найважливіший факт для вашого обліку. Немає нарахування на закритті, проти якого можна провести операцію, тож кожне закриття місяця потребує нарахування за невиставлений час роботи брокера, а кожен рахунок потребує коригування проти оцінки минулого місяця.
Важливі ще дві механіки виставлення рахунків. По-перше, передоплата: ви можете сплатити наперед від одного до кількох місяців, і передоплата дійсна один рік, перш ніж спливає. Клієнт на плані $99 може сплатити наперед дванадцять місяців і пропустити щомісячні платежі на рік, і кредит покриває кожен план на акаунті, тож додавання другого інстанса витрачає його швидше. Це передоплачений актив із однорічним запобіжником, а не витрата в момент платежу. По-друге, річного рахунку немає. Оскільки клієнти так часто змінюють плани, CloudAMQP не пропонує річного виставлення рахунків; кредит передоплати є заміною. Якщо ваш процес закупівель вимагає річного рахунку або окремих замовлень на кожну підписку, плануйте це заздалегідь: окремі замовлення вимагають окремих акаунтів, щоб підписки виставлялися окремо, а умови виставлення рахунків проходять через їхню команду виставлення рахунків, а не через потік самообслуговування з карткою.
Інстанси в маркетплейсі виставляються через платформу, а не через CloudAMQP
Якщо ви розгорнули через Heroku add-ons або маркетплейси AWS, Azure чи GCP, ці витрати взагалі не з'являються в рахунку CloudAMQP. Вони потрапляють до рахунку платформи — щомісячного рахунку Heroku або розбивки витрат вашого хмарного провайдера — під назвою цієї платформи. Це найпоширеніша прогалина у звірянні для команд, які запускають брокери у двох місцях: прямий рахунок звіряється чисто, тоді як його двійник у маркетплейсі ховається всередині більшого хмарного рахунку, часто класифікований як загальний хостинг. Вирішіть раз і назавжди, звідки виставляється кожен інстанс, і переконайтеся, що ваше зняття даних на кінець місяця охоплює як панель керування CloudAMQP, так і кожен маркетплейс, де він міг би сховатися.
Скільки це коштує на реалістичних конфігураціях
Ціни за прайс-листом мають сенс лише помножені на секунди, тож ось три конфігурації, побудовані з опублікованих цін для однонодових інстансів.
Побічний проєкт запускає staging на безкоштовному рівні Lemming і Puffin за $49 для невеликого продакшн-сервісу. Рядок брокера — $49 на місяць, фіксовано, і єдине завдання зі звіряння — підтвердити, що інстанс працював увесь місяць.
Зростаюча SaaS-команда запускає продакшн на Penguin за $99 і staging на Ermine за $19. Посеред місяця глибина черги змушує до оновлення: staging рівня Puffin залишається незмінним, але продакшн переходить із Puffin за $49 на Penguin за $99 на десятий день тридцятиденного місяця. Продакшн-частина оцінюється як десять днів за нижчим рівнем плюс двадцять днів за вищим, приблизно $16.33 плюс $66.00, або близько $82.33, а staging додає $19. Загальна сума рахунку сягає близько $101.33 для конфігурації, ціни за прайс-листом якої сумуються до $118. Наступного місяця, коли Penguin працює весь період, та сама конфігурація виставляє повні $118. Той, хто проводить ціну за прайс-листом обидва місяці, завищує перший місяць і нічого не занижує другого, — і це саме той дрейф, який карає посекундна оплата.
Більша компанія запускає тринодовий продакшн-кластер плюс staging і передоплачений кредитний баланс. Кластер множить ставку однонодового інстанса, зміни плану під час реагування на інциденти додають пропорційні відрізки, а передоплата поглинає загальну суму без списання з картки. Рахунок усе одно деталізує кожен інстанс і кожен відрізок, і саме списання кредиту — це число для проведення, а не нуль у виписці з картки.
Жодна з цих конфігурацій не стосується кількості повідомлень. Якщо ваша фінансова модель множить очікувані повідомлення на ставку за повідомлення, вона моделює іншого постачальника. Моделюйте рівні інстансів, помножені на очікувані секунди, і переглядайте припущення щодо рівня щоразу, коли зростання з'єднань чи черг змушує до зміни розміру.
Чому продакшн-брокер — це COGS, а не накладні витрати
Брокер повідомлень, який у продакшні переносить події замовлень, диспетчеризацію завдань і сповіщення клієнтів, є прямою витратою на надання вашого продукту. Він масштабується разом із бізнесом, він перестає мати значення тієї миті, коли нічого не продається, і він природно розташовується над лінією валової маржі поряд із обчисленнями, базою даних, сховищем і пропускною здатністю для продакшну. Практика валової маржі SaaS застосовує тест на прямі витрати: витрати, що існують для обслуговування клієнтів у продакшні, — це собівартість доходу, тоді як витрати, що будують, продають або адмініструють компанію, — це операційні витрати. Класичний SaaS має валову маржу 75–85 відсотків на цій основі, причому бізнеси з важкою інфраструктурою мають нижчу, і інвестори порівнюють вас із цими діапазонами.
Застосовуйте тест інстанс за інстансом, бо один акаунт CloudAMQP зазвичай містить кілька. Продакшн-брокери, що несуть клієнтські навантаження, проходять до собівартості продажів. Інстанси для staging, навантажувального тестування та пісочниць розробників не проходять і потрапляють до досліджень і розробок або загальних накладних витрат. Спільний Ermine, що запускає ваше staging-середовище, не є COGS лише тому, що ділить рахунок із продакшн-Penguin. Рахунок змішує їх разом, тож розділяйте його щомісяця за інстансами, користуючись розбивкою за інстансами в панелі керування. Команди, що пропускають розділення, зазвичай помиляються у приємливіший бік, ховаючи інфраструктуру в накладні витрати та звітуючи про маржу, яку їхня юніт-економіка не може захистити. Перевірка під час due diligence перекласифікує це за одну годину, і перерахована маржа ніколи не буває вищою.
Бухгалтерські стандарти це підтверджують. За ASC 350-40 керована хостингова домовленість, де постачальник керує програмним забезпеченням, є контрактом на послуги, і плата визнається витратою в міру понесення протягом періоду використання. Роботи з впровадження можуть мати власний облік, але щомісячна плата за час роботи інстансів — це витрата періоду, ніколи не капіталізований актив. Передоплати — це дзеркальне відображення: гроші виходять сьогодні, витрата пізніше, тож передоплата обліковується як передоплачений актив і вивільняється у витрати в міру використання кредиту. Проведення передоплати як витрати в день платежу завищує місяць платежу та занижує кожен місяць, який покриває кредит.
Проводьте чисту суму, яку ви фактично платите. Безкоштовний рівень Lemming — це безкоштовна потужність, а не дохід, тож немає чого донараховувати. Якщо ви хочете бачити, скільки коштувало б навантаження без нього, відстежуйте це у своїх метриках і тримайте бухгалтерську книгу за фактичною вартістю.
Як проводити, щоб рахунок звірявся
Виділіть брокеру власний рахунок собівартості продажів, а не змішуйте його із загальними хмарними чи програмними витратами. Виділений рахунок, як-от брокер повідомлень, дає змогу поділити місячні продакшн-витрати на місячні інстансо-секунди й побачити вашу справжню вартість на одиницю потужності — це число підказує, чи зміна розміру купила запас, чи лише більший рахунок.
Оскільки виставлення рахунків відбувається через місяць, ритм такий: нарахування, потім розрахунок, потім коригування. Оцінюйте частину брокера за рівнями інстансів і секундами на закритті, відокремлюйте продакшн від staging і коригуйте до рахунку, коли він надходить. Ось повний цикл для місяця, коли продакшн коштував $82.33 після зміни розміру посеред місяця, а staging додав $19.00:
2026-01-01 open Assets:Cash:Operating USD
2026-01-01 open Assets:Prepaid:CloudAMQP USD
2026-01-01 open Expenses:CostOfSales:Message-Broker USD
2026-01-01 open Expenses:Research:Staging-Infra USD
2026-01-01 open Liabilities:Accrued:CloudAMQP USD
2026-01-31 * "CloudAMQP" "Січнева оцінка, зміна розміру prod Puffin-to-Penguin плюс Ermine staging"
Expenses:CostOfSales:Message-Broker 82.33 USD
Expenses:Research:Staging-Infra 19.00 USD
Liabilities:Accrued:CloudAMQP -101.33 USD
2026-02-04 * "CloudAMQP" "Січневий рахунок розраховано, оцінка була точною"
Liabilities:Accrued:CloudAMQP 101.33 USD
Assets:Cash:Operating -101.33 USDКоли передоплата покриває місяць, частина розрахунку списує передоплачений актив замість грошових коштів. Запишіть передоплату як актив, коли ви її сплачуєте, а потім вивільняйте щомісячне споживання:
2026-01-05 * "CloudAMQP" "Передоплата 12 місяців Big Bunny за 99 на місяць"
Assets:Prepaid:CloudAMQP 1188.00 USD
Assets:Cash:Operating -1188.00 USD
2026-01-31 * "CloudAMQP" "Січневе споживання проти передоплати, prod плюс staging"
Expenses:CostOfSales:Message-Broker 82.33 USD
Expenses:Research:Staging-Infra 19.00 USD
Assets:Prepaid:CloudAMQP -101.33 USDВідстежуйте однорічний термін спливання передоплати так само, як ви відстежуєте будь-який кредит «використай або втрать». Баланс, що спливає, — це реальний збиток, і він заслуговує на нагадування в календарі, а не на виявлення під час прибирання наступного року. Якщо ви ведете облік у текстовому форматі, шаблони відстеження витрат у документації природно поширюються на розбивку брокера за інстансами.
Одна пастка класифікації: надбавка за перевищення передачі даних і більший рівень — обидва є витратами брокера, але означають різне. Зміна рівня — це запланована потужність; перевищення — це незаплановане спалювання понад допустимий обсяг добросовісного використання. Проводьте обидва на рахунок брокера, але позначайте або занотовуйте перевищення окремо, щоб місяць його появи читався як виняток, а не як нова базова лінія.
П'ять контролів, що тримають облік часу роботи інстансів чесним
Посекундна оплата винагороджує увагу й карає принцип «налаштував і забув». Ці п'ять контролів ловлять поширені дрейфи.
1. Звіряйте інстанс за інстансом, а не рахунок за рахунком
Зіставляйте кожен рядок рахунку з інстансом, який ви впізнаєте, на рівні, який ви авторизували, за секунди, що приблизно покривають місяць. Рядок для інстанса, яким ніхто не володіє, зазвичай є забутим staging-брокером або кластером для навантажувального тестування з трьох спринтів тому, що досі виставляється посекундно. Видаляйте безжально; тут немає винагороди за простійну потужність.
2. Записуйте кожну зміну розміру з її часовою міткою
Кожна зміна плану розбиває місяць на оцінені відрізки. Ведіть легкий журнал змін, навіть спільну нотатку з датою, інстансом, старим рівнем і новим рівнем, і звіряйте відрізки рахунку з ним. Без журналу змішана сума, як-от $82.33, є неперевіреною арифметикою. З ним математика звіряється за хвилину.
3. Залучайте витрати маркетплейсу до того самого огляду
Якщо якийсь інстанс виставляється через Heroku або хмарний маркетплейс, додайте ці рядки до того самого щомісячного огляду, що й прямий рахунок. Називайте маркетплейс в описі проводки, щоб наступний рецензент не шукав рядок CloudAMQP, якого ніколи не буде. Тут також ховається подвійне виставлення рахунків: інстанс, перенесений із маркетплейсу на пряме виставлення рахунків, іноді працює подвійно кілька днів.
4. Стежте за допустимим обсягом передачі даних, перш ніж він виставить рахунок
Передача даних включена до 30 відсотків витрат команди, із 30-денним вікном на вирішення після перевищення, перш ніж надбавки потраплять у наступні рахунки. Сприймайте перше повідомлення про перевищення як контроль, а не як надбавку. Перевірте, у якого інстанса підскочив трафік, підтвердіть, що це законне зростання, а не шторм повторних спроб чи балакучий споживач, і вирішіть це в межах вікна. Цикл повторних спроб, що розгортається на кластер, може перетворити тихий місяць на перевищення передачі, не змінивши жодного рівня.
5. Автоматизуйте зняття даних
Панель керування перелічує кожен рахунок, а клієнтський API надає операції з рахунками поряд з управлінням інстансами, тож зняття даних на кінець місяця не обов'язково має бути ручним кліканням у консолі. Заскриптуйте завантаження, розберіть рядки за інстансами й порівняйте з вашим журналом змін і вашим нарахуванням. Сама оцінка нарахування може надходити з тих самих даних: ставки рівнів, помножені на минулі секунди, — це краще за вгадування з минулого місячного підсумку щоразу, коли зміна розміру відбулася посеред циклу.
Контрольний список на кінець місяця для витрат на брокер
Замкніть цикл однаково щомісяця, щоб числа залишалися надійними:
- Перелічіть кожен інстанс і кластер, прямі та виставлені через маркетплейс, і підтвердіть, що кожен досі має власника та призначення.
- Звірте кожен рядок рахунку з інстансом, рівнем і часовим відрізком, користуючись журналом змін розміру для будь-яких змішаних сум.
- Відокремте продакшн від staging і пісочниці та підтвердіть, що до собівартості продажів потрапив лише продакшн.
- Скоригуйте нарахування минулого місяця до розрахованого рахунку та перенесіть відхилення в оцінку наступного місяця.
- Списуйте будь-яку передоплату за фактичним споживанням і перевіряйте залишок проти однорічного терміну спливання.
- Підтвердіть, що використання передачі залишилося в межах допустимого обсягу добросовісного використання, і вирішіть будь-яке повідомлення про перевищення в його 30-денному вікні.
- Підтвердіть, що кожен інстанс, створений протягом місяця, успадкував правильний тег середовища та потрапив на правильний рахунок із першого дня.
Витягніть рахунок CloudAMQP за цей місяць сьогодні та зіставте кожен рядок з інстансом, який ви можете назвати. Якщо кожен рядок зіставляється чисто, ваш облік брокера чесний. Якщо якийсь не зіставляється, ви щойно знайшли або забутий інстанс, що досі виставляється посекундно, або двійника в маркетплейсі, що ховається в іншому рахунку, — і кожна з цих знахідок окупає огляд.
