AWS-IoT-Core-Alternative: Wann ein Standard-MQTT-Broker einfacher ist

Eine AWS-IoT-Core-Alternative ist sinnvoll, wenn Ihr Projekt eher einen Standard-MQTT-Broker als eine cloudspezifische IoT-Plattform braucht. Dieser Leitfaden erklärt, was AWS IoT Core bietet, welche Unterschiede Sie bewerten sollten, wie sich die Authentifizierungsmodelle vergleichen lassen und wann ein standardbasierter verwalteter MQTT-Broker der einfachere Weg ist, inklusive Code, mit dem Sie beide testen können.

Worin AWS IoT Core stark ist

AWS IoT Core ist ein Managed Service, der Geräte mit der AWS-Cloud verbindet. Über einen MQTT-Endpunkt hinaus bietet er Geräteregistrierung und -identität, Authentifizierung auf Basis von X.509-Zertifikaten, feingranulare IoT-Policies, Device Shadows und eine Rules Engine, die Nachrichten an andere AWS-Dienste weiterleitet. Wenn Ihr Backend bereits in AWS läuft und Gerätedaten mit wenig Verbindungscode in AWS-Dienste fließen sollen, ist diese Integration der Hauptgrund für die Wahl.

In diesem Artikel geht es nicht darum, ob AWS IoT Core gut ist, sondern ob er zum Zuschnitt Ihres Projekts passt. AWS aktualisiert den Dienst regelmäßig; prüfen Sie daher jeden einzelnen Punkt anhand des aktuellen AWS IoT Core Developer Guide.

Wann Teams nach einer Alternative suchen

Die Gründe lassen sich meist in einige Gruppen einteilen:

• Sie brauchen einen schlichten Broker. Es geht um Messaging zwischen Gerät und App, ein Dashboard oder einen industriellen Daten-Hub wie einen Unified Namespace (UNS) für Industrie-4.0-Projekte, nicht um eine AWS-Daten-Pipeline.
• Ihr Backend läuft nicht auf AWS. Es läuft in einer anderen Cloud, On-Premises oder gemischt.
• Aufwand beim Onboarding. Zertifikats-Provisioning pro Gerät ist starke Sicherheit, bringt aber zusätzliche Schritte für Prototypen, Schulungen und kleine Flotten.
• Bedenken zur Portabilität. Geräte sollen durch Ändern weniger Einstellungen zwischen Brokern wechseln können.
• Datensouveränität und Regulierung. Unternehmen in Deutschland, Österreich und der Schweiz prüfen im Rahmen von DSGVO, NIS2 oder IEC 62443 genau, wo Daten verarbeitet werden und wie abhängig sie von einem Anbieter sind. Klären Sie Hosting-Region und Vertragsbedingungen bei jedem Anbieter, den Sie vergleichen.
• Planbare Preismodelle. Manche Teams bevorzugen tarifbasierte Preise gegenüber nutzungsbasierter Abrechnung. Was günstiger ist, hängt ganz von Ihrer Last ab.

Was Sie bewerten sollten: AWS IoT Core vs. Standard-MQTT-Broker

AWS veröffentlicht eine Seite, die beschreibt, wo die eigene MQTT-Implementierung von der MQTT-Spezifikation abweicht. Lesen Sie sie zusammen mit Ihren Anforderungen. Die Tabelle listet auf, was zu prüfen ist, statt aktuelle Details zu behaupten.

In den letzten beiden Zeilen bietet AWS IoT Core mehr integrierte Funktionen. Sind diese zentral für Ihr Design, passt er womöglich besser.

Der Unterschied im Authentifizierungsmodell

Das ist oft der größte praktische Unterschied.

Ein typisches AWS-IoT-Core-Gerät besitzt ein Client-Zertifikat samt privatem Schlüssel sowie die Amazon Root CA und verbindet sich per Mutual TLS. An das Zertifikat angehängte Policies steuern, worin es veröffentlichen und was es abonnieren darf. Das ist ein starkes Modell, das im großen Maßstab einen Provisioning-Prozess erfordert.

Ein Standard-Broker wie ConnectMQ nutzt serverseitiges TLS mit Benutzername, Passwort und Client-ID, die in einem Portal ausgegeben werden. Geräte prüfen das Let's-Encrypt-Zertifikat des Brokers über den System-CA-Speicher, und die Client-ID ist an die ausgegebenen Zugangsdaten gebunden. Der Einstieg ist einfacher; Ihre Verantwortung besteht darin, Zugangsdaten sicher auf den Geräten zu speichern.

Keines der Modelle ist pauschal besser. Bewerten Sie, welches Modell Ihre Flottengröße, Ihre Sicherheitsanforderungen und Ihr Fertigungsprozess tragen können.

Gerätecode schreiben, der mit beiden funktioniert

Der beste Weg, Lock-in zu vermeiden, ist die Trennung von Verbindungsdetails und Anwendungslogik. Dieses MQTT.js-v5-Beispiel verbindet sich entweder mit einem Zertifikat (im Stil von AWS IoT Core) oder mit Benutzername und Passwort (Standard-Broker), während der restliche Code identisch bleibt:

// npm install mqtt
const fs = require("fs");
const mqtt = require("mqtt");

const mode = process.env.BROKER_MODE || "standard"; // "standard" oder "certificate"

const options = {
  clientId: process.env.MQTT_CLIENT_ID || "YOUR_CLIENT_ID",
  protocolVersion: 5,
  reconnectPeriod: 5000,
};

let url;
if (mode === "certificate") {
  url = `mqtts://${process.env.MQTT_ENDPOINT}:8883`;
  options.key = fs.readFileSync("device.private.key");
  options.cert = fs.readFileSync("device.cert.pem");
  options.ca = fs.readFileSync("root-ca.pem");
} else {
  url = "mqtts://broker.connectmq.com:8883";
  options.username = process.env.MQTT_USERNAME || "YOUR_USERNAME";
  options.password = process.env.MQTT_PASSWORD || "YOUR_PASSWORD";
}

const client = mqtt.connect(url, options);
const topic = "site1/area1/pump7/telemetry";

client.on("connect", () => {
  console.log("Connected in", mode, "mode");
  setInterval(() => {
    const reading = { pressure: 2.4 + Math.random() * 0.2, ts: Date.now() };
    client.publish(topic, JSON.stringify(reading), { qos: 1 });
  }, 5000);
});

client.on("error", (err) => console.error("MQTT error:", err.message));

Halten Sie Topic-Namen frei von anbieterspezifischen Präfixen und vermeiden Sie in der Geräte-Firmware Abhängigkeiten von Funktionen, die nur ein Anbieter hat. Dann ist ein Anbieterwechsel eine reine Konfigurationsänderung. Das Beispiel-Topic site1/area1/pump7/telemetry folgt bereits der ISA-95-Logik; in einem UNS wird daraus die vollständige Hierarchie, etwa acme/werk-stuttgart/montage/linie-1/pumpe-7/telemetry, die auf jedem Standard-Broker identisch funktioniert. Der Artikel zum MQTT-Vendor-Lock-in listet die Muster auf, auf die Sie achten sollten.

AWS-spezifische Funktionen ersetzen

Wenn Sie zu einem schlichten Broker wechseln, planen Sie, wie Sie die genutzten Funktionen abdecken:

1. Rules Engine. Betreiben Sie einen Subscriber-Dienst, einen Node-RED-Flow oder einen Telegraf-Agenten, der Topics liest und in Ihre Datenbank oder API schreibt.
2. Device Shadows. Veröffentlichen Sie gewünschten und gemeldeten Zustand auf Retained Topics wie site1/area1/pump7/state/reported und .../state/desired.
3. Flottenidentität. Stellen Sie pro Gerät einen Satz Zugangsdaten aus und führen Sie ein Inventar in Ihrem eigenen System.
4. Monitoring. Nutzen Sie das Verbindungsstatus-Topic des Brokers ($SYS/broker/connection/{clientId}/state bei ConnectMQ) und das Dashboard im Portal.

Ein risikoarmer Migrationspfad

Wenn Sie einige oder alle Geräte umziehen möchten, tun Sie es schrittweise statt in einer einzigen Umstellung:

1. Zuerst spiegeln. Betreiben Sie einen kleinen Bridge-Dienst, der ausgewählte Topics auf dem bestehenden Endpunkt abonniert und sie auf dem neuen Broker erneut veröffentlicht. Dashboards und neue Consumer können dann auf den neuen Broker umziehen, während die Geräte bleiben, wo sie sind.
2. Eine Gerätegruppe pilotieren. Flashen oder konfigurieren Sie eine kleine Charge von Geräten mit dem neuen Endpunkt und neuen Zugangsdaten. Beobachten Sie Reconnect-Verhalten, Nachrichtenraten und Payload-Größen im Vergleich zu den Limits des neuen Tarifs.
3. Integrationen umziehen. Ersetzen Sie jede Regel durch einen externen Subscriber oder Node-RED-Flow, ein Datenziel nach dem anderen, und vergleichen Sie die Ergebnisse parallel.
4. Die Flotte umstellen, und zwar in Wellen, wobei die alte Konfiguration für ein Rollback verfügbar bleibt, bis jede Welle stabil läuft.

Da beide Seiten MQTT sprechen, ist jeder Schritt umkehrbar. Genau deshalb sollte die Firmware frei von anbieterspezifischen Abhängigkeiten bleiben.

Eine Entscheidungs-Checkliste

• Liegt der Großteil Ihres Backends auf AWS und nutzen Sie die Rules Engine intensiv? Dann passt AWS IoT Core wahrscheinlich besser.
• Brauchen Sie einen neutralen Broker für Geräte, Apps und On-Premises-Systeme über Umgebungen hinweg? Dann ist ein Standard-Broker einfacher.
• Brauchen Sie QoS 2 oder bestimmte MQTT-5-Funktionen? Prüfen Sie die aktuelle Unterstützung auf beiden Seiten.
• Ist Zertifikats-Provisioning pro Gerät für Sie heute praktikabel?
• Kann Ihr Team die Integrationen betreiben, die ein schlanker Broker externen Tools überlässt?

Einen standardbasierten Broker testen

Sie können die Alternative bewerten, ohne irgendetwas zu migrieren. Erstellen Sie einen kostenlosen Serverless-Broker ohne Kreditkarte, führen Sie das obige Skript im Standardmodus aus und prüfen Sie den Datenverkehr im Live-Topic-Explorer. Für mehr Kontext lesen Sie den Leitfaden zum Cloud-MQTT-Broker, vergleichen Sie mit der Azure-IoT-Hub-Alternative und sehen Sie, wie sich ein verwalteter MQTT-Broker von einer IoT-Plattform unterscheidet. Mehr erfahren Sie auf connectmq.com.

Häufig gestellte Fragen

Können für AWS IoT Core gebaute Geräte sich mit einem anderen MQTT-Broker verbinden?

Ja, sofern sie Standard-MQTT verwenden. In der Regel ändern Sie den Endpunkt, wechseln von Zertifikatsauthentifizierung zur Methode des neuen Brokers und entfernen jede AWS-spezifische Topic-Nutzung.

Ersetzt ein Standard-Broker die AWS IoT Rules Engine?

Nicht von allein. Sie ergänzen einen externen Subscriber, Node-RED oder Telegraf zur Weiterleitung der Daten, wodurch jeder Baustein austauschbar bleibt.

Ist AWS IoT Core sicherer als ein Broker mit Benutzername und Passwort?

Mutual TLS mit Zertifikaten pro Gerät ist ein starkes Modell. Ein Broker mit TLS und eindeutigen Zugangsdaten pro Gerät ist ebenfalls solide, wenn die Zugangsdaten korrekt gespeichert und rotiert werden.

Wo sollte ich die Limits von AWS IoT Core prüfen?

Nutzen Sie den aktuellen AWS IoT Core Developer Guide und die Seiten zu den Service Quotas, da sich Limits und unterstützte Funktionen ändern.