Ваш тариф CloudAMQP стоит $99 в месяц, но в счете указано $82.33, а в следующем месяце — $114.07, при этом вы ничего не меняли, кроме изменения размера инстанса во вторник. Всё в порядке. CloudAMQP не продаёт сообщения. Он продаёт время работы инстанса по секундам, выставляет счёт в конце месяца и пропорционально распределяет каждое изменение тарифа до той самой секунды, когда оно произошло. Цена в прайсе — это ограничение, а не обещание. Пока ваша бухгалтерия не начнёт относиться к счёту как к показанию счётчика, а не к подписке, ваши инфраструктурные расходы будут дрейфовать, начисления будут промахиваться, а валовая маржа тихо поглотит разницу.
В этом посте объясняется, как CloudAMQP на самом деле измеряет и выставляет счета, как выглядят реалистичные счета, почему production-брокер относится к себестоимости продаж и как сверять счета за время работы инстансов, чтобы каждый доллар попал в правильный счёт.
Как 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 или маркетплейсы AWS, Azure или GCP, расходы вообще не появятся в счёте CloudAMQP. Они попадают в счёт платформы — ежемесячный счёт Heroku или разбивку затрат вашего облачного провайдера — под наименованием этой платформы. Это самый распространённый пробел в сверке для команд, запускающих брокеры в двух местах: прямой счёт сверяется чисто, пока его двойник из маркетплейса скрывается внутри более крупного облачного счёта, часто классифицированный как общий хостинг. Решите один раз, откуда выставляется каждый инстанс, и убедитесь, что ваша выборка на конец месяца охватывает как панель управления CloudAMQP, так и каждый маркетплейс, где он может скрываться.
Сколько это стоит при реалистичных конфигурациях
Цены из прайса имеют смысл только умноженными на секунды, поэтому вот три конфигурации, построенные из опубликованных цен одноузловых тарифов.
Хобби-проект запускает staging на бесплатном уровне Lemming и Puffin за $49 для небольшого production-сервиса. Строка брокера — $49 в месяц, фиксированно, и единственная задача сверки — подтвердить, что инстанс работал весь месяц.
Растущая SaaS-команда запускает production на Penguin за $99 и staging на Ermine за $19. В середине месяца глубина очереди вынуждает к апгрейду: staging уровня Puffin остаётся на месте, но production переходит с Puffin за $49 на Penguin за $99 на десятый день тридцатидневного месяца. Производственная часть оценивается как десять дней по нижнему уровню плюс двадцать дней по верхнему, примерно $16.33 плюс $66.00, или около $82.33, а staging добавляет $19. Итог счёта оказывается около $101.33 для конфигурации, чьи цены из прайса в сумме дают $118. В следующем месяце, когда Penguin работает весь период, та же конфигурация выставляет полные $118. Любой, кто отражает цену из прайса в обоих месяцах, завышает первый месяц и ничего не занижает во втором, — это и есть тот самый дрейф, который наказывает поминутная тарификация.
Более крупная компания запускает трёхузловой production-кластер плюс staging и предоплаченный кредитный баланс. Кластер умножает ставку одноузлового тарифа, изменения тарифа во время реагирования на инциденты добавляют пропорциональные сегменты, а предоплата поглощает итог без списания с карты. Счёт всё равно детализирует каждый инстанс и каждый сегмент, и именно списание кредита — это та сумма, которую нужно отразить, а не ноль в выписке по карте.
Ни одна из этих конфигураций не включает подсчёт сообщений. Если ваша финансовая модель умножает ожидаемые сообщения на ставку за сообщение, она моделирует другого поставщика. Моделируйте уровни инстансов, умноженные на ожидаемые секунды, и пересматривайте допущение об уровне всякий раз, когда рост соединений или очередей вынуждает к изменению размера.
Почему production-брокер — это себестоимость, а не накладные расходы
Брокер сообщений, который в production передаёт события заказов, отправку задач и уведомления клиентов, — это прямая стоимость предоставления вашего продукта. Он масштабируется вместе с бизнесом, он перестаёт иметь значение в тот момент, когда ничего не продаётся, и он естественно находится над строкой валовой маржи вместе с вычислениями, базой данных, хранением и пропускной способностью для production. Практика валовой маржи SaaS применяет тест на прямые затраты: расходы, которые существуют для обслуживания клиентов в production, — это себестоимость выручки, тогда как расходы, которые создают, продают или администрируют компанию, — это операционные расходы. Классический SaaS показывает валовую маржу 75–85 процентов на этой основе, причём инфраструктурно тяжёлые бизнесы показывают меньше, и инвесторы сравнивают вас с этими диапазонами.
Применяйте тест инстанс за инстансом, потому что один аккаунт CloudAMQP обычно содержит несколько. Production-брокеры, несущие клиентские рабочие нагрузки, попадают в себестоимость продаж. Staging, нагрузочные тесты и инстансы песочницы разработчиков попадают в исследования и разработку или общие накладные расходы. Общий Ermine, на котором работает ваша среда staging, не становится себестоимостью просто потому, что делит счёт с production Penguin. Счёт объединяет их воедино, поэтому разделяйте его каждый месяц по инстансам, используя разбивку по инстансам в панели управления. Команды, которые пропускают это разделение, обычно ошибаются в лестную сторону, пряча инфраструктуру в накладные расходы и показывая маржу, которую не может защитить их юнит-экономика. Проверка при дью-дилидженсе переклассифицирует это за один день, и пересчитанная маржа никогда не бывает более высокой.
Стандарты бухгалтерского учёта это подтверждают. Согласно ASC 350-40, договор управляемого хостинга, где поставщик управляет программным обеспечением, — это договор на оказание услуг, и сборы относятся к расходам по мере их возникновения в течение периода использования. Работы по внедрению могут иметь собственный порядок учёта, но ежемесячная плата за время работы инстанса — это расход периода, никогда не капитализируемый актив. Предоплаты — это обратная картина: деньги уходят сегодня, расход признаётся позже, поэтому предоплата отражается как предоплаченный актив и высвобождается в расход по мере использования кредита. Отражение предоплаты как расхода в день оплаты завышает месяц оплаты и занижает каждый месяц, который покрывает кредит.
Отражайте чистую сумму, которую вы фактически платите. Бесплатный уровень Lemming — это бесплатная ёмкость, а не выручка, поэтому начислять её до полной суммы нечего. Если вы хотите видеть, сколько бы стоила рабочая нагрузка без него, отслеживайте это в своих метриках и держите книгу на фактической стоимости.
Как отразить это так, чтобы счёт сверялся
Дайте брокеру собственный счёт себестоимости продаж, а не смешивайте его с общими облачными или программными расходами. Специальный счёт, например брокер сообщений, позволяет разделить месячные production-расходы на месячные инстансо-секунды и увидеть вашу истинную стоимость за единицу ёмкости — это число говорит вам, купило ли изменение размера запас производительности или просто больший счёт.
Поскольку тарификация идёт с оплатой в конце месяца, ритм такой: начислить, затем погасить, затем скорректировать. Оцените долю брокера исходя из уровней инстансов и секунд на закрытии, разделите production и staging и скорректируйте до счёта, когда он придёт. Вот полный цикл для месяца, когда production стоил $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 на Penguin плюс staging на Ermine"
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 предоставляет операции со счетами наряду с управлением инстансами, так что выборка на конец месяца не обязана быть человеком, щёлкающим по консоли. Заскриптуйте загрузку, разберите строки по инстансам и сравните с вашим журналом изменений и вашим начислением. Саму оценку начисления можно получить из тех же данных: ставки уровней, умноженные на прошедшие секунды, что лучше угадывания по итогу прошлого месяца всякий раз, когда изменение размера произошло в середине цикла.
Чек-лист на конец месяца по затратам на брокера
Замкните цикл одинаково каждый месяц, чтобы числа оставались достоверными:
- Перечислите каждый инстанс и кластер, с прямым счётом и через маркетплейс, и подтвердите, что у каждого всё ещё есть владелец и назначение.
- Сверьте каждую строку счёта с инстансом, уровнем и временным сегментом, используя ваш журнал изменений размера для любых смешанных итогов.
- Разделите расходы production, staging и песочницы и подтвердите, что только production попал в себестоимость продаж.
- Скорректируйте начисление прошлого месяца до погашенного счёта и перенесите отклонение в оценку следующего месяца.
- Спишите любую предоплату на фактическое потребление и сверьте оставшийся баланс с его годовым истечением.
- Подтвердите, что использование передачи данных осталось в пределах лимита добросовестного использования, и урегулируйте любое уведомление о превышении в пределах его 30-дневного окна.
- Подтвердите, что каждый инстанс, созданный в течение месяца, унаследовал правильный тег среды и попал в правильный счёт с первого дня.
Заберите счёт CloudAMQP за этот месяц сегодня и сопоставьте каждую строку с инстансом, который вы можете назвать. Если каждая строка сопоставляется чисто, учёт вашего брокера честен. Если какая-то нет, вы только что нашли либо забытый инстанс, всё ещё тарифицируемый по секундам, либо двойника из маркетплейса, скрывающегося в другом счёте, и любая находка окупает обзор.
