Ein Sensor auf einer abgelegenen Anlage muss Messwerte sicher übertragen, Befehle empfangen und nach einer unterbrochenen Verbindung zuverlässig weiterarbeiten. AWS IoT Core stellt dafür die verwaltete Cloud-Infrastruktur bereit und verbindet Geräte über MQTT, HTTPS oder LoRaWAN mit Anwendungen und weiteren AWS-Diensten. Ich zeige, wie die Plattform aufgebaut ist, welche Rolle Geräteschatten und Regeln spielen, worauf es bei Sicherheit und Kosten ankommt und wann die Lösung auch für verteilte Projekte in Regionen wie Timor-Leste sinnvoll ist.
Die wichtigsten Punkte für den Einsatz vernetzter Geräte
- Verbindung: Geräte kommunizieren über MQTT, MQTT über WebSocket Secure, HTTPS oder LoRaWAN.
- Sicherheit: TLS sowie individuelle X.509-Zertifikate und präzise IoT-Richtlinien schützen Geräte und Daten.
- Gerätezustand: Device Shadows speichern den gewünschten und den zuletzt gemeldeten Zustand auch während einer Offline-Phase.
- Datenverarbeitung: Die Rules Engine filtert Nachrichten und leitet sie an Lambda, S3, DynamoDB, Kinesis oder andere Ziele weiter.
- Kosten: Abgerechnet werden unter anderem Konnektivität, Nachrichten, Schatten, Registry und Regelverarbeitung getrennt voneinander.
Was AWS IoT Core in einem IoT-System übernimmt
Die Plattform ist kein einzelnes Gerät und auch keine fertige IoT-Anwendung. Sie bildet vielmehr die verwaltete Kommunikationsschicht zwischen Sensoren, Aktoren, Gateways und Cloud-Anwendungen. AWS übernimmt dabei den Betrieb der zentralen IoT-Endpunkte, während das Entwicklungsteam Geräteidentitäten, Berechtigungen, Nachrichtenformate und Geschäftslogik festlegt.
Im Zentrum stehen das Device Gateway und der Message Broker. Das Gateway nimmt sichere Verbindungen entgegen, der Broker verteilt veröffentlichte Nachrichten an berechtigte Abonnenten. Ein Temperatursensor kann beispielsweise Messwerte auf einem MQTT-Topic veröffentlichen, während eine Anwendung oder ein Alarmdienst dieses Topic abonniert.
Die wichtigsten Bausteine lassen sich so einordnen:
| Baustein | Aufgabe | Praktischer Nutzen |
|---|---|---|
| Device Gateway | Verwaltet die sichere Verbindung von Geräten | Sensoren und Aktoren erreichen die Cloud ohne eigenen Brokerbetrieb |
| Message Broker | Verteilt Publish- und Subscribe-Nachrichten | Geräte und Anwendungen können bidirektional kommunizieren |
| Thing Registry | Speichert Geräteidentitäten und Metadaten | Geräte lassen sich gruppieren, suchen und verwalten |
| Device Shadow | Speichert den logischen Gerätezustand | Anwendungen können auch mit zeitweise offline befindlichen Geräten arbeiten |
| Rules Engine | Filtert, transformiert und routet Nachrichten | Messwerte gelangen automatisiert in Speicher, Datenbanken oder Funktionen |
| IoT Jobs | Steuert Aufgaben für Geräteflotten | Firmware-Updates, Zertifikatswechsel und Wartungsaufträge werden planbar |
Ich halte diese Trennung für entscheidend. Viele Projekte scheitern nicht an der ersten MQTT-Verbindung, sondern daran, dass später Identitäten, Zustände, Updates und Datenflüsse ungeordnet wachsen. Wer diese Bausteine von Anfang an sauber trennt, reduziert spätere Umbauten deutlich.
Welche Protokolle und Verbindungen sinnvoll sind
Für die meisten dauerhaft verbundenen Geräte ist MQTT über TLS die naheliegende Wahl. Das Protokoll ist leichtgewichtig, unterstützt Publish und Subscribe und eignet sich deshalb für Sensoren mit begrenzter Rechenleistung oder instabiler Verbindung. AWS IoT Core unterstützt MQTT 3.1.1 und MQTT 5 mit einigen AWS-spezifischen Besonderheiten.
MQTT kennt die Quality-of-Service-Stufen QoS 0 und QoS 1. QoS 0 versendet eine Nachricht höchstens einmal und verursacht weniger Overhead. QoS 1 bestätigt die Zustellung mindestens einmal, weshalb eine Nachricht beim Wiederholen doppelt ankommen kann. Anwendungen müssen solche Duplikate daher über eine Nachrichten-ID oder einen Zeitstempel erkennen.
| Verfahren | Geeignet für | Wichtige Grenze |
|---|---|---|
| MQTT über TLS | Dauerhafte Telemetrie und Steuerbefehle | Das Gerät braucht eine stabile, wiederaufbaubare Verbindung |
| MQTT über WebSocket Secure | Webanwendungen und Clients hinter restriktiven Firewalls | Die Anwendung muss WebSocket- und AWS-Signaturverfahren korrekt umsetzen |
| HTTPS | Einzelne Uploads, einfache Geräte und seltene Statusmeldungen | Publish ist möglich, ein dauerhaftes Subscribe-Modell jedoch nicht |
| LoRaWAN | Weit verteilte, stromsparende Sensoren mit geringer Datenmenge | Bandbreite und Nachrichtenvolumen sind stark begrenzt |
Für MQTT-Verbindungen werden häufig die Ports 8883 oder 443 verwendet, während HTTPS typischerweise über 443 oder 8443 läuft. In abgelegenen Gebieten mit Mobilfunk- oder Satellitenanbindung zählt jedoch nicht nur der Port. Entscheidend sind Wiederverbindung, lokale Pufferung, Zeitüberschreitungen und ein sparsames Nachrichtenformat.
Bei einem Sensor in Timor-Leste würde ich Messwerte nicht im Sekundentakt senden, wenn sich die Temperatur nur langsam verändert. Ein Intervall von beispielsweise 60 Sekunden oder eine ereignisbasierte Übertragung spart Energie und senkt das Nachrichtenvolumen. Für sicherheitskritische Alarme gilt natürlich eine andere Priorität als für historische Klimadaten.
Wie Sicherheit bei Geräten wirklich funktioniert
Jedes Gerät oder jeder Client benötigt eine Identität und eine Berechtigung. In klassischen Geräteflotten geschieht die Authentifizierung meist über ein individuelles X.509-Zertifikat, das zusammen mit dem privaten Schlüssel im Gerät gespeichert wird. Die Kommunikation wird mit TLS 1.2 oder TLS 1.3 verschlüsselt.
Das Zertifikat allein erlaubt noch keinen beliebigen Zugriff. Eine AWS-IoT-Richtlinie legt fest, ob ein Gerät verbinden, auf bestimmte Topics veröffentlichen oder Nachrichten abonnieren darf. Ich empfehle, die Rechte strikt an die Geräteidentität zu binden, statt einem gesamten Gerätetyp pauschal Zugriff auf alle Topics zu geben.
- Eigene Identität pro Gerät: kein gemeinsames Zertifikat für eine ganze Flotte.
- Minimale Rechte: ein Sensor darf nur seine eigenen Messwerte veröffentlichen.
- Getrennte Topics: Telemetrie, Befehle und Statusmeldungen sollten nicht unkontrolliert vermischt werden.
- Sicherer Schlüsselspeicher: private Schlüssel gehören möglichst in ein Secure Element oder einen vergleichbaren geschützten Speicher.
- Rotation und Sperrung: verlorene oder kompromittierte Geräte müssen schnell deaktiviert werden können.
Ein häufiger Fehler ist die großzügige Richtlinie mit Wildcards wie iot:*. Sie vereinfacht den ersten Test, macht einen später kompromittierten Sensor aber unnötig gefährlich. Besser ist, die Berechtigungen bereits im Prototypen auf konkrete Aktionen und Ressourcen zu beschränken.
Die Verantwortung bleibt geteilt. AWS schützt die Cloud-Infrastruktur, aber das Team muss Zertifikate, private Schlüssel, Firmware, Identitäten und Richtlinien sicher betreiben. Gerade bei Geräten, die jahrelang draußen stehen, ist Lebenszyklusmanagement wichtiger als eine einmalige sichere Verbindung.
Warum Device Shadows bei instabiler Verbindung helfen
Ein Device Shadow ist ein cloudbasiertes JSON-Dokument mit dem logischen Zustand eines Geräts. Typischerweise enthält es einen desired-Zustand für gewünschte Änderungen und einen reported-Zustand für das, was das Gerät tatsächlich meldet. Die Differenz zwischen beiden wird als Delta sichtbar.
Das ist besonders nützlich, wenn Geräte nicht ständig online sind. Eine Leitstelle kann etwa die gewünschte Ventilstellung ändern, obwohl ein Gateway gerade keine Mobilfunkverbindung hat. Sobald das Gerät zurückkehrt, liest es den aktuellen Zielzustand, führt die Änderung aus und meldet den erreichten Zustand zurück.
Ein einfaches Beispiel sieht konzeptionell so aus:
{
"state": {
"desired": {
"mode": "eco"
},
"reported": {
"mode": "normal"
}
}
}Wichtig ist die Rollenverteilung. Anwendungen schreiben normalerweise in desired, Geräte in reported. Werden beide Bereiche wahllos von mehreren Komponenten verändert, entstehen schwer nachvollziehbare Zustandskonflikte.
Shadows ersetzen keine Zeitreihendatenbank. Sie eignen sich für den aktuellen Zustand, etwa Betriebsmodus, Solltemperatur oder Firmware-Version. Für Millionen historischer Messwerte sind Dienste wie S3, Timestream oder eine andere passende Datenplattform besser geeignet. Diese Unterscheidung spart Kosten und hält die Gerätekommunikation übersichtlich.
Wie die Rules Engine aus Nachrichten Anwendungen macht
Eine eingehende MQTT-Nachricht ist zunächst nur ein Datenpaket. Die Rules Engine kann daraus einen nutzbaren Prozess machen. Eine Regel filtert Nachrichten mit einer SQL-ähnlichen Syntax, verändert Felder und leitet das Ergebnis an andere AWS-Dienste oder Geräte weiter.
Ein typischer Datenfluss für eine verteilte Messstation sieht so aus:
- Der Sensor veröffentlicht Temperatur, Luftfeuchtigkeit und Batteriestand.
- Eine Regel prüft, ob das Topic und das JSON-Format gültig sind.
- Normale Messwerte werden zur Speicherung weitergeleitet.
- Ein ungewöhnlich hoher Wert löst eine Lambda-Funktion oder Benachrichtigung aus.
- Der letzte Gerätezustand wird zusätzlich im Device Shadow aktualisiert.
Zu den möglichen Zielen gehören unter anderem Lambda, DynamoDB, S3, Kinesis, SNS und SQS. AWS IoT Rules kann bis zu 10 Aktionen pro Regel ausführen. Trotzdem würde ich nicht jede denkbare Verarbeitung in eine einzige Regel packen. Kleine Regeln mit klarer Aufgabe lassen sich besser testen, überwachen und bei Fehlern zurückrollen.
Auch die Topic-Struktur verdient Aufmerksamkeit. Ein Schema wie site/device-type/device-id/telemetry ist verständlicher als eine lose Sammlung kurzer Bezeichnungen. Geräte-ID, Standort und Datentyp sollten möglichst eindeutig sein, weil diese Informationen später für Berechtigungen, Filter und Auswertungen gebraucht werden.
Für Wartung und Updates kommt IoT Jobs hinzu. Damit lassen sich Aufgaben an einzelne Geräte oder Gruppen verteilen, beispielsweise Firmware-Updates, Zertifikatswechsel oder Neustarts. Bei Geräten mit teurer oder unzuverlässiger Verbindung sollte ein Auftrag fortsetzbar sein und einen klaren Fehlerstatus zurückmelden.
Was AWS IoT Core kostet und wann die Lösung passt
Die Abrechnung erfolgt nutzungsabhängig. Es gibt keine verpflichtende monatliche Grundgebühr für den Dienst, aber mehrere getrennte Kostenbereiche. Dazu gehören Verbindungen, Nachrichten, Device Shadows, Registry-Nutzung und Rules-Engine-Verarbeitung. Zusätzlich entstehen Kosten für die AWS-Zieldienste, etwa Speicherung, Datenbanken oder Lambda-Aufrufe.
Die genaue Summe hängt stärker vom Nachrichtenverhalten als von der reinen Gerätezahl ab. Ein Beispiel macht das sichtbar: 100 Sensoren, die jede Minute eine Nachricht senden, erzeugen bereits rund 4,32 Millionen Nachrichten pro Monat, bevor Wiederholungen, Statusmeldungen, Schattenaktualisierungen und Regelaktionen berücksichtigt werden.
| Kostenfaktor | Was den Verbrauch erhöht | Wie ich ihn begrenzen würde |
|---|---|---|
| Nachrichten | Zu kurze Intervalle, große Payloads und unnötige Wiederholungen | Ereignisbasierte Übertragung, kompakte JSON-Strukturen und sinnvolle QoS-Wahl |
| Verbindungen | Häufiges Trennen und Neuverbinden vieler Geräte | Stabile Sessions und exponentielles Backoff bei Wiederholungen |
| Device Shadow | Häufige Zustandsupdates ohne echte Änderung | Nur bei Zustandsänderung aktualisieren |
| Rules Engine | Viele Regelprüfungen und mehrere Aktionen pro Nachricht | Früh filtern und Regeln nach Geschäftszweck trennen |
| Folgedienste | Große Datenmengen in Speicher-, Analyse- oder Streamingdiensten | Aufbewahrungsfristen, Aggregation und passende Speicherklassen festlegen |
Für einen kleinen Prototypen ist die Plattform bequem, weil kein eigener MQTT-Broker betrieben werden muss. Für ein sehr kleines, lokales System mit wenigen Geräten kann ein selbst verwalteter Broker jedoch günstiger erscheinen. Dann übernimmt das Team allerdings Patchen, Hochverfügbarkeit, Zertifikatsverwaltung, Monitoring und Skalierung selbst. Genau diese Betriebskosten werden am Anfang oft unterschätzt.
Ich würde die Lösung besonders dann einsetzen, wenn eine Flotte wachsen soll, Geräte sicher mit Cloud-Diensten kommunizieren müssen oder Remote-Wartung wichtig ist. Weniger passend ist sie, wenn sämtliche Daten lokal bleiben müssen, die Verbindung niemals eine Cloud erreichen darf oder die Anwendung nur aus zwei lokal vernetzten Sensoren besteht.
Ein belastbarer Start für ein neues IoT-Projekt
Der beste Einstieg ist ein kleiner, realitätsnaher Prototyp mit einem Gerät, einem Topic und einem klaren Messwert. Dabei sollte nicht nur der Erfolgsfall getestet werden. Ebenso wichtig sind Stromausfall, Netzwerkunterbrechung, doppelte Nachrichten, falsche Zertifikate und ein Neustart während eines Updates.
- Gerätemodell definieren: Geräte-ID, Standort, Firmware-Version und Messgrößen festlegen.
- Topic-Struktur planen: Telemetrie, Befehle, Status und Fehler getrennt benennen.
- Authentifizierung einrichten: pro Gerät ein Zertifikat und eine minimale Richtlinie verwenden.
- Nachrichtenfluss testen: MQTT-Nachrichten senden, empfangen und über Regeln weiterleiten.
- Offline-Verhalten bauen: lokal puffern, Wiederverbindung implementieren und Shadows gezielt einsetzen.
- Monitoring ergänzen: Verbindungsfehler, abgelehnte Nachrichten, Zertifikatsabläufe und Regelaktionen überwachen.
- Flottenbetrieb vorbereiten: Gruppen, Jobs, Update-Strategie und Sperrprozess für verlorene Geräte definieren.
Für die Geräteentwicklung helfen AWS IoT Device SDKs, weil sie Protokoll- und Verbindungsdetails abnehmen. Vor dem Rollout sollte außerdem ein automatisierter Verbindungstest stehen. Ich würde ein Gerät erst dann in größerer Zahl ausrollen, wenn ein Ausfall der Cloud-Verbindung nicht zu einem gefährlichen Zustand führt.
Für Projekte mit wechselnder Konnektivität, etwa bei Umweltstationen, Verkehrs- oder Telekommunikationsinfrastruktur, ist die wichtigste Designentscheidung oft nicht der Cloud-Dienst selbst. Es ist die Frage, welche Funktionen lokal weiterlaufen müssen. Ein Sensor darf Messwerte zwischenspeichern, ein Aktor sollte Sicherheitsgrenzen jedoch unabhängig von der Cloud durchsetzen.
Die richtige Entscheidung hängt am Betriebsmodell
AWS IoT Core ist stark, wenn sichere Gerätekommunikation, Gerätezustände, Regeln und Flottenwartung zusammengehören. Die Plattform nimmt viel Infrastrukturarbeit ab, verlangt aber saubere Identitäten, disziplinierte Topic-Strukturen und eine realistische Kostenplanung.
Mein praktischer Rat lautet, zuerst den Datenfluss und das Offline-Verhalten zu entwerfen und erst danach die einzelnen AWS-Dienste auszuwählen. Wer pro Gerät eine klare Identität vergibt, Nachrichten sparsam plant und Cloud- sowie lokale Funktionen sinnvoll trennt, erhält ein IoT-System, das auch unter schwierigen Netzwerkbedingungen zuverlässig wachsen kann.
