Ein BYOC-MQTT-Broker läuft in Ihrem eigenen Cloud-Konto, während ein spezialisierter Anbieter die Betriebsarbeit übernimmt. Dieser Artikel erklärt, wie das Bring-Your-Own-Cloud-Modell funktioniert, wo die Verantwortlichkeiten liegen, wann es gegenüber geteiltem oder dediziertem Hosting die richtige Wahl ist und wie Sie Ihr Konto vor dem Rollout vorbereiten.
Was ist ein BYOC-MQTT-Broker?
„Bring Your Own Cloud" beschreibt ein Bereitstellungsmodell, bei dem die Software auf Infrastruktur läuft, die Ihnen gehört und die Sie bezahlen, typischerweise in einem Cloud-Konto oder einer Subscription unter der Kontrolle Ihrer Organisation, während der Anbieter sie verwaltet. Die virtuellen Maschinen oder Container des Brokers, Netzwerk, Festplatten und Load Balancer liegen in Ihrem Konto. Die Ingenieure oder die Automatisierung des Anbieters stellen den Broker über von Ihnen gewährte Zugriffe bereit, konfigurieren, aktualisieren und überwachen ihn.
Vergleichen Sie das mit den zwei bekannteren Hosting-Optionen:
- Geteiltes (Serverless-)Hosting. Viele Kunden teilen sich einen Cluster im Konto des Anbieters. Sie erhalten Endpunkte und Zugangsdaten in Minuten und zahlen nichts für ungenutzte Kapazität, wählen aber die zugrunde liegende Infrastruktur nicht selbst.
- Dediziertes Hosting. Sie erhalten Ihren eigenen isolierten Cluster, weiterhin im Konto des Anbieters. Die Leistung teilen Sie mit niemandem, die Infrastruktur gehört aber dem Anbieter.
- BYOC. Ihr eigener isolierter Broker in Ihrem eigenen Konto. Der Nachrichtenverkehr fließt über Infrastruktur, die Sie kontrollieren, unter Ihren Cloud-Sicherheitsrichtlinien und Ihrer Abrechnung.
Wenn Sie neu darin sind, wie Broker in ein IoT-System passen, behandelt was ein MQTT-Broker leistet die Grundlagen.
Warum Teams sich für Bring Your Own Cloud entscheiden
Datenkontrolle und Compliance
Der häufigste Grund ist die Datenkontrolle. Manche Organisationen haben die Richtlinie, dass Produktionsdaten, einschließlich Gerätetelemetrie, in eigenen Konten bleiben müssen, wo ihre eigene Protokollierung, Verschlüsselungsschlüssel, Netzwerkkontrollen und Audits gelten. Eine BYOC-Bereitstellung lässt die MQTT-Ebene diese Richtlinie erfüllen, ohne dass das Team selbst zum Broker-Betreiber werden muss. Für Industrieunternehmen im DACH-Raum spielen dabei oft DSGVO, die Anforderungen aus NIS2 und interne Vorgaben nach IEC 62443 eine Rolle, die bestimmen, wo Maschinendaten liegen und wer darauf zugreift. Unser Leitfaden zur Datenresidenz bei MQTT geht tiefer auf Standort- und Regulierungsfragen ein.
Netzwerknähe
Wenn Ihre Consumer, etwa Stream-Prozessoren, Datenbanken und Analysedienste, bereits in einem bestimmten Cloud-Konto und einer bestimmten Region laufen, hält ein Broker in ihrer Nähe den Verkehr im privaten Netzwerk. Subscriber innerhalb Ihres virtuellen Netzwerks können sich verbinden, ohne das öffentliche Internet zu durchqueren, während Geräte weiterhin einen öffentlichen Endpunkt erreichen.
Bestehende Cloud-Zusagen nutzen
Viele Unternehmen haben Verbrauchszusagen mit einem Cloud-Anbieter ausgehandelt. Läuft die Infrastruktur des Brokers in Ihrem Konto, zählen die Ausgaben für Rechenleistung und Netzwerk auf diese Zusagen und erscheinen in Ihren bestehenden Kostenberichten.
Einfachere Sicherheitsprüfung
Sicherheitsteams genehmigen Infrastruktur oft leichter, wenn sie in einem Konto liegt, das sie bereits überwachen, und unter Richtlinien läuft, die sie bereits durchsetzen, als eine neue Umgebung eines Drittanbieters von Grund auf zu bewerten.
Wer ist bei einer BYOC-Bereitstellung wofür zuständig?
Die genaue Aufteilung legt Ihre Vereinbarung mit dem Anbieter fest, das typische Muster sieht aber so aus:
| Bereich | Sie (Kontoinhaber) | Anbieter (Betreiber) |
|---|---|---|
| Cloud-Konto, Abrechnung, Organisationsrichtlinien | Ja | Nein |
| Netzwerkdesign, IP-Bereiche, Peering, Firewall-Richtlinie | Genehmigt und verantwortet | Schlägt Broker-spezifische Teile vor und setzt sie um |
| Installation und Konfiguration des Brokers | Prüft | Ja |
| Upgrades und Sicherheitspatches für den Broker | Genehmigt Wartungsfenster | Ja |
| TLS-Zertifikate für Broker-Endpunkte | Domain-Entscheidungen | Ausstellung und Erneuerung |
| Überwachung des Broker-Zustands und Störungsbehebung | Eskalationskontakt | Ja |
| Geräte-Firmware und Client-Anwendungen | Ja | Nein |
| Daten-Consumer und nachgelagerte Integrationen | Ja | Nein |
Der Kerngedanke: Sie behalten Eigentum und Einblick in die Infrastruktur, der Anbieter trägt die Betriebslast. Vereinbaren Sie schriftlich den Umfang der Zugriffe, Wartungsfenster, Eskalationswege und wie Zugriffe widerrufen werden.
BYOC vs. Shared, Dedicated und Self-Hosted
| Kriterium | Geteiltes Serverless | Dedicated | BYOC | Self-Hosted |
|---|---|---|---|---|
| Wo die Infrastruktur läuft | Konto des Anbieters | Konto des Anbieters | Ihr Konto | Ihr Konto oder Rechenzentrum |
| Wer den Broker betreibt | Anbieter | Anbieter | Anbieter | Ihr Team |
| Isolation von anderen Kunden | Logisch | Physischer Cluster | Physisch, in Ihrem Konto | Vollständig |
| Zeit bis zur ersten Verbindung | Minuten | Kurz | Länger (Kontoeinrichtung) | Abhängig von Ihrem Team |
| Infrastrukturrechnung | Im Tarif enthalten | Im Tarif enthalten | Ihre Cloud-Rechnung plus Dienst | Ihre Cloud- oder Hardware-Rechnung |
| Ihr Betriebsaufwand | Sehr gering | Sehr gering | Gering | Hoch |
BYOC liegt zwischen dediziertem Hosting und Self-Hosting. Wenn Sie nicht sicher sind, ob Sie es brauchen, bietet ein dedizierter MQTT-Broker oft genug Isolation bei weniger Einrichtungsaufwand. Wenn Sie volle Kontrolle wollen und die Leute haben, um ihn zu betreiben, vergleichen Sie den Aufwand unter MQTT-Broker selbst betrieben vs. verwaltet.
So funktioniert BYOC bei ConnectMQ
ConnectMQ bietet BYOC als einen seiner Tarife an: Der Broker läuft in Ihrem Cloud-Konto und wird für Sie verwaltet. Er verhält sich genauso wie in den anderen Tarifen. Clients verbinden sich per MQTT 3.1.1 oder MQTT 5.0 über die Standardports TCP 1883, TLS 8883, WebSocket 8083 und Secure WebSocket 8084 mit dem Pfad /mqtt. Geräte-Firmware und Anwendungen, die für einen Serverless- oder Dedicated-Broker geschrieben wurden, brauchen also keine Codeänderungen, sondern nur neue Verbindungsdaten.
Die Plattformfunktionen bleiben verfügbar: generierte Zugangsdaten mit daran gebundenen Client-IDs, Mandantenisolation und tarifabhängige Kontingente, Flood-Schutz, IP-Sperren nach wiederholt fehlgeschlagenen Anmeldungen, MQTT-5-Funktionen wie Shared Subscriptions, Session Expiry und Message Expiry sowie Sparkplug-B-Dekodierung mit erneutem Veröffentlichen in ISA-95-Topics für Industrieprojekte. Damit kann der BYOC-Broker als Kern eines Unified Namespace (UNS) dienen: Die ISA-95-Anlagenhierarchie (Enterprise → Site → Area → Line → Cell) wird zur Topic-Struktur, etwa acme/werk-stuttgart/montage/linie-1/zelle-3/temperatur, und MES, ERP und Analysedienste in Ihrem Konto abonnieren genau die Ebene, die sie brauchen. Mehr dazu im Beitrag zu Sparkplug B und Unified Namespace.
Da BYOC von Ihrer Cloud-Umgebung abhängt, klären Sie die unterstützten Cloud-Anbieter, Regionen und das Zugriffsmodell direkt mit dem Team, bevor Sie den Rollout planen.
Ihr Cloud-Konto vorbereiten
Unabhängig vom Anbieter verkürzt dieselbe Vorbereitung das BYOC-Onboarding:
- Legen Sie ein eigenes Konto oder eine eigene Subscription für den Broker an, damit Berechtigungen, Abrechnung und Audit-Logs von anderen Workloads getrennt sind.
- Wählen Sie die Region danach, von wo sich Geräte verbinden, wo die Consumer laufen und welche Residenzanforderungen gelten.
- Reservieren Sie Netzwerkbereiche, die nicht mit Ihren bestehenden VPCs oder On-Premises-Netzen kollidieren, falls Sie Peering oder VPN-Verbindungen planen.
- Prüfen Sie die Service-Quotas für Recheninstanzen, Load Balancer und öffentliche IP-Adressen in dieser Region.
- Definieren Sie das Zugriffsmodell: eine eingeschränkte Rolle, die der Anbieter übernehmen kann, mit aktivierter Protokollierung und einem dokumentierten Weg, sie zu widerrufen.
- Entscheiden Sie über DNS für die Broker-Endpunkte und wer die Einträge verwaltet.
- Vereinbaren Sie Wartungsfenster und wie Sie vor Upgrades benachrichtigt werden.
- Richten Sie Kosten-Tags ein, damit die Broker-Infrastruktur in Ihren Berichten sichtbar ist.
Clients vor der Migration validieren
Während die BYOC-Umgebung vorbereitet wird, können Sie das Client-Verhalten gegen den öffentlichen MQTT-Broker, der nur für Tests und Prototypen gedacht ist, und anschließend gegen einen kostenlosen privaten Broker testen. Dieses Python-Beispiel nutzt paho-mqtt 2.x und verbindet sich über TLS. Ersetzen Sie Host und Zugangsdaten später durch Ihren BYOC-Endpunkt; sonst ändert sich nichts.
import ssl
import paho.mqtt.client as mqtt
HOST = "broker.connectmq.com" # durch Ihren BYOC-Endpunkt ersetzen
PORT = 8883
CLIENT_ID = "YOUR_CLIENT_ID"
def on_connect(client, userdata, flags, reason_code, properties):
print("Connected:", reason_code)
client.subscribe("connectmq/demo/byoc-7c21/#", qos=1)
client.publish("connectmq/demo/byoc-7c21/status", "online", qos=1, retain=True)
def on_message(client, userdata, msg):
print(msg.topic, msg.payload.decode())
client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id=CLIENT_ID,
protocol=mqtt.MQTTv5)
# Für einen privaten Broker auskommentieren:
# client.username_pw_set("YOUR_USERNAME", "YOUR_PASSWORD")
client.tls_set(cert_reqs=ssl.CERT_REQUIRED)
client.on_connect = on_connect
client.on_message = on_message
client.connect(HOST, PORT, keepalive=60)
client.loop_forever()
Führen Sie dasselbe Skript gegen jede Umgebung aus und halten Sie die Topic-Struktur identisch. Sobald der BYOC-Broker live ist, ist der Wechsel eine reine Konfigurationsänderung.
Häufige Stolperfallen
- Zu weitreichende Zugriffe für den Betreiber. Gewähren Sie nur, was der Broker braucht, und protokollieren Sie jede Aktion.
- Vergessene Egress-Kosten. Befinden sich Geräte oder Consumer in anderen Regionen oder Clouds, erscheinen Datentransfergebühren auf Ihrer Rechnung.
- Blockierte Upgrades. Richtlinien, die den Betreiber am Patchen hindern, schaffen dasselbe Risiko wie ein ungepflegter selbst gehosteter Broker.
- Keine Staging-Umgebung. Halten Sie einen kleinen Nicht-Produktions-Broker vor, zum Beispiel im kostenlosen Serverless-Tarif, für Firmware- und Integrationstests.
Starten Sie mit ConnectMQ
Sie können die Plattform noch heute im kostenlosen Serverless-Tarif ohne Kreditkarte unter app.connectmq.com erkunden. Entwickeln und testen Sie Ihre Geräte dort und sprechen Sie dann mit dem Team über den Wechsel zu BYOC, wenn Ihre Anforderungen an die Datenkontrolle es verlangen. Einen breiteren Überblick über die Hosting-Optionen bietet der Leitfaden zum Cloud-MQTT-Broker, oder vergleichen Sie die Tarife in der Übersicht zum verwalteten MQTT-Broker.
Häufig gestellte Fragen
Ist ein BYOC-MQTT-Broker dasselbe wie Self-Hosting?
Nein. Die Infrastruktur liegt in Ihrem Konto, aber der Anbieter installiert, aktualisiert und überwacht den Broker. Beim Self-Hosting erledigt Ihr eigenes Team all das.
Brauchen meine Geräte für BYOC eine andere Firmware?
Nicht, wenn der Broker Standard-MQTT spricht. Bei ConnectMQ nutzt BYOC dieselben Protokolle und Ports wie die anderen Tarife, Sie ändern also nur Hostname und Zugangsdaten.
Wer bezahlt bei BYOC die Cloud-Infrastruktur?
Die Infrastruktur erscheint auf Ihrer eigenen Cloud-Rechnung, der Verwaltungsdienst wird vom Anbieter separat abgerechnet. Klären Sie die genaue Regelung mit Ihrem Anbieter.
Wann ist BYOC überdimensioniert?
Wenn keine Richtlinie verlangt, dass Daten in Ihrem eigenen Konto bleiben, ist ein geteilter oder dedizierter verwalteter MQTT-Broker schneller eingerichtet und einfacher zu betreiben.
