你的 CloudAMQP 计划标价每月 $99，但账单显示 $82.33，下个月又变成 $114.07，而你除了在某个周二调整了一下实例规格之外什么都没改。并没有哪里出错。CloudAMQP 不卖消息，它按秒出售实例时间，延后一个月开票，并把每一次计划变更按秒精确分摊。标价是限速，不是承诺。除非你的账簿把这张账单当作抄表读数而不是订阅费，否则你的基础设施成本会漂移，计提会漏掉，毛利率会悄悄吸收掉差额。
本文解释 CloudAMQP 实际如何计量和计费、真实的账单长什么样、为什么生产 broker 应归入销货成本，以及如何核对实例时间账单，让每一美元都落到正确的科目里。
CloudAMQP 如何计量：时间，而非消息
CloudAMQP 是 84codes 运营的托管 RabbitMQ 和 LavinMQ 服务。你选择一个 broker、一个计划和区域，就会得到一个实例或一个集群。计费模型跟随实例，而非流经实例的流量，这与按请求计费的消息服务正好相反——后者由负载大小驱动账单。在这里，决定你账单的两个问题是：你运行的实例有多大，以及运行了多少秒。
共享计划有配额，专用计划有容量
共享多租户计划是唯一会出现消息数的地方。Loyal Lemming 免费，带 200 万条消息的月度配额和 40 个连接；Elegant Ermine 每月 $19，带 2000 万条消息配额和 200 个连接。这些适合开发、原型和业余项目。配额是上限，不是计量表：在配额之内你并不按消息付费。
专用计划完全不再计算消息数。你获得自己的 broker 或一个多可用区集群，每个专用计划都以相同的速度运行相同的引擎。你按系统承载量选择档位：连接数、队列数和存储的消息数。单节点 LavinMQ 阶梯从每月 $49 的 Passionate Puffin 开始，经过 $99 的 Playful Penguin、$199 的 Lively Lynx 和 $499 的 Wild Wolverine，再往上是更大的档位。一节点、三节点和五节点的集群形态用价格换取可用性。数据传输在公平使用额度内包含在内，定价页将其定义为每月等于团队消费 30% 的免费传输量。如果超出，你有 30 天时间解决超额，之后流量费用才会出现在后续账单上。
实际后果是：只要实例仍能承载连接、队列和积压，你的消息量可以翻倍而账单一分钱不动。反过来，如果因为某个限制卡住了而升级到更大的档位，从那一刻起每一秒都按新价格重新定价，即使流量不变。控制这张账单的技能是容量规划，而不是流量预测。
每一秒都算数，账单晚一个月到
所有计划都按秒计费。每月末，你的账单反映每个实例可用的确切时间，因此月中创建、月中删除或月中调整规格的实例会产生按比例分摊的费用，而不是整月或零费用。你可以随时切换计划而不停机，档位之间的自动扩缩容效果相同：每个时间段按当时生效的档位定价。
付款在服务交付后的下个月进行。CloudAMQP 自己的 FAQ 说得很清楚：计费按比例分摊，客户只为服务可用的时间付费，你在下个月初收到第一张账单，而不是在注册时。这种延后结算的节奏对你的账簿来说是最重要的事实。期末没有任何待入账的费用，这意味着每次月末结账都需要对未开票的 broker 时间做计提，而每张账单都需要对上个月的估算做调整。
还有两个计费机制很重要。第一，预付款：你可以预付一个月到几个月，预付款有效期为一年，到期作废。一个 $99 计划的客户可以预付十二个月，一年内跳过月度扣费，而该额度覆盖账户上的所有计划，所以增加第二个实例会更快消耗它。这是一项带一年期限的预付资产，而不是付款时的费用。第二，没有年度账单。因为客户更换计划太频繁，CloudAMQP 不提供年度计费；预付款额度是替代方案。如果你的采购流程要求年度账单或每个订阅单独的采购订单，请尽早规划：单独的 PO 需要单独的账户，以便订阅分开计费，而开票条款要通过他们的计费团队处理，而不是自助刷卡流程。
Marketplace 实例通过平台计费，而非 CloudAMQP
如果你通过 Heroku 附加组件或 AWS、Azure、GCP marketplace 开通，这笔支出根本不会出现在 CloudAMQP 账单上。它落在平台账单上——Heroku 的月度账单或你的云提供商的成本明细——以该平台自己的命名出现。这是同时在两处运行 broker 的团队最常见的核对缺口：直接账单核对得干干净净，而 marketplace 上的孪生实例藏在一张更大的云账单里，通常被归类为通用托管。一次性决定每个实例从哪里计费，并确保你的月末拉取同时覆盖 CloudAMQP 控制面板和它可能藏身的每个 marketplace。
真实规模下的成本
标价只有乘以秒数才有意义，所以这里用已公布的单节点价格构建三种规模。
一个业余项目在免费的 Lemming 档上跑 staging，用 $49 的 Puffin 跑一个小型生产服务。broker 这一项是每月 $49，固定不变，唯一的核对任务是确认实例整月都在运行。
一个成长中的 SaaS 团队用 $99 的 Penguin 跑生产，用 $19 的 Ermine 跑 staging。月中，队列深度迫使升级：Puffin 级别的 staging 保持不动，但生产在 30 天月份的第 10 天从 $49 的 Puffin 升到 $99 的 Penguin。生产部分按较低档位计 10 天加较高档位计 20 天，大约 $16.33 加 $66.00，即约 $82.33，staging 再加 $19。账单总额约为 $101.33，而这套配置的标价合计是 $118。下个月，Penguin 全程运行，同样的配置按完整的 $118 出账。把标价记入两个月的人，第一个月会高估，第二个月则没有低估——这正是按秒计费会惩罚的漂移。
一家更大的公司运行三节点生产集群，加上 staging 和预付余额。集群将单节点价格乘以倍数，事件响应期间的计费变更增加按比例的分段，预付款吸收总额而不产生刷卡扣费。账单仍然逐项列出每个实例和每个分段，而真正要入账的是额度消耗额，而不是卡账单上的零。
这些规模都不涉及消息数。如果你的财务模型把预期消息数乘以每条消息的费率，那你建模的是另一家厂商。要按实例档位乘以预期秒数来建模，并在连接数或队列增长迫使调整规格时重新审视档位假设。
为什么生产 broker 是 COGS，而非间接费用
一个在生产中承载订单事件、任务分发和客户通知的消息 broker，是交付你产品的直接成本。它随业务增长，一旦没有销售就不再重要，并且自然地和其他生产用计算、数据库、存储和带宽一起位于毛利线之上。SaaS 毛利率实践采用直接成本测试：为服务生产中的客户而存在的支出是营收成本，而构建、销售或管理公司的支出是运营费用。经典 SaaS 按此基础运行 75% 到 85% 的毛利率，基础设施密集型业务则更低，投资者会用这些区间来衡量你。
要逐个实例应用这个测试，因为一个 CloudAMQP 账户通常有多个实例。承载客户工作负载的生产 broker 归入销货成本。staging、负载测试和开发者沙盒实例归入研发或一般间接费用。运行你 staging 环境的共享 Ermine 不会仅仅因为和生产 Penguin 共用一张账单就成为 COGS。账单把它们混在一起，所以要每月按实例拆分，使用控制面板的逐实例明细。跳过拆分的团队通常错在好看的方向：把基础设施埋进间接费用，报告出一个单位经济模型撑不住的毛利率。尽职调查审查一个下午就能重新分类，而重述后的毛利率永远不是更高的那个。
会计准则支持这一点。根据 ASC 350-40，由供应商运行软件的管理式托管安排是服务合同，费用在使用期内按 incurred 计入费用。实施工作可能有自己的处理方式，但每月的实例时间费用是期间费用，永远不是可资本化的资产。预付款是镜像的另一面：今天现金流出，以后才计费用，所以预付款作为预付资产存在，并在额度被消耗时释放为费用。把预付款当作付款当天的费用，会高估付款月，低估额度覆盖的每个月。
按你实际支付的净额入账。免费的 Lemming 档是免费容量，不是营收，所以没有需要毛额化的东西。如果你想看到没有它时工作负载的成本，把它记录在你的指标里，让账簿保持现金成本。
如何入账才能让账单核对得上
给 broker 一个自己的销售成本科目，而不是混进通用的云或软件支出。一个专门的科目，比如 message broker，让你可以将当月生产支出除以当月实例秒数，看到每单位容量的真实成本，这个数字才能告诉你：调整规格是买到了余量，还是只是账单变大了。
因为计费延后一个月，节奏是计提、结算、调整。在月末根据实例档位和秒数估算 broker 部分，拆分生产和 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" "一月估算，生产 Puffin 升 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" "一月消耗对预付款，生产加 staging"
Expenses:CostOfSales:Message-Broker 82.33 USD
Expenses:Research:Staging-Infra 19.00 USD
Assets:Prepaid:CloudAMQP -101.33 USD像跟踪任何不用即失的额度一样跟踪预付款的一年到期。到期的余额是真实损失，它值得一个日历提醒，而不是明年清理时的意外发现。如果你用纯文本记账，文档中的成本跟踪模式可以自然地扩展为逐实例的 broker 拆分。
一个分类陷阱：数据传输超额附加费和更大的档位都是 broker 成本，但含义不同。档位变更是计划内的容量；超额是超出公平使用额度的计划外消耗。两者都记入 broker 科目，但要单独标记或备注超额，这样它出现的那个月读起来是例外而不是新的基线。
五个保持实例时间诚实的控制措施
按秒计费奖励关注，惩罚设置后不管。这五个控制措施能抓住常见的漂移。
1. 逐实例核对，而非逐账单核对
把每条账单行匹配到你认识的实例、你授权的档位，以及大致覆盖整月的秒数。一个没有人拥有的实例行，通常是被遗忘的 staging broker，或三个冲刺前的负载测试集群仍在按秒计费。果断删除；闲置容量在这里没有奖励。
2. 记录每次调整规格及其时间戳
每次计划变更都会把月份分成多个定价分段。保持一个轻量的变更日志，哪怕是一份共享笔记，记录日期、实例、旧档位和新档位，并把账单的分段与它核对。没有日志，像 $82.33 这样的混合总额是无法验证的算术。有了它，一分钟就能核对。
3. 把 marketplace 支出纳入同一次审查
如果有任何实例通过 Heroku 或云 marketplace 计费，把这些行与直接账单一起加入每月的审查。在账簿摘要中写明 marketplace 名称，这样下个月的审查者就不会去找一条永远不会存在的 CloudAMQP 行。这也是重复计费藏身之处：一个从 marketplace 迁移到直接计费的实例，有时会在几天内双重运行。
4. 在公平使用传输额度计费之前关注它
数据传输在团队消费的 30% 以内免费包含，超额后有 30 天的解决窗口，之后附加费才会出现在后续账单上。把第一次超额通知当作控制点，而不是附加费。检查哪个实例的流量激增，确认是合理的增长而不是重试风暴或话多的消费者，并在窗口内解决。一个在集群中扩散的重试循环，可以在不改变任何档位的情况下把平静的月份变成传输超额。
5. 自动化拉取
控制面板列出每张账单，客户 API 在实例管理之外还暴露账单操作，所以月末拉取不必是人工点控制台。编写脚本下载、解析逐实例行，并与你的变更日志和计提进行比对。计提估算本身可以来自同一数据：档位费率乘以已过秒数，这比在周期中途发生调整规格时从上月总额猜测要好得多。
broker 成本的月末清单
每月以同样的方式闭环，让数字保持可信：
- 列出每个实例和集群，包括直接和 marketplace 计费的，确认每个仍有所有者和用途。
- 将每条账单行核对到实例、档位和时间分段，对任何混合总额使用你的调整规格日志。
- 拆分生产与 staging 及沙盒支出，确认只有生产进入了销货成本。
- 将上个月的计提调整到已结算的账单，并把差异结转到下个月的估算中。
- 按实际消耗扣减任何预付款，并对照一年到期检查剩余余额。
- 确认传输使用保持在公平使用额度内，并在 30 天窗口内解决任何超额通知。
- 确认当月创建的每个实例都继承了正确的环境标签，并从第一天起落入正确的科目。
今天就拉取你本月的 CloudAMQP 账单，把每一行匹配到一个你能叫出名字的实例。如果每一行都能干净对应，你的 broker 会计就是诚实的。如果有一行对不上，你刚刚发现的要么是一个仍在按秒计费的被遗忘实例，要么是藏在另一张账单里的 marketplace 孪生实例，而任何一项发现都值得这次审查。
