MQTT-Broker-Preise erklärt: Preismodelle verstehen und die eigene Rechnung abschätzen

MQTT-Broker-Preise sind vor allem deshalb so unübersichtlich, weil die Anbieter Unterschiedliches messen: Der eine rechnet pro Verbindung ab, der nächste pro Nachricht, ein dritter pro Gigabyte und ein vierter pro dediziertem Cluster. Dieser Leitfaden erklärt jedes Preismodell, zeigt, welche Workloads es begünstigt oder benachteiligt, und liefert Ihnen eine wiederholbare Methode, um Ihre eigene Nutzung abzuschätzen, damit Sie Angebote auf gleicher Basis vergleichen können. Er enthält bewusst keine Preisangaben, denn diese ändern sich häufig; die Methode bleibt gültig.

Warum MQTT-Broker-Preise so stark variieren

Die tatsächlichen Kosten eines Brokers entstehen durch wenige Ressourcen: Arbeitsspeicher pro offener Verbindung, CPU pro weitergeleiteter Nachricht, Netzwerkbandbreite, Speicher für Retained Messages und Nachrichten in Warteschlangen sowie die Menschen, die ihn betreiben. Jeder Anbieter wählt eine oder zwei davon als Abrechnungseinheit und bündelt den Rest in Planlimits. Deshalb können zwei Dienste für genau dieselbe Geräteflotte günstig oder teuer wirken, je nachdem, wie Ihr Traffic aussieht.

Betrachten Sie zwei Flotten. Die erste besteht aus vielen Tausend Geräten, die jeweils alle fünfzehn Minuten einen kleinen Messwert senden. Die zweite besteht aus einigen Dutzend Maschinen in einem Werk, die hochfrequente Daten für Zustandsüberwachung oder Predictive Maintenance streamen. Die erste ist verbindungsintensiv und nachrichtenarm, die zweite genau umgekehrt. Ein Modell pro Verbindung begünstigt die zweite Flotte, ein Modell pro Nachricht die erste. Wer sein Lastprofil kennt, hat schon fast gewonnen.

Die gängigen Preismodelle für MQTT-Broker

1. Pro Verbindung

Sie zahlen für die Anzahl gleichzeitiger Verbindungen, häufig gemessen als Spitzenwert oder Monatsmaximum. Das Nachrichtenvolumen kann im Rahmen einer Fair-Use-Regel unbegrenzt oder pro Plan gedeckelt sein.

• Begünstigt: gesprächige Geräte, hohe Nachrichtenraten, kleine Flotten.
• Benachteiligt: riesige Flotten überwiegend inaktiver Geräte sowie Architekturen, in denen jeder Browser-Tab oder jede mobile App eine eigene Verbindung hält.
• Achten Sie darauf: ob gleichzeitige oder kumulierte Verbindungen gezählt werden und ob kurze Reconnect-Stürme in den Spitzenwert einfließen.

2. Pro Verbindungsminute (Sitzungsdauer)

Sie zahlen für die Gesamtzeit, in der Clients verbunden sind, meist gezählt in Verbindungs- oder Sitzungsminuten. Dieses Modell ist bei Cloud-IoT-Plattformen verbreitet, die alles nach Verbrauch abrechnen.

• Begünstigt: Geräte, die sich kurz verbinden, publizieren und wieder trennen.
• Benachteiligt: dauerhaft verbundene Geräte, die jeweils einen vollen Monat an Minuten ansammeln.
• Achten Sie darauf: wie Minutenbruchteile gerundet werden und ob Keepalive-Traffic zusätzlich als Nachrichten zählt.

3. Pro Nachricht

Sie zahlen pro veröffentlichter oder zugestellter Nachricht, oft in Paketen. Manche Dienste zählen eine Nachricht einmal beim Publish; andere zählen jede Zustellung an jeden Subscriber, sodass ein Publish mit zehn Subscribern als elf Nachrichten zählt. Manche zählen in festen Größeneinheiten, sodass ein großer Payload als mehrere Nachrichten gilt.

• Begünstigt: große, ruhige Flotten.
• Benachteiligt: hochfrequente Telemetrie, Fan-out an viele Subscriber und große Payloads.
• Achten Sie darauf: ob Pings, Subscribes, Retained-Zustellungen und QoS-Bestätigungen mitgezählt werden.

4. Pro Traffic-Volumen

Sie zahlen pro übertragenem Gigabyte eingehend, ausgehend oder beides. Das kommt der Abrechnung von Cloud-Netzwerken sehr nahe.

• Begünstigt: kompakte binäre Payloads wie Sparkplug B oder CBOR.
• Benachteiligt: ausführliches JSON, hoher Fan-out und videoähnliche Workloads.
• Achten Sie darauf: ob TLS- und Protokoll-Overhead enthalten sind und ob Ingress und Egress unterschiedlich bepreist werden.

5. Gestaffelte Pläne mit Kontingenten

Sie zahlen einen festen Betrag pro Stufe, und jede Stufe enthält Limits für Verbindungen, Nachrichtengröße, QoS-Level, Durchsatz oder Funktionen. Für die Budgetplanung ist dies das am besten vorhersehbare Modell.

• Begünstigt: Teams, die eine bekannte monatliche Rechnung wünschen.
• Benachteiligt: Workloads, die knapp über einer Stufengrenze liegen.
• Achten Sie darauf: was am Limit passiert: Ablehnung, Drosselung oder automatische Abrechnung von Mehrverbrauch.

6. Dedizierte Kapazität

Sie zahlen für einen isolierten Cluster, bemessen in Instanzen, Knoten oder Kapazitätseinheiten, unabhängig davon, wie stark Sie ihn nutzen. BYOC (Bring Your Own Cloud) ist eine Variante, bei der die Infrastruktur in Ihrem eigenen Cloud-Konto läuft: Sie bezahlen den Cloud-Anbieter für die Ressourcen und den Hersteller für das Management.

• Begünstigt: große, gleichmäßige Workloads, strikte Isolation und Anforderungen an die Datenresidenz.
• Benachteiligt: kleine oder sprunghafte Workloads, die Kapazität ungenutzt lassen.
• Achten Sie darauf: Mindestlaufzeiten, Aufschläge für Hochverfügbarkeit und wer den zonenübergreifenden Traffic bezahlt.

7. Lizenzen für den Eigenbetrieb

Bei Software, die Sie selbst betreiben, berechnen Hersteller möglicherweise pro Knoten, pro Kern, pro Verbindungsstufe oder per Enterprise-Vertrag. Die Lizenz ist nur ein Teil der Kosten; Infrastruktur und Personalaufwand überwiegen häufig. Unser Leitfaden zu den Gesamtbetriebskosten eines MQTT-Brokers behandelt diese versteckten Kosten.

Preismodelle auf einen Blick

So schätzen Sie Ihre Nutzung ab

Bevor Sie Angebote vergleichen, sollten Sie Ihren Workload messen oder abschätzen. Jedes Preismodell lässt sich aus denselben wenigen Kennzahlen berechnen:

1. Geräte (D): Anzahl der publizierenden Clients.
2. Weitere Clients (B): Backends, Dashboards, Browser-Sitzungen, Node-RED-Instanzen.
3. Maximale gleichzeitige Verbindungen: meist D + B, plus Reserve für überlappende Reconnects.
4. Nachrichten pro Gerät und Stunde (R).
5. Durchschnittliche Payload-Größe in Byte (S).
6. Durchschnittliche Subscriber pro Nachricht (F): Fan-out.
7. Verbundener Zeitanteil (C): 1,0 für dauerhaft verbundene Geräte.

Daraus leiten Sie die Monatswerte ab (mit 730 Stunden pro Monat):

published messages / month  = D x R x 730
delivered messages / month  = published x F
connection-minutes / month  = (D + B) x C x 730 x 60
payload traffic in  (bytes)  = published x S
payload traffic out (bytes)  = delivered x S

Ein Rechenbeispiel mit angenommenen Werten: 400 Geräte, die alle 30 Sekunden publizieren (R = 120), ein JSON-Payload von 200 Byte und zwei Subscriber pro Nachricht (ein Datenbank-Writer und ein Dashboard).

published  = 400 x 120 x 730          = 35,040,000 messages / month
delivered  = 35,040,000 x 2           = 70,080,000 messages / month
traffic in = 35,040,000 x 200 bytes   = about 7 GB / month
traffic out= 70,080,000 x 200 bytes   = about 14 GB / month
peak connections = 400 + 3 backend clients + headroom

Wenden Sie die Einheiten jedes Anbieters auf diese Zahlen an und schlagen Sie bei den Traffic-Schätzungen einige zehn Prozent für Protokoll-Overhead (TLS, MQTT-Header, Keepalives) auf, statt anzunehmen, dass die Payload-Bytes schon alles sind. Ein Pilotprojekt auf einem echten Broker, beobachtet über dessen Konsole oder die $SYS-Statistiken, ermöglicht es Ihnen, Annahmen durch gemessene Werte zu ersetzen.

Kostenhebel, die Sie selbst steuern

Unabhängig vom Modell können Sie die Rechnung meist durch Designentscheidungen senken:

• Bei Änderung oder mit Totbändern publizieren statt in festen, kurzen Intervallen. Das entspricht dem Report-by-Exception-Prinzip von Sparkplug B, das in einem Unified Namespace (UNS) üblich ist: Die Topic-Struktur folgt der ISA-95-Hierarchie (Enterprise, Site, Area, Line, Cell), und jede Maschine meldet nur Änderungen, statt den UNS mit unveränderten Werten zu fluten. Mehr dazu unter Sparkplug B und Unified Namespace.
• Mehrere Messwerte in einer Nachricht bündeln, wo die Latenz es zulässt.
• Kompakte Payloads oder MQTT-5-Topic-Aliase verwenden, um Bytes einzusparen.
• Shared Subscriptions statt vieler identischer Consumer nutzen.
• Keine eigene Broker-Verbindung pro Browser-Tab, wenn ein Backend den Fan-out übernehmen kann.

Ihre Schätzung den ConnectMQ-Plänen zuordnen

ConnectMQ nutzt gestaffelte Pläne, die über Limits definiert sind, was die Schätzung einfach macht: Suchen Sie den kleinsten Plan, dessen Limits Ihre maximalen Verbindungen, Ihr QoS-Level und Ihre Nachrichtengröße abdecken. Serverless (Free) läuft auf einem geteilten Cluster mit bis zu 25 Verbindungen, QoS bis 1 und Nachrichten bis 256 KB, was für Prototypen und kleine Pilotprojekte passt. Serverless (Paid) erhöht das auf bis zu 1.000 Verbindungen, QoS 2, Nachrichten bis 1 MB und Shared Subscriptions. Darüber hinaus bietet Dedicated einen isolierten Cluster, BYOC läuft in Ihrem eigenen, von ConnectMQ verwalteten Cloud-Konto, und Self Managed Enterprise läuft auf Ihrer Infrastruktur. Wird ein Kontingent erreicht, erhalten MQTT-5-Clients einen eindeutigen Reason Code wie 0x97 (Quota exceeded), sodass Limits nie stillschweigend greifen. Der Artikel über Verbindungslimits von MQTT-Brokern erklärt, wie Sie damit planen.

Pläne bei ConnectMQ vergleichen

Starten Sie mit dem kostenlosen Serverless-Plan unter app.connectmq.com ohne Kreditkarte, messen Sie Ihren realen Traffic während eines Pilotprojekts und steigen Sie erst dann auf, wenn die Zahlen es verlangen. ConnectMQ ist ein verwalteter MQTT-Broker mit denselben Endpunkten und demselben Client-Code in jedem Plan. Hintergründe zu Bereitstellungsmodellen finden Sie in unserem Leitfaden zum Cloud-MQTT-Broker, und unter kostenloser Tarif für MQTT-Broker erfahren Sie, was Sie von Gratisplänen am Markt erwarten können.

Häufig gestellte Fragen

Welches Preismodell für MQTT-Broker ist am günstigsten?

Keines ist grundsätzlich am günstigsten. Preise pro Verbindung passen zu wenigen aktiven Clients, Preise pro Nachricht zu vielen ruhigen Geräten und dedizierte Kapazität zu großen, gleichmäßigen Lasten. Schätzen Sie zuerst Ihren Workload ab und wenden Sie dann jedes Modell darauf an.

Zählen Keepalive-Pings als Nachrichten?

Das hängt vom Anbieter ab. Manche zählen nur Publishes der Anwendung, andere alle MQTT-Pakete. Fragen Sie ausdrücklich nach, denn kurze Keepalive-Intervalle summieren sich bei einer großen Flotte.

Wie vermeide ich überraschende Mehrkosten?

Wählen Sie einen Plan, dessen Limits ablehnen oder drosseln statt automatisch abzurechnen, überwachen Sie die Nutzung in der Konsole und richten Sie Warnungen ein, bevor Sie ein Kontingent erreichen.

Kann ich die Kosten ohne echte Geräte abschätzen?

Ja, mit der Formel aus diesem Leitfaden und angenommenen Raten und Payload-Größen. Ersetzen Sie die Annahmen so bald wie möglich durch gemessene Werte aus einem kleinen Pilotprojekt.