Zum Hauptinhalt springen

Sekundengenaue Abrechnung, nicht pro Nachricht: CloudAMQPs Instanzzeit-Rechnungen als Infrastruktur-COGS abgleichen

Veröffentlicht 13 Minuten LesezeitMike ThriftMike Thrift
Sekundengenaue Abrechnung, nicht pro Nachricht: CloudAMQPs Instanzzeit-Rechnungen als Infrastruktur-COGS abgleichen
Auf dieser Seite

Dein CloudAMQP-Plan sagt 99 $ pro Monat, aber die Rechnung sagt 82,33 $, und nächsten Monat sagt sie 114,07 $, und du hast nichts geändert außer einer Instanzgrößenanpassung an einem Dienstag. Nichts ist falsch. CloudAMQP verkauft keine Nachrichten. Es verkauft Instanzzeit sekundengenau, rechnet einen Monat nachträglich ab und pro-rataisiert jede Planänderung auf die exakte Sekunde ihres Eintretens. Der Listenpreis ist ein Tempolimit, kein Versprechen. Solange deine Bücher die Rechnung als Zählerstand statt als Abonnement behandeln, werden deine Infrastrukturkosten driften, deine Abgrenzungen fehlschlagen, und deine Bruttomarge wird die Differenz stillschweigend absorbieren.

Dieser Beitrag erklärt, wie CloudAMQP tatsächlich misst und abrechnet, wie realistische Rechnungen aussehen, warum der Produktions-Broker zu den Herstellungskosten (Cost of Goods Sold) gehört und wie du Instanzzeit-Rechnungen abgleichst, damit jeder Dollar im richtigen Konto landet.

Wie CloudAMQP misst: Zeit, nicht Nachrichten​

CloudAMQP ist verwaltetes RabbitMQ- und LavinMQ-Hosting von 84codes. Du wählst einen Broker, einen Plan und eine Region, und du bekommst eine Instanz oder einen Cluster. Das Abrechnungsmodell folgt der Instanz, nicht dem durch sie fließenden Verkehr, was das Gegenteil von nachrichtenorientierten Messaging-Diensten ist, bei denen die Payload-Größe die Rechnung treibt. Hier sind die beiden Fragen, die deine Rechnung bestimmen, wie groß eine Instanz war, die du betrieben hast, und für wie viele Sekunden.

Shared-Pläne haben Quoten, Dedicated-Pläne haben Kapazität​

Die geteilten Multi-Tenant-Pläne sind der einzige Ort, an dem Nachrichtenzahlen überhaupt auftauchen. Loyal Lemming ist kostenlos mit einer monatlichen Quote von 2 Millionen Nachrichten und 40 Verbindungen, und Elegant Ermine kostet 19 $ pro Monat mit einer Quote von 20 Millionen Nachrichten und 200 Verbindungen. Diese eignen sich für Entwicklung, Prototypen und Hobbyprojekte. Die Quote ist eine Obergrenze, kein Zähler: Du zahlst nicht pro Nachricht innerhalb dieser Quote.

Dedicated-Pläne verzichten vollständig auf das Zählen von Nachrichten. Du bekommst deinen eigenen Broker oder einen Multi-AZ-Cluster davon, und jeder Dedicated-Plan läuft mit derselben Engine und derselben Geschwindigkeit. Du wählst eine Stufe danach, wie viel dein System hält: Verbindungen, Queues und gespeicherte Nachrichten. Die Single-Node-LavinMQ-Leiter reicht von Passionate Puffin für 49 $ pro Monat über Playful Penguin für 99 $, Lively Lynx für 199 $ und Wild Wolverine für 499 $, mit größeren Stufen darüber. Cluster-Formen mit einem, drei und fünf Knoten tauschen Preis gegen Verfügbarkeit. Der Datentransfer ist innerhalb einer Fair-Use-Grenze enthalten, die die Preisseite als kostenlosen Transfer in Höhe von 30 Prozent deiner Team-Ausgaben pro Monat definiert. Wenn du sie überschreitest, hast du 30 Tage Zeit, die Überschreitung zu beheben, bevor Verkehrsgebühren auf späteren Rechnungen erscheinen.

Die praktische Konsequenz: Dein Nachrichtenvolumen kann sich verdoppeln, ohne die Rechnung um einen Cent zu bewegen, solange die Instanz noch die Verbindungen, Queues und den Rückstau hält. Umgekehrt bepreist ein Upgrade auf eine größere Stufe, weil eine Grenze dich eingeengt hat, jede Sekunde ab diesem Moment neu, selbst wenn der Verkehr flach ist. Kapazitätsplanung, nicht Verkehrsprognose, ist die Fähigkeit, die diese Rechnung kontrolliert.

Jede Sekunde zählt, und die Rechnung kommt einen Monat später​

Alle Pläne werden sekundengenau abgerechnet. Am Ende jedes Monats spiegelt deine Rechnung die exakte Zeit wider, in der jede Instanz zur Nutzung verfügbar war, sodass eine mitten im Monat erstellte, gelöschte oder in der Größe angepasste Instanz eine pro-rataisierte Belastung erzeugt statt eines vollen oder null Monats. Du kannst Pläne jederzeit ohne Ausfallzeit wechseln, und Autoscaling zwischen Stufen hat denselben Effekt: Jedes Segment des Monats wird zu der Stufe bepreist, die während dieser Sekunden aktiv war.

Die Zahlung erfolgt im Monat nach der Erbringung. CloudAMQPs eigene FAQ drückt es klar aus: Die Abrechnung ist pro-rataisiert, Kunden zahlen nur für die Zeit, in der der Dienst für sie verfügbar war, und du erhältst deine erste Rechnung zu Beginn des kommenden Monats statt bei der Anmeldung. Dieser Nachträglichkeitsrhythmus ist die wichtigste Tatsache für deine Bücher. Zum Abschluss gibt es keine Belastung, gegen die du buchen kannst, was bedeutet, dass jeder Monatsabschluss eine Abgrenzung für nicht abgerechnete Broker-Zeit benötigt und jede Rechnung einen Abgleich gegen die Schätzung des Vormonats.

Zwei weitere Abrechnungsmechaniken sind wichtig. Erstens die Vorauszahlung: Du kannst einen bis mehrere Monate im Voraus bezahlen, und eine Vorauszahlung ist ein Jahr lang gültig, bevor sie verfällt. Ein Kunde mit einem 99-$-Plan kann zwölf Monate im Voraus zahlen und ein Jahr lang monatliche Belastungen überspringen, und das Guthaben deckt jeden Plan im Konto ab, sodass das Hinzufügen einer zweiten Instanz es schneller aufbraucht. Das ist ein vorausbezahlter Vermögenswert mit einer einjährigen Zündschnur, kein Aufwand zum Zahlungszeitpunkt. Zweitens gibt es keine Jahresrechnung. Weil Kunden so oft Pläne wechseln, bietet CloudAMQP keine jährliche Abrechnung an; Vorauszahlungsguthaben ist der Ersatz. Wenn dein Beschaffungsprozess eine Jahresrechnung oder separate Bestellungen pro Abonnement verlangt, plane frühzeitig darum herum: Separate Bestellungen erfordern separate Konten, damit die Abonnements separat abgerechnet werden, und Rechnungsbedingungen laufen über deren Abrechnungsteam statt über den Self-Service-Kartenprozess.

Marketplace-Instanzen werden über die Plattform abgerechnet, nicht über CloudAMQP​

Wenn du über Heroku-Add-ons oder die AWS-, Azure- oder GCP-Marketplaces bereitgestellt hast, erscheint die Ausgabe überhaupt nicht auf einer CloudAMQP-Rechnung. Sie landet auf der Plattformrechnung, Herokus Monatsrechnung oder der Kostenaufschlüsselung deines Cloud-Anbieters, unter der Benennung dieser Plattform. Dies ist die häufigste Abgleichslücke für Teams, die Broker an zwei Orten betreiben: Die direkte Rechnung gleicht sich sauber ab, während der Marketplace-Zwilling sich in einer größeren Cloud-Rechnung versteckt, oft als generisches Hosting klassifiziert. Entscheide einmal, woher jede Instanz abgerechnet wird, und stelle sicher, dass dein Monatsabruf sowohl das CloudAMQP-Kontrollpanel als auch jeden Marketplace abdeckt, in dem er sich verstecken könnte.

Was das bei realistischen Formen kostet​

Listenpreise ergeben nur Sinn multipliziert mit Sekunden, also hier drei Formen, gebaut aus veröffentlichten Single-Node-Preisen.

Ein Nebenprojekt betreibt Staging auf der kostenlosen Lemming-Stufe und einen Puffin für 49 $ für einen kleinen Produktionsdienst. Die Broker-Zeile beträgt 49 $ pro Monat, flach, und die einzige Abgleichsaufgabe ist die Bestätigung, dass die Instanz den ganzen Monat lief.

Ein wachsendes SaaS-Team betreibt Produktion auf einem Penguin für 99 $ und Staging auf einem Ermine für 19 $. Mitten im Monat erzwingt die Queue-Tiefe ein Upgrade: Staging auf Puffin-Niveau bleibt, aber die Produktion wechselt zehn Tage in einem dreißigtägigen Monat von Puffin für 49 $ zu Penguin für 99 $. Der Produktionszweig bepreist sich als zehn Tage zur niedrigeren Stufe plus zwanzig Tage zur höheren, etwa 16,33 $ plus 66,00 $, also etwa 82,33 $, und Staging fügt 19 $ hinzu. Die Rechnungssumme landet bei etwa 101,33 $ für ein Setup, dessen Listenpreise sich auf 118 $ summieren. Nächsten Monat, mit Penguin für den vollen Zeitraum aktiv, rechnet dasselbe Setup die vollen 118 $ ab. Wer den Listenpreis in beiden Monaten bucht, überzeichnet den ersten Monat und unterzeichnet den zweiten nicht, was genau die Drift ist, die sekundengenaue Abrechnung bestraft.

Ein größerer Betrieb betreibt einen dreiknotigen Produktionscluster plus Staging und ein vorausbezahltes Guthaben. Der Cluster multipliziert den Single-Node-Tarif, Planänderungen während der Incident-Bearbeitung fügen pro-rataisierte Segmente hinzu, und die Vorauszahlung absorbiert die Summe ohne Kartenbelastung. Die Rechnung listet dennoch jede Instanz und jedes Segment auf, und der Guthabenabzug ist die zu buchende Zahl, nicht die Null auf dem Kontoauszug.

Keine dieser Formen beinhaltet Nachrichtenzahlen. Wenn dein Finanzmodell erwartete Nachrichten mit einem Pro-Nachricht-Tarif multipliziert, modelliert es einen anderen Anbieter. Modelliere Instanzstufen multipliziert mit erwarteten Sekunden, und überdenke die Stufenannahme, wann immer Verbindungs- oder Queue-Wachstum eine Größenanpassung erzwingt.

Warum der Produktions-Broker COGS ist, nicht Gemeinkosten​

Ein Message-Broker, der Produktions-Bestellereignisse, Job-Dispatches und Kundenbenachrichtigungen trägt, ist ein direkter Kostenfaktor für die Bereitstellung deines Produkts. Er skaliert mit dem Geschäft, er ist irrelevant, sobald nichts verkauft wird, und er gehört natürlich über die Bruttomargenlinie neben Compute, Datenbank, Speicher und Bandbreite für die Produktion. Die SaaS-Bruttomargen-Praxis wendet einen Direktkostentest an: Ausgaben, die existieren, um Kunden in der Produktion zu bedienen, sind Umsatzkosten, während Ausgaben, die das Unternehmen aufbauen, verkaufen oder verwalten, Betriebsausgaben sind. Klassisches SaaS erzielt auf dieser Basis 75 bis 85 Prozent Bruttomarge, wobei infrastrukturlastige Unternehmen niedriger liegen, und Investoren messen dich an diesen Bandbreiten.

Wende den Test Instanz für Instanz an, denn ein CloudAMQP-Konto enthält normalerweise mehrere. Produktions-Broker, die Kunden-Workloads tragen, gehen in die Herstellungskosten über. Staging-, Lasttest- und Entwickler-Sandbox-Instanzen fallen in Forschung und Entwicklung oder allgemeine Gemeinkosten. Der geteilte Ermine, der deine Staging-Umgebung betreibt, ist nicht COGS, nur weil er sich eine Rechnung mit dem Produktions-Penguin teilt. Die Rechnung fasst sie zusammen, also teile sie jeden Monat pro Instanz auf, unter Verwendung der Aufschlüsselung pro Instanz im Kontrollpanel. Teams, die die Aufteilung überspringen, irren sich meist in die schmeichelhafte Richtung, vergraben Infrastruktur in Gemeinkosten und melden eine Marge, die ihre Stückökonomie nicht verteidigen kann. Eine Diligence-Prüfung reklassifiziert sie an einem Nachmittag, und die neu dargestellte Marge ist nie die höhere.

Die Rechnungslegungsstandards stützen dies. Nach ASC 350-40 ist eine verwaltete Hosting-Vereinbarung, bei der der Anbieter die Software betreibt, ein Dienstleistungsvertrag, und die Gebühren werden über den Nutzungszeitraum als angefallen aufwandswirksam. Implementierungsarbeit kann eine eigene Behandlung haben, aber die monatliche Instanzzeit-Gebühr ist ein Periodenaufwand, nie ein aktivierter Vermögenswert. Vorauszahlungen sind das Spiegelbild: Cash heute raus, Aufwand später, sodass die Vorauszahlung als vorausbezahlter Vermögenswert steht und in den Aufwand freigesetzt wird, während das Guthaben verbraucht wird. Die Buchung der Vorauszahlung als Aufwand am Zahlungstag überzeichnet den Zahlungsmonat und unterzeichnet jeden Monat, den das Guthaben abdeckt.

Buche den Nettobetrag, den du tatsächlich zahlst. Die kostenlose Lemming-Stufe ist freie Kapazität, kein Umsatz, also gibt es nichts aufzuwerten. Wenn du Sichtbarkeit darüber willst, was der Workload ohne sie kosten würde, verfolge das in deinen Metriken und halte das Hauptbuch zu Cash-Kosten.

Wie man es bucht, damit die Rechnung abgeglichen wird​

Gib dem Broker ein eigenes Umsatzkostenkonto, statt es in generische Cloud- oder Software-Ausgaben zu mischen. Ein dediziertes Konto wie Message-Broker ermöglicht es dir, die Produktionsausgaben des Monats durch die Instanzsekunden des Monats zu teilen und deine wahren Kosten pro Kapazitätseinheit zu sehen, was die Zahl ist, die dir sagt, ob eine Größenanpassung Spielraum gekauft hat oder nur eine größere Rechnung.

Weil die Abrechnung einen Monat nachträglich läuft, ist der Rhythmus abgrenzen, dann begleichen, dann abgleichen. Schätze den Broker-Anteil aus Instanzstufen und Sekunden zum Abschluss, trenne Produktion von Staging und korrigiere auf die Rechnung, wenn sie eintrifft. Hier ist ein vollständiger Zyklus für einen Monat, in dem die Produktion nach einer Größenanpassung mitten im Monat 82,33 $ betrug und Staging 19,00 $ hinzufügte:

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" "January estimate, prod Puffin-to-Penguin resize plus 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" "January invoice settles, estimate was exact"
  Liabilities:Accrued:CloudAMQP  101.33 USD
  Assets:Cash:Operating  -101.33 USD

Wenn eine Vorauszahlung den Monat abdeckt, zieht der Begleichungszweig den vorausbezahlten Vermögenswert statt Cash. Erfasse die Vorauszahlung als Vermögenswert, wenn du sie zahlst, und setze dann den Verbrauch jedes Monats frei:

2026-01-05 * "CloudAMQP" "Prepay 12 months Big Bunny at 99 per month"
  Assets:Prepaid:CloudAMQP  1188.00 USD
  Assets:Cash:Operating  -1188.00 USD
 
2026-01-31 * "CloudAMQP" "January consumption against prepayment, prod plus staging"
  Expenses:CostOfSales:Message-Broker  82.33 USD
  Expenses:Research:Staging-Infra  19.00 USD
  Assets:Prepaid:CloudAMQP  -101.33 USD

Verfolge den einjährigen Verfall der Vorauszahlung so, wie du jedes Use-it-or-lose-it-Guthaben verfolgst. Ein verfallendes Guthaben ist ein echter Verlust, und es verdient eine Kalendererinnerung, keine Entdeckung während der Aufräumarbeiten des nächsten Jahres. Wenn du deine Bücher in Plain Text führst, erweitern sich die Kostenverfolgungsmuster in der Dokumentation natürlich auf eine Broker-Aufteilung pro Instanz.

Eine Klassifizierungsfalle: Ein Datentransfer-Überschreitungszuschlag und eine größere Stufe sind beide Broker-Kosten, aber sie bedeuten unterschiedliche Dinge. Die Stufenänderung ist geplante Kapazität; die Überschreitung ist ungeplanter Verbrauch über die Fair-Use-Grenze hinaus. Buche beides auf das Broker-Konto, aber tagge oder vermerke die Überschreitung separat, damit der Monat, in dem sie erscheint, als Ausnahme und nicht als neue Grundlinie gelesen wird.

Fünf Kontrollen, die Instanzzeit ehrlich halten​

Sekundengenaue Abrechnung belohnt Aufmerksamkeit und bestraft Set-and-Forget. Diese fünf Kontrollen fangen die häufigen Drifts ab.

1. Instanz für Instanz abgleichen, nicht Rechnung für Rechnung​

Ordne jede Rechnungsposition einer Instanz zu, die du erkennst, zu einer Stufe, die du autorisiert hast, für Sekunden, die den Monat ungefähr abdecken. Eine Position für eine Instanz, die niemand besitzt, ist normalerweise ein vergessener Staging-Broker oder ein Lasttest-Cluster von vor drei Sprints, der immer noch sekundengenau abrechnet. Lösche gnadenlos; es gibt hier keine Belohnung für untätige Kapazität.

2. Jede Größenanpassung mit ihrem Zeitstempel protokollieren​

Jede Planänderung teilt den Monat in bepreiste Segmente. Führe ein leichtgewichtiges Änderungsprotokoll, sogar eine geteilte Notiz mit Datum, Instanz, alter Stufe und neuer Stufe, und gleiche die Segmente der Rechnung dagegen ab. Ohne das Protokoll ist eine gemischte Summe wie 82,33 $ unüberprüfbare Arithmetik. Mit ihm prüft sich die Mathematik in einer Minute.

3. Marketplace-Ausgaben in dieselbe Prüfung einbeziehen​

Wenn eine Instanz über Heroku oder einen Cloud-Marketplace abgerechnet wird, füge diese Positionen derselben monatlichen Prüfung wie die direkte Rechnung hinzu. Nenne den Marketplace in der Hauptbuch-Narration, damit der Prüfer des nächsten Monats nicht nach einer CloudAMQP-Position sucht, die nie existieren wird. Hier versteckt sich auch die doppelte Abrechnung: Eine von Marketplace auf direkte Abrechnung migrierte Instanz läuft manchmal einige Tage doppelt.

4. Die Fair-Use-Transfergrenze beobachten, bevor sie abgerechnet wird​

Der Datentransfer ist bis zu 30 Prozent der Team-Ausgaben enthalten, mit einem 30-tägigen Lösungsfenster nach einer Überschreitung, bevor Zuschläge auf späteren Rechnungen erscheinen. Behandle die erste Überschreitungsmitteilung als die Kontrolle, nicht den Zuschlag. Prüfe, welcher Verkehr einer Instanz gestiegen ist, bestätige, dass es legitimes Wachstum und kein Retry-Sturm oder ein geschwätziger Consumer ist, und löse es innerhalb des Fensters. Eine Retry-Schleife, die sich über einen Cluster ausbreitet, kann einen ruhigen Monat in eine Transferüberschreitung verwandeln, ohne eine Stufe zu ändern.

5. Den Abruf automatisieren​

Das Kontrollpanel listet jede Rechnung auf, und die Kunden-API stellt Rechnungsvorgänge neben der Instanzverwaltung bereit, sodass der Monatsabruf kein Mensch sein muss, der durch eine Konsole klickt. Skripte den Download, parse die Positionen pro Instanz und vergleiche sie mit deinem Änderungsprotokoll und deiner Abgrenzung. Die Abgrenzungsschätzung selbst kann aus denselben Daten kommen: Stufentarife multipliziert mit verstrichenen Sekunden, was das Raten aus der Summe des Vormonats übertrifft, wann immer eine Größenanpassung mitten im Zyklus stattfand.

Monatsabschluss-Checkliste für Broker-Kosten​

Schließe den Kreis jeden Monat auf dieselbe Weise, damit die Zahlen vertrauenswürdig bleiben:

  1. Liste jede Instanz und jeden Cluster auf, direkt und marketplace-abgerechnet, und bestätige, dass jede noch einen Besitzer und einen Zweck hat.
  2. Gleiche jede Rechnungsposition einer Instanz, Stufe und einem Zeitsegment zu, unter Verwendung deines Größenanpassungsprotokolls für alle gemischten Summen.
  3. Trenne Produktions- von Staging- und Sandbox-Ausgaben und bestätige, dass nur die Produktion in den Herstellungskosten gelandet ist.
  4. Gleiche die Abgrenzung des Vormonats gegen die beglichene Rechnung ab und trage die Abweichung in die Schätzung des nächsten Monats vor.
  5. Ziehe jede Vorauszahlung um den tatsächlichen Verbrauch ab und prüfe den verbleibenden Saldo gegen ihren einjährigen Verfall.
  6. Bestätige, dass die Transfernutzung innerhalb der Fair-Use-Grenze blieb, und löse jede Überschreitungsmitteilung innerhalb ihres 30-Tage-Fensters.
  7. Bestätige, dass jede während des Monats erstellte Instanz das richtige Umgebungs-Tag geerbt hat und vom ersten Tag an im richtigen Konto gelandet ist.

Ziehe heute die CloudAMQP-Rechnung dieses Monats und ordne jede Position einer Instanz zu, die du benennen kannst. Wenn jede Position sauber zugeordnet ist, ist deine Broker-Buchhaltung ehrlich. Wenn eine nicht passt, hast du gerade entweder eine vergessene Instanz gefunden, die noch sekundengenau abrechnet, oder einen Marketplace-Zwilling, der sich in einer anderen Rechnung versteckt, und jede dieser Entdeckungen bezahlt die Prüfung.

Quelle: https://beancount.io/de/blog/2026/11/10/cloudamqp-instance-time-billing-infra-cogs-reconciliation-guide

Veröffentlicht: 10. November 2026