Cloud-MQTT-Broker: Der komplette Leitfaden zu gehostetem MQTT

Ein Cloud-MQTT-Broker bietet Ihren Geräten, Apps und Services einen zuverlässigen, aus dem Internet erreichbaren Nachrichten-Hub, ohne dass Sie einen Server installieren, patchen oder skalieren müssen. Dieser Leitfaden erklärt, was ein gehosteter Broker ist, wie sich die Bereitstellungsmodelle unterscheiden, worauf Sie bei Sicherheit, Limits und Kosten achten sollten und wie Sie vom Laptop-Prototyp in den Produktivbetrieb kommen. Am Ende haben Sie eine funktionierende Verbindung zu einem privaten Broker und eine Checkliste für die Wahl eines Anbieters.

Was ist ein Cloud-MQTT-Broker?

Ein MQTT-Broker ist der Server, der jede veröffentlichte Nachricht empfängt und an alle passenden Subscriber weiterleitet. Falls Sie diese Rolle auffrischen möchten, beginnen Sie mit was ein MQTT-Broker leistet. Ein Cloud-MQTT-Broker ist dieselbe Software, die auf einer von einem Anbieter betriebenen Infrastruktur läuft und über einen öffentlichen Hostnamen erreichbar ist. Sie erhalten Endpunkte, Zugangsdaten und eine Verwaltungskonsole; der Anbieter kümmert sich um Server, Betriebssysteme, TLS-Zertifikate, Upgrades und Kapazität.

Der Unterschied zu „einer VM mit Mosquitto darauf“ liegt in der Verantwortung. Mit einer VM in der Cloud gehört der Broker weiterhin Ihnen: Konfiguration, Zertifikate, Monitoring, Sicherheitspatches und der Ausfall um drei Uhr nachts. Bei einem gehosteten Broker wird all das zur Aufgabe des Anbieters, und Sie nutzen MQTT als Dienst. Dieses Modell wird oft als MQTT-Broker as a Service bezeichnet, und es ist der Grund, warum die meisten neuen IoT-Projekte in der Cloud starten und nicht auf einem Server in der Abstellkammer.

Warum Teams MQTT in die Cloud verlagern

• Erreichbarkeit. Geräte im Feld verbinden sich über das öffentliche Internet mit einem stabilen Hostnamen, ohne eingehende Firewall-Regeln oder Port-Weiterleitungen an jedem Standort.
• Zeit bis zur ersten Nachricht. Einen Broker anzulegen dauert Minuten statt tagelanger Server-Härtung.
• Betriebsaufwand. Zertifikatserneuerungen, Betriebssystem-Patches, Broker-Upgrades und Kapazitätsplanung sind nicht mehr die Arbeit Ihres Teams.
• Elastisches Wachstum. Der Sprung von zehn Testgeräten auf Tausende ist ein Planwechsel, keine Neuarchitektur.
• Integrierte Werkzeuge. Ein guter Anbieter liefert einen Web-Client, einen Topic-Explorer und Einblick in Verbindungen, die Sie sonst selbst zusammenbauen müssten.

Die Kehrseiten sind ebenfalls real: Sie hängen von Verfügbarkeit und Roadmap des Anbieters ab, Daten verlassen Ihr Gelände, und Sie arbeiten innerhalb der Plan-Kontingente. Wir wägen beide Seiten in MQTT-Broker selbst betrieben vs. verwaltet ab.

Bereitstellungsmodelle für Cloud-MQTT-Broker

„Cloud-Broker“ umfasst mehrere sehr unterschiedliche Architekturen. Zu wissen, welche Sie einkaufen, ist wichtiger als jede Feature-Liste.

Serverless

Ein Serverless-MQTT-Broker läuft auf einem geteilten, mandantenfähigen Cluster. Sie erstellen einen Broker in Sekunden, zahlen im kleinen Maßstab nichts oder wenig und müssen sich nie um Instanzen kümmern. Gute Anbieter setzen strikte Mandantenisolation, Kontingente pro Plan und Flood-Schutz durch, damit ein lauter Mandant anderen nicht schaden kann. Die Einschränkungen sind die vom Plan festgelegten Limits für Verbindungen, Nachrichtengröße und Durchsatz. Wie diese Isolation funktioniert, behandeln wir in mandantenfähige MQTT-Broker.

Dedicated

Ein dedizierter MQTT-Broker stellt Ihnen einen isolierten Cluster bereit. Niemand sonst teilt sich Ihre CPU, Ihren Speicher oder Ihr Netzwerk, daher sind Latenz und Durchsatz besser planbar, und die Limits richten sich nach Ihrer Last statt nach einer geteilten Stufe.

BYOC

Bei einem BYOC-MQTT-Broker läuft der Broker in Ihrem eigenen Cloud-Konto. Die Daten bleiben so in einer Infrastruktur, die Sie kontrollieren, und die Ausgaben zählen auf Ihre bestehenden Cloud-Verträge, während der Anbieter den Broker weiterhin für Sie betreibt. Für regulierte Branchen ist das oft die Antwort, ebenso für Industrieunternehmen im DACH-Raum, die DSGVO, NIS2 oder interne Vorgaben nach IEC 62443 im eigenen Konto abbilden wollen; die Compliance-Seite beleuchtet MQTT-Datenresidenz.

Self-Managed Enterprise

Manche Umgebungen, etwa Werke ohne Internet-Ausgang oder streng segmentierte OT-Netze, können keinen externen Dienst nutzen. Eine selbst verwaltete Edition erlaubt es, dieselbe Broker-Software auf eigener Hardware zu betreiben, wobei Ihr Team den Betrieb übernimmt.

Sicherheit bei einem gehosteten MQTT-Broker

Der Umzug in die Cloud stellt Ihren Broker ins öffentliche Internet, Sicherheit ist also nicht optional. Das Wesentliche, nach Wichtigkeit geordnet:

1. TLS bei jeder Verbindung. Verwenden Sie Port 8883 für MQTT über TLS und 8084 für Secure WebSocket. Unverschlüsseltes 1883 ist nur für Wegwerf-Tests mit unkritischen Daten akzeptabel.
2. Eindeutige Zugangsdaten pro Gerät oder Service. Geteilte Passwörter machen aus einem kompromittierten Gerät eine kompromittierte Flotte.
3. Bindung der Client ID. Sind Client IDs an ausgegebene Zugangsdaten gebunden, kann ein gestohlenes Passwort nicht genutzt werden, um sich als anderes Gerät auszugeben.
4. Brute-Force-Schutz. Der Broker sollte IP-Adressen nach wiederholt fehlgeschlagenen Logins sperren.
5. Mandantenisolation. Prüfen Sie auf geteilter Infrastruktur, dass die Topics eines Kunden für andere unsichtbar sind.
6. Flood-Schutz und Kontingente. Ein fehlerhafter Client, der in einer Publish-Schleife hängt, sollte gedrosselt werden, statt den Broker lahmlegen zu dürfen.
7. Payload-Hygiene. Legen Sie niemals Geheimnisse oder personenbezogene Daten in Topic-Namen ab; Topic-Strings erscheinen in Logs und Tools.

Die vollständige Liste, inklusive Certificate Pinning auf Geräten und Rotation von Zugangsdaten, finden Sie in unseren MQTT Security Best Practices.

Limits und Kontingente, die Sie verstehen müssen

Jeder gehostete Broker setzt Limits durch, und diese prägen Ihr Design stärker, als die meisten erwarten. Fragen Sie nach diesen Zahlen, bevor Sie sich festlegen:

Überschreitet ein Client auf einem MQTT-5-Broker ein Kontingent, erhält er einen Reason Code statt eines stillen Verwerfens; 0x97 (Quota exceeded) ist der, auf den Sie achten sollten. Unser Artikel zu Verbindungskontingenten von MQTT-Brokern erklärt, wie Sie diese dimensionieren.

So funktionieren die Preise für Cloud-MQTT

Anbieter bepreisen gehostetes MQTT auf einige wiedererkennbare Arten:

• Nach Anzahl der Verbindungen, oft der dominierende Faktor bei Geräteflotten.
• Nach Nachrichtenvolumen oder Durchsatz, relevant bei hochfrequenter Telemetrie.
• Nach Cluster oder Instanz, typisch für Dedicated-Bereitstellungen.
• Nach Funktionsstufe, wobei QoS 2, größere Nachrichten oder Shared Subscriptions erst in höheren Plänen freigeschaltet werden.

Der auf dem Papier günstigste Plan ist nicht immer das günstigste System. Berücksichtigen Sie Engineering-Zeit für den Betrieb, die Kosten von Ausfällen und den Aufwand für einen Wechsel, falls der Anbieter nicht passt. MQTT-Broker-Preise schlüsselt die Modelle auf, und Total Cost of Ownership vergleicht die Ausgaben für verwaltete und selbst betriebene Broker über die Zeit. Das Lock-in-Risiko ist am geringsten, wenn der Anbieter Standard-MQTT ohne proprietäres SDK spricht, was wir in MQTT-Vendor-Lock-in vermeiden behandeln.

Verbindung zu einem MQTT-Broker in der Cloud: Praxis

Am schnellsten verstehen Sie gehostetes MQTT, indem Sie es nutzen. Beginnen Sie mit dem geteilten öffentlichen MQTT-Broker unter broker.connectmq.com, der kein Konto erfordert. Verwenden Sie eine eindeutige Client ID und ein eindeutiges Topic-Präfix, und denken Sie daran, dass der öffentliche MQTT-Broker für alle lesbar und nur für Tests und Prototypen gedacht ist, nicht für Produktivdaten:

# Terminal 1: abonnieren
mosquitto_sub -h broker.connectmq.com -p 1883 -i cloud-sub-r4t7 \
  -t "connectmq/demo/r4t7w2/#" -v

# Terminal 2: veröffentlichen
mosquitto_pub -h broker.connectmq.com -p 1883 -i cloud-pub-r4t7 \
  -t "connectmq/demo/r4t7w2/sensor1/temp" -m "22.4"

Für einen privaten Broker sieht der Ablauf so aus:

1. Registrieren Sie sich unter app.connectmq.com und wählen Sie einen Plan.
2. Erstellen Sie einen Broker.
3. Kopieren Sie den generierten Benutzernamen, das Passwort und die Client ID aus dem Portal.
4. Verbinden Sie sich über TLS auf Port 8883 (oder aus dem Browser per WSS auf 8084 mit dem Pfad /mqtt).

mosquitto_sub -h broker.connectmq.com -p 8883 --capath /etc/ssl/certs \
  -i YOUR_CLIENT_ID -u YOUR_USERNAME -P YOUR_PASSWORD \
  -t "plant1/#" -v

Das Zertifikat wird von Let's Encrypt ausgestellt, daher verifizieren es Standard-CA-Bundles. Unter macOS und Windows verwenden Sie --cafile mit einer CA-Bundle-Datei statt --capath.

Ein produktionsnaher Client in Python

Dieser paho-mqtt-2.x-Client verbindet sich mit Zugangsdaten, meldet seine Präsenz mit einem Retained-Status und einem Last Will an und nutzt MQTT 5 Message Expiry, damit veraltete Messwerte nicht an Subscriber ausgeliefert werden, die erst viel später online kommen:

import json
import time

import paho.mqtt.client as mqtt
from paho.mqtt.packettypes import PacketTypes
from paho.mqtt.properties import Properties

BASE = "plant1/line1/sensor1"

def on_connect(client, userdata, flags, reason_code, properties):
    if reason_code.is_failure:
        print("Connect failed:", reason_code)
        return
    client.publish(f"{BASE}/status", "online", qos=1, retain=True)
    client.subscribe(f"{BASE}/cmd", qos=1)

def on_message(client, userdata, msg):
    print("Command:", msg.payload.decode())

client = mqtt.Client(
    mqtt.CallbackAPIVersion.VERSION2,
    client_id="YOUR_CLIENT_ID",
    protocol=mqtt.MQTTv5,
)
client.username_pw_set("YOUR_USERNAME", "YOUR_PASSWORD")
client.will_set(f"{BASE}/status", "offline", qos=1, retain=True)
client.tls_set()
client.reconnect_delay_set(min_delay=1, max_delay=60)
client.on_connect = on_connect
client.on_message = on_message

client.connect("broker.connectmq.com", 8883, keepalive=30)
client.loop_start()

props = Properties(PacketTypes.PUBLISH)
props.MessageExpiryInterval = 60  # Sekunden

while True:
    payload = json.dumps({"temp": 22.4, "ts": int(time.time())})
    client.publish(f"{BASE}/telemetry", payload, qos=1, properties=props)
    time.sleep(10)

Im ConnectMQ-Portal können Sie im Live-Topic-Explorer verfolgen, wie diese Nachrichten eintreffen, über den MQTT-Client im Browser einen Befehl zurücksenden und prüfen, ob ein bestimmter Client verbunden ist, indem Sie $SYS/broker/connection/{clientId}/state abonnieren.

Einen Cloud-Broker in den Rest Ihres Stacks integrieren

Ein Broker leitet Nachrichten weiter; er speichert sie nicht in Ihrer Datenbank und ruft keine APIs auf. Das saubere, portable Muster besteht darin, Integrationswerkzeuge als gewöhnliche MQTT-Clients anzubinden:

• Zeitreihenspeicherung: Der MQTT-Consumer von Telegraf, der in InfluxDB schreibt, oder ein kleiner Python-Subscriber, der in PostgreSQL oder TimescaleDB schreibt.
• Flows und Automatisierung: Node-RED mit einem mqtt-broker-Konfigurationsknoten, der mit TLS auf Port 8883 auf Ihren Broker zeigt.
• Dashboards: Grafana auf der Datenbank oder eine Browser-App mit MQTT.js über WSS.
• Smart Home: Die MQTT-Integration von Home Assistant.

Da jedes dieser Werkzeuge ein Standard-Client ist, können Sie Tools austauschen oder ergänzen, ohne die Geräte-Firmware anzufassen. Für lastverteilte Backend-Consumer verteilen MQTT 5 Shared Subscriptions ($share/group/topic) Nachrichten auf mehrere Worker; sie sind typischerweise kostenpflichtigen Stufen vorbehalten, wie in der Plantabelle unten.

Einen Anbieter für Cloud-MQTT-Broker auswählen

Nutzen Sie diese Checkliste beim Vergleich von Anbietern. Sie ergänzt unseren umfassenderen Leitfaden dazu, wie Sie einen IoT-MQTT-Broker auswählen.

1. Unterstützt MQTT 3.1.1 und 5.0 mit Standard-Clients, ohne proprietäres SDK.
2. Bietet TLS- und Secure-WebSocket-Endpunkte mit einem öffentlich vertrauenswürdigen Zertifikat.
3. Veröffentlicht klare Kontingente für Verbindungen, Nachrichtengröße, QoS und Rate.
4. Stellt eine Gratis-Stufe oder einen öffentlichen MQTT-Broker für Tests bereit, um Ihre Clients vor dem Bezahlen zu validieren.
5. Bietet einen Weg von geteilt zu Dedicated oder BYOC, ohne den Client-Code zu ändern.
6. Gibt Ihnen Transparenz: Verbindungsstatus, Live-Topic-Ansicht und Alarme bei relevanten Werten.
7. Dokumentiert Mandantenisolation und Missbrauchsschutz in geteilten Plänen.
8. Beantwortet Ihre Fragen zu Datenresidenz und Support schriftlich.

Gehen Sie vor dem Start die MQTT-Produktions-Checkliste durch, und wenn Sie einen selbst gehosteten Mosquitto ablösen, ersparen Ihnen die Schritte in Mosquitto zu einem Cloud-MQTT-Broker migrieren einige Überraschungen. Sobald Sie live sind, erklärt MQTT-Broker-Monitoring, welche Signale Sie beobachten sollten.

Wie ConnectMQ hineinpasst

ConnectMQ ist ein verwalteter MQTT-Broker, der auf den oben beschriebenen Bereitstellungsmodellen aufbaut:

Jeder Broker unterstützt MQTT 3.1.1 und 5.0 über TCP 1883, TLS 8883, WebSocket 8083 und Secure WebSocket 8084, mit einem Let's-Encrypt-Zertifikat. Das Portal enthält einen MQTT-Client im Browser, einen Live-Topic-Explorer, ein Dashboard, eine nach ISA-95-Ebenen gegliederte Geräteansicht sowie Schwellenwert-Alarmregeln mit Alarmprotokoll, auf Englisch oder Türkisch. Auf der Sicherheitsseite erhalten Sie Mandantenisolation, Kontingente pro Plan, Flood-Schutz, IP-Sperren nach wiederholt fehlgeschlagenen Logins und an ausgegebene Zugangsdaten gebundene Client IDs. Für industrielle Nutzer erkennt ConnectMQ außerdem ISA-95- und Unified-Namespace-Topics und dekodiert Sparkplug-B-Payloads.

In Industrie-4.0-Projekten wird der Cloud-MQTT-Broker damit zum Kern eines Unified Namespace (UNS): Die ISA-95-Anlagenhierarchie (Enterprise → Site → Area → Line → Cell) wird direkt zur Topic-Struktur, etwa acme/werk-stuttgart/montage/linie-1/zelle-3/temperatur. SPS-Gateways, OPC-UA-Server und Edge-Geräte veröffentlichen an ihrer Stelle im Baum, MES, ERP und Analysedienste abonnieren genau die Ebene, die sie brauchen. Wie Sparkplug B in dieses Modell passt, erklärt Sparkplug B und Unified Namespace.

Was ConnectMQ bewusst nicht tut, ist Ihren Daten-Stack zu ersetzen: Es gibt keine integrierte Rule Engine und keine Datenbank-Bridge, sodass Speicherung und Automatisierung von Standard-MQTT-Clients wie Telegraf, Node-RED oder Ihren eigenen Services übernommen werden, wie oben beschrieben.

Starten Sie Ihren Cloud-MQTT-Broker kostenlos

Testen Sie Ihre Clients noch heute auf broker.connectmq.com und erstellen Sie dann einen privaten Broker unter app.connectmq.com. Der kostenlose Serverless-Plan benötigt keine Kreditkarte, und dieselben Zugangsdaten und derselbe Code funktionieren weiter, wenn Sie auf einen kostenpflichtigen, Dedicated- oder BYOC-Plan wechseln.

Häufig gestellte Fragen

Was ist der Unterschied zwischen einem Cloud-MQTT-Broker und einem verwalteten MQTT-Broker?

In der Praxis überschneiden sich die Begriffe. „Cloud“ beschreibt, wo der Broker läuft und wie Geräte ihn erreichen, „verwaltet“ beschreibt, wer ihn betreibt; die meisten gehosteten Angebote sind beides, aber eine VM mit Ihrem eigenen Mosquitto ist zwar in der Cloud gehostet, aber nicht verwaltet.

Ist ein Cloud-MQTT-Broker sicher genug für Industriedaten?

Das kann er sein, wenn Sie TLS bei jeder Verbindung, eindeutige Zugangsdaten pro Gerät und ein Bereitstellungsmodell verwenden, das Ihren Anforderungen entspricht. Werke mit strengen Vorgaben zur Datenresidenz wählen oft Dedicated- oder BYOC-Bereitstellungen statt einer geteilten Stufe.

Kann ich einen kostenlosen Cloud-MQTT-Broker produktiv nutzen?

Eine Gratis-Stufe eignet sich für kleine, unkritische Bereitstellungen innerhalb ihrer Limits, etwa bis zu 25 Verbindungen im kostenlosen Serverless-Plan von ConnectMQ. Der anonyme öffentliche MQTT-Broker ist niemals für den Produktivbetrieb geeignet, weil jeder die dort veröffentlichten Daten lesen kann.

Brauche ich ein spezielles SDK, um mich mit einem gehosteten MQTT-Broker zu verbinden?

Nicht bei einem standardbasierten Anbieter. Jeder MQTT-3.1.1- oder 5.0-Client funktioniert, darunter paho-mqtt, MQTT.js, MQTTnet, PubSubClient und die Mosquitto-CLI-Tools.

Wie speichere ich Daten aus einem Cloud-MQTT-Broker in einer Datenbank?

Betreiben Sie einen Subscriber, der in Ihre Datenbank schreibt, etwa Telegraf für InfluxDB oder ein kurzes Python-Skript für PostgreSQL. Der Broker liefert die Nachrichten; der Subscriber entscheidet, wo sie gespeichert werden.