MQTT-Broker selbst betrieben vs. verwaltet im Vergleich

Die Entscheidung, ob Sie Ihren MQTT-Broker selbst betreiben oder einen verwalteten MQTT-Broker nutzen, bestimmt, wie viel Ihrer Woche in Infrastruktur statt in Produktarbeit fließt. Für Maschinenbauer und Fertigungsunternehmen im Mittelstand, deren IT- und OT-Teams ohnehin knapp besetzt sind, ist das oft die wichtigere Frage als die Wahl der Broker-Software. Dieser Artikel vergleicht beide Optionen hinsichtlich Betriebsaufwand, versteckter Kosten und Sicherheitsverantwortung und liefert Ihnen anschließend eine Entscheidungsmatrix, mit der Sie das passende Modell für Ihr Projekt sicher auswählen.

Wenn Sie vor dem Vergleich der Hosting-Modelle noch einmal nachlesen möchten, was ein MQTT-Broker leistet, beginnen Sie dort.

Was „selbst betrieben“ und „verwaltet“ tatsächlich bedeuten

Ein selbst gehosteter Broker ist Software, die Sie installieren und betreiben: Mosquitto, EMQX, VerneMQ, NanoMQ oder ein anderer Open-Source- oder kommerzieller Broker auf einer VM, einem Raspberry Pi, einem Kubernetes-Cluster oder einem Server in Ihrem Werk. Ihnen gehören das Betriebssystem, die Broker-Konfiguration, die TLS-Zertifikate, die Benutzerdatenbank, die Backups und der Pager.

Ein verwalteter MQTT-Broker ist ein Dienst. Der Anbieter betreibt den Broker, hält ihn aktuell, erneuert Zertifikate und stellt Endpunkte bereit; Sie erhalten einen Hostnamen, Ports und Zugangsdaten. Topic-Design, Client-Code und Daten bleiben weiterhin in Ihrer Verantwortung, die Server darunter jedoch nicht. ConnectMQ als verwalteter MQTT-Broker stellt Ihnen innerhalb weniger Minuten einen einsatzbereiten Broker zur Verfügung.

Dazwischen liegt eine Hybridform: Bring Your Own Cloud (BYOC). Dabei läuft der Broker in Ihrem Cloud-Konto, wird aber vom Anbieter betrieben. Dieses Modell behandelt der Leitfaden zum BYOC-MQTT-Broker.

Die eigentliche Arbeit beim Betrieb eines eigenen Brokers

Mosquitto zu installieren dauert eine Minute. Es gut zu betreiben erfordert dauerhaften Aufwand. Ein produktionsreifes selbst gehostetes Setup benötigt typischerweise:

# Minimal production mosquitto.conf - every line is something you now maintain
per_listener_settings true

listener 8883
certfile /etc/mosquitto/certs/fullchain.pem
keyfile  /etc/mosquitto/certs/privkey.pem
allow_anonymous false
password_file /etc/mosquitto/passwd
acl_file /etc/mosquitto/acl

listener 8084
protocol websockets
certfile /etc/mosquitto/certs/fullchain.pem
keyfile  /etc/mosquitto/certs/privkey.pem
allow_anonymous false
password_file /etc/mosquitto/passwd

persistence true
persistence_location /var/lib/mosquitto/
max_queued_messages 1000
message_size_limit 1048576

Diese Datei ist nur der Anfang. Drumherum brauchen Sie:

Zertifikats-Lebenszyklus – Zertifikate beschaffen, vor Ablauf erneuern und den Broker neu laden, ohne Clients zu trennen.
Patches für Betriebssystem und Broker – Sicherheitsmeldungen für Kernel, OpenSSL und den Broker selbst verfolgen.
Benutzer- und Zugangsdatenverwaltung – Geräte-Zugangsdaten anlegen, rotieren und widerrufen, idealerweise ohne Dateien von Hand zu bearbeiten.
Monitoring – Verbindungszahlen, Nachrichtenraten, Speicher und Festplatte beobachten und einen Menschen alarmieren, wenn etwas aus dem Ruder läuft.
Missbrauchsschutz – Ratenbegrenzungen, Verbindungslimits und das Blockieren von Brute-Force-Anmeldeversuchen.
Backups und Wiederherstellung – Persistenzdateien, Konfiguration und die Passwortdatenbank.
Kapazitätsplanung – erkennen, wann ein Knoten nicht mehr reicht, und wissen, was dann zu tun ist.
Rufbereitschaft – jemand, der reagiert, wenn der Broker um 3 Uhr nachts ausfällt.

Keine dieser Aufgaben ist für sich genommen schwierig. Zusammen werden sie zu einem Teilzeitjob, der in der ursprünglichen Schätzung selten auftaucht.

MQTT-Broker selbst betrieben vs. verwaltet im direkten Vergleich

Faktor	Selbst betrieben	Verwaltet
Zeit bis zur ersten Verbindung	Stunden bis Tage (Server, TLS, Authentifizierung)	Minuten (registrieren, Broker anlegen)
Infrastrukturkosten	Server oder VM, Speicher, Bandbreite	Tarifgebühr oder kostenloser Tarif
Personalkosten	Laufender Betrieb, Patches, Rufbereitschaft	Größtenteils vom Anbieter getragen
TLS-Zertifikate	Sie stellen aus und erneuern	Bereitgestellt und erneuert
Sicherheitshärtung	Vollständig Ihre Verantwortung	Geteilt: Anbieter härtet, Sie schützen Zugangsdaten
Anpassbarkeit	Volle Kontrolle über Broker und Plugins	Begrenzt auf das, was der Dienst anbietet
Netzwerkstandort	Überall, auch an Air-Gapped-Standorten	Internet-Endpunkt (oder Ihre Cloud mit BYOC)
Skalierung	Sie entwerfen und betreiben sie	Tarif oder Stufe wechseln
Datenkontrolle	Vollständig auf Ihrer Hardware	Abhängig von Anbieter und Bereitstellungsmodell

Keine Spalte gewinnt überall. Entscheidend ist, welche Schwächen Ihr Projekt weniger treffen.

Versteckte Kosten, die die meisten Teams übersehen

Die sichtbaren Kosten des Self-Hostings sind eine VM-Rechnung. Die versteckten Kosten sind meist höher:

Entwicklerzeit. Jede Stunde, die für das Erneuern von Zertifikaten, das Debuggen einer vollen Festplatte oder ein Broker-Upgrade draufgeht, fehlt bei Ihrer Geräte-Firmware oder Anwendung.
Kosten von Störungen. Ein Broker-Ausfall legt alle Geräte gleichzeitig lahm. Die Kosten sind die Ausfallzeit plus die Hektik, ein unvertrautes System unter Druck zu diagnostizieren.
Sicherheitsschulden. Ein vergessener Test-Listener auf Port 1883 mit allow_anonymous true ist ein häufiger Grund, warum Broker ungeschützt im Internet landen.
Wissenskonzentration. Oft weiß nur eine Person, wie der Broker konfiguriert ist. Verlässt sie das Unternehmen, geht das Wissen mit.

Eine strukturierte Methode, diese Posten zu beziffern, finden Sie im Artikel zu den Gesamtbetriebskosten eines MQTT-Brokers. Verwenden Sie Ihre eigenen Gehalts- und Störungszahlen; generische Werte treffen die Realität selten.

Sicherheitsverantwortung: Wer ist wofür zuständig?

Sicherheit ist in beiden Modellen geteilt, die Aufteilung unterscheidet sich jedoch.

Bei einem selbst gehosteten Broker gehört Ihnen alles: Firewall-Regeln, TLS-Konfiguration, Cipher-Auswahl, Passwort-Hashing, ACL-Dateien, Härtung des Betriebssystems, Log-Aufbewahrung und Reaktion auf Angriffe.

Bei einem verwalteten MQTT-Broker verantwortet der Anbieter die Plattformebene. Bei ConnectMQ zum Beispiel stellt die Plattform TLS auf Port 8883 und Secure WebSocket auf 8084 mit einem Let's-Encrypt-Zertifikat bereit, dazu Mandantenisolation, tarifabhängige Kontingente, Flood-Schutz, IP-Sperren nach wiederholt fehlgeschlagenen Anmeldungen sowie Client-IDs, die an die ausgegebenen Zugangsdaten gebunden sind. Ihre Aufgaben bleiben:

Benutzernamen und Passwörter aus öffentlichen Repositories und Firmware-Dumps heraushalten.
Auf Geräten in Produktion TLS (8883 oder 8084) statt unverschlüsseltem 1883 verwenden.
Topics so gestalten, dass sensible Daten nicht dort veröffentlicht werden, wo sie nicht hingehören.

Der Leitfaden zu MQTT-Sicherheits-Best-Practices behandelt die Client-Seite im Detail. Unabhängig vom Modell gilt: Wer unter NIS2 fällt oder Produkte mit Blick auf den EU Cyber Resilience Act entwickelt, sollte die Aufteilung der Verantwortung zwischen eigenem Team und Anbieter schriftlich festhalten.

Wann Self-Hosting die richtige Wahl ist

Einen MQTT-Broker selbst zu betreiben, passt gut, wenn:

Das Netzwerk isoliert ist. Ein Air-Gapped-Werk oder ein Schiff ohne zuverlässige Verbindung braucht einen lokalen Broker.
Sie Broker-Funktionen benötigen, die ein Dienst nicht bietet, etwa ein eigenes Authentifizierungs-Plugin oder eine spezielle Bridge-Konfiguration.
Sie bereits ein erfahrenes Plattform-Team haben, bei dem Monitoring, Patches und Rufbereitschaft etabliert sind, sodass ein weiterer Dienst kaum zusätzlichen Aufwand bedeutet.
Regulierung eine On-Premises-Verarbeitung verlangt und eine vom Anbieter betriebene Bereitstellung in Ihrer Umgebung keine Option ist.

Selbst in diesen Fällen kombinieren viele Teams einen lokalen Edge-Broker mit einem Cloud-Broker für den Fernzugriff, verbunden über eine MQTT-Bridge oder eine Gateway-Anwendung. In Industrie-4.0-Projekten trägt der Edge-Broker im Werk häufig den Unified Namespace (UNS) des Standorts: Die ISA-95-Hierarchie (Enterprise → Site → Area → Line → Cell) bildet die Topic-Struktur, etwa acme/werk-stuttgart/montage/linie-1/zelle-3/temperatur, und die Bridge spiegelt ausgewählte Teilbäume in die Cloud. So bleiben SPS-nahe Abläufe lokal, während standortübergreifende Auswertungen denselben Namensraum nutzen. Mehr dazu im Beitrag Sparkplug B und Unified Namespace.

Wann ein verwalteter MQTT-Broker die bessere Wahl ist

Ein verwalteter MQTT-Broker gewinnt in der Regel, wenn:

Sie ein kleines Team sind und niemand Rufbereitschaft für Infrastruktur übernehmen möchte.
Sie einen Prototyp bauen oder ein Produkt starten und die Zeit bis zum ersten funktionierenden Gerät wichtiger ist als tiefgehende Anpassung.
Geräte über das Internet verteilt sind – Wohnungen, Fahrzeuge, entlegene Standorte, beim Kunden installierte Maschinen – und einen stabilen öffentlichen Endpunkt mit TLS benötigen.
Ihre Last stufenweise wächst. Der Wechsel von einem kostenlosen zu einem kostenpflichtigen Tarif oder einem dedizierten Cluster ist einfacher als der Umbau eines Servers.

ConnectMQ deckt diese Stufen ab: mit einem kostenlosen Serverless-Tarif (bis zu 25 Verbindungen, QoS bis 1, Nachrichten bis 256 KB), einem kostenpflichtigen Serverless-Tarif (bis zu 1.000 Verbindungen, QoS 2, Nachrichten bis 1 MB, Shared Subscriptions), isolierten Dedicated-Clustern, BYOC und einer Self-Managed-Enterprise-Option.

Eine Entscheidungsmatrix, die Sie heute nutzen können

Bewerten Sie jede Zeile für Ihr Projekt mit 0 bis 2 Punkten und addieren Sie dann jede Spalte.

Frage	Punkte für selbst betrieben	Punkte für verwaltet
Muss der Broker ohne Internetzugang laufen?	2 bei Ja	0
Haben Sie bereits ein Betriebsteam mit Rufbereitschaft?	2 bei Ja	2 bei Nein
Benötigen Sie eigene Broker-Plugins?	2 bei Ja	0
Ist die Markteinführungszeit entscheidend?	0	2 bei Ja
Sind die Geräte über das öffentliche Internet verteilt?	0	2 bei Ja
Werden weniger als zwei Personen das System betreuen?	0	2 bei Ja
Sind planbare Monatskosten wichtiger als die niedrigsten reinen Serverkosten?	0	2 bei Ja

Liegt die Spalte „verwaltet“ vorn, starten Sie mit einem verwalteten MQTT-Broker und halten Ihre Clients standardkonform, damit Sie später wechseln können, falls sich die Anforderungen ändern. Wie Sie portabel bleiben, erklärt der Artikel zum MQTT-Vendor-Lock-in.

Das verwaltete Modell in fünf Minuten testen

Den Unterschied spüren Sie sofort. Mit den installierten Kommandozeilen-Clients von Mosquitto abonnieren und veröffentlichen Sie gegen den öffentlichen MQTT-Broker, der für Tests und Prototypen gedacht ist, nicht für Produktionsdaten:

# Terminal 1: abonnieren (verwenden Sie ein eigenes, eindeutiges Präfix)
mosquitto_sub -h broker.connectmq.com -p 1883 -i sub-7f3a9 -t "connectmq/demo/7f3a9/#" -v

# Terminal 2: veröffentlichen
mosquitto_pub -h broker.connectmq.com -p 1883 -i pub-7f3a9 -t "connectmq/demo/7f3a9/temp" -m "21.4"

Wiederholen Sie das anschließend gegen Ihren eigenen privaten Broker über TLS, mit den im Portal generierten Zugangsdaten:

mosquitto_pub -h broker.connectmq.com -p 8883 --capath /etc/ssl/certs \
  -u YOUR_USERNAME -P YOUR_PASSWORD -i YOUR_CLIENT_ID \
  -V mqttv5 -t "plant1/line1/temp" -m "21.4"

Keine Zertifikate ausstellen, keine Konfigurationsdateien bearbeiten. Vergleichen Sie das mit der Checkliste von oben, und Sie haben den Kern der Entscheidung.

Starten Sie mit einem verwalteten MQTT-Broker

Wenn die Matrix in Richtung „verwaltet“ zeigt, testen Sie ConnectMQ mit echten Geräten, bevor Sie sich festlegen. Erstellen Sie einen kostenlosen Serverless-Broker ohne Kreditkarte, verbinden Sie ein Gerät über TLS und beobachten Sie mit dem MQTT-Client im Browser und dem Live-Topic-Explorer, wie Ihre Nachrichten ankommen. Einen breiteren Überblick über die Hosting-Optionen bietet der Leitfaden zum Cloud-MQTT-Broker.

Häufig gestellte Fragen

Ist ein selbst gehosteter MQTT-Broker günstiger als ein verwalteter MQTT-Broker?

Der Server selbst ist oft günstiger, doch zu den Gesamtkosten gehören Patches, Zertifikate, Monitoring und Rufbereitschaft. Für kleine Teams übersteigen die Personalkosten meist die Einsparungen beim Server.

Kann ich mit einem verwalteten MQTT-Broker beginnen und später auf einen selbst betriebenen wechseln?

Ja, sofern Ihre Clients Standard-MQTT 3.1.1 oder 5.0 verwenden und Sie anbieterspezifische Funktionen meiden. Ein Broker-Wechsel bedeutet dann nur, Host, Port und Zugangsdaten anzupassen.

Verliere ich bei einem verwalteten MQTT-Broker die Kontrolle über meine Daten?

Sie behalten die Kontrolle darüber, was Sie veröffentlichen und wer Zugangsdaten besitzt. Soll der Broker in Ihrem eigenen Cloud-Konto laufen, hält eine BYOC-Bereitstellung die Infrastruktur dort, während der Anbieter sie betreibt.

Was ist mit Brokern in Air-Gapped-Netzwerken?

Ein isoliertes Netzwerk braucht einen lokalen Broker. Ein gängiges Muster ist ein lokaler Edge-Broker für das Werk, der den UNS des Standorts trägt, plus ein verwalteter Cloud-MQTT-Broker für Remote-Dashboards, verbunden über eine Bridge oder ein Gateway.

MQTT-Broker selbst betrieben vs. verwaltet: Kosten, Risiko und Aufwand im Vergleich