Die wichtigsten Punkte für den praktischen Einsatz
- Die Plattform ist kein einzelnes Produkt, sondern ein Stack aus Messaging, Geräteverwaltung, Edge-Funktionen und Security.
- Bei schwankender Konnektivität ist lokale Verarbeitung oft wichtiger als reine Cloud-Anbindung.
- Greengrass V1 sollte man nicht mehr neu einplanen, weil der Support am 1. Juni 2026 endete.
- IoT Events wurde am 20. Mai 2026 abgekündigt; neue Architekturen sollten darauf keine Abhängigkeit mehr bauen.
- Im industriellen Umfeld liefern Edge-Filterung und strukturierte Maschinendaten oft den größten Nutzen.
Was die Plattform für vernetzte Geräte tatsächlich löst
Im Kern geht es nicht um ein einzelnes Tool, sondern um eine Kette: Gerät identifizieren, Daten sicher senden, Regeln anwenden, Geräte verwalten und bei Bedarf lokal weiterarbeiten. Für mich ist das der Unterschied zwischen einer Bastellösung und einem belastbaren System für Flotten mit Dutzenden oder Tausenden Endpunkten. Die Plattform ist deshalb besonders interessant, wenn Sensordaten nicht nur gesammelt, sondern auch verteilt, aktualisiert und überwacht werden sollen.
Das Kommunikationsmodell basiert vor allem auf Publish/Subscribe. Geräte senden Nachrichten an Topics, andere Komponenten lesen sie wieder aus, wenn sie berechtigt sind. Ein Sensor muss dadurch nicht wissen, welche Anwendung die Daten später verarbeitet. Genau das macht solche Architekturen in Netzen mit schwankender Anbindung oder vielen Standorten deutlich robuster.
Wer IoT nur als Datenpipeline betrachtet, unterschätzt den Betrieb. In der Praxis geht es fast immer auch um Zertifikate, Rollouts, Fehlersuche, Gerätegruppen und die Frage, was passiert, wenn ein Standort kurz offline ist. Genau an dieser Stelle trennt sich eine Cloud-Demo von einem ernsthaften IoT-System.
Die nächste Frage ist deshalb nicht „kann es Nachrichten empfangen?“, sondern: Welche Bausteine übernehmen welche Aufgabe, und wo muss ich die Logik besser am Rand als in der Cloud halten?
So greifen die Bausteine ineinander
Ich zerlege den Stack gern in fünf Rollen. Diese Trennung hilft, weil man damit Architektur, Security und Betrieb sauberer plant und nicht alles in einen großen, schwer wartbaren Block presst.
| Baustein | Wofür er da ist | Wann er besonders wichtig wird |
|---|---|---|
| Core-Ebene | Verbindet Geräte sicher mit der Cloud, verarbeitet MQTT- und MQTT-over-WSS-Nachrichten und routet Daten an nachgelagerte Systeme. | Wenn Geräte direkt in die Cloud sprechen sollen und ein klarer Message-Bus gebraucht wird. |
| Gerätemanagement | Inventar, Gruppen, Firmware-Updates und Fernwartung über den gesamten Lebenszyklus. | Wenn aus einem Pilotprojekt eine Flotte wird und Versionen auseinanderlaufen. |
| Greengrass V2 | Lokale Verarbeitung, Zwischenspeicherung, Messaging und Ausführung von Logik am Edge. | Wenn Latenz, Offline-Phasen oder teure Bandbreite eine Rolle spielen. |
| Device Defender | Prüft Sicherheitskonfigurationen und überwacht Geräte auf auffälliges Verhalten. | Wenn Security nicht nur dokumentiert, sondern messbar überwacht werden soll. |
| SiteWise | Strukturiert, speichert und überwacht industrielle Maschinendaten. | Wenn Produktions- oder Anlagenwerte im Mittelpunkt stehen und nicht nur rohe Telemetrie. |
Ich würde die Architektur immer von unten nach oben denken: erst Identität und Verbindung, dann lokale Pufferung, dann zentrale Auswertung. Gerade in Netzen mit Firewalls oder streng kontrollierten Zugängen lohnt ein früher Test mit den relevanten Ports, vor allem 443 und 8883. An dieser Stelle scheitern Piloten oft nicht an der Plattform, sondern am Netzwerk.
Die eigentliche Stärke liegt also nicht in einem einzelnen Dienst, sondern darin, dass jeder Baustein eine klar begrenzte Aufgabe hat. Genau daraus entsteht eine Architektur, die sich später noch erweitern lässt, ohne komplett neu gebaut werden zu müssen.
Wann sie sich lohnt und wann nicht
Ich halte die Plattform dann für sinnvoll, wenn Geräte nicht nur Daten senden, sondern über ihren Lebenszyklus hinweg verwaltet werden müssen. Sobald ein System aus mehreren Standorten, wechselnden Firmware-Ständen und realen Betriebsstörungen besteht, wird die Frage nach Management und Security wichtiger als die reine Übertragung.
| Passt gut | Warum | Typisches Beispiel |
|---|---|---|
| Verteilte Sensornetze mit vielen Endgeräten | Geräteidentität, Gruppenverwaltung und Updates werden schnell zentral wichtig. | Gebäudeautomation, Messstellen, Smart Metering |
| Industrie, Energie, Logistik | Lokale Reaktion, Ausfallsicherheit und saubere Flottensteuerung bringen echten Mehrwert. | Maschinen, Anlagen, Lager, Fuhrpark |
| Standorte mit schlechter oder teurer Verbindung | Edge-Verarbeitung reduziert Datenverkehr und hält das System nutzbar, auch wenn der Uplink schwankt. | Außenstandorte, Inselregionen, abgelegene Infrastruktur |
| Viele Geräte, die regelmäßig aktualisiert werden müssen | OTA-Updates und Inventarpflege sparen manuelle Arbeit. | Flotten mit 100, 1.000 oder mehr Geräten |
| Eher nicht | Warum | Typisches Gegenbeispiel |
| Ein einzelner Sensor ohne Lebenszyklus | Der Betriebsaufwand kann den Nutzen schnell übersteigen. | Einfaches Laborprojekt oder lokaler Einzelsensor |
| Ein System ohne Fernwartung und ohne Skalierung | Dann braucht man oft nur eine schlichte Datenanbindung, aber keinen kompletten IoT-Stack. | Kleine Anlage mit einer festen Steuerung |
Bei 500 Maschinen würde ich selten jeden Rohwert im Sekundentakt in die Cloud schicken. Sinnvoller ist oft eine Verdichtung am Rand: Zustand, Alarm, Anomalie, Betriebsstunden. So bleiben Kosten, Latenz und Bandbreite beherrschbar, und die Cloud wird zum Auswertungs- statt zum Datenmüll-Layer. Genau an dieser Stelle tauchen dann die unterschätzten Kosten und Grenzen auf.
Kosten und Grenzen, die oft unterschätzt werden
Die Plattform wirkt auf den ersten Blick schlank, aber in IoT-Projekten wachsen die Kosten meist dort, wo viele kleine Einzeldinge zusammenkommen. Nicht die eine große Funktion ist teuer, sondern Nachrichtenmenge, Datenvolumen, Update-Management, Edge-Betrieb und die Pflege über Monate hinweg.
| Kostenfaktor | Warum er sich bemerkbar macht | Was ich dagegen tun würde |
|---|---|---|
| Nachrichtenvolumen | 1.000 Sensoren mit einem Sendeintervall von 10 Sekunden erzeugen pro Tag 8,64 Millionen Nachrichten. | Am Edge aggregieren, nur Deltas oder Alarme senden, unnötige Rohdaten vermeiden. |
| Datenübertragung | Große Payloads und häufige Übertragung treiben Netz- und Egress-Kosten hoch. | Daten verdichten, komprimieren und nach Relevanz trennen. |
| Gerätebetrieb | Zertifikate, Inventar, OTA-Updates und Support kosten dauerhaft Zeit. | Provisionierung automatisieren, Gerätegruppen bilden, Rollback-Strategien definieren. |
| Edge-Infrastruktur | Lokale Gateways oder Core-Geräte brauchen Wartung, Monitoring und Patchfenster. | Hardware standardisieren und Update-Zyklen fest einplanen. |
| Produktstatus | Greengrass V1 wurde am 1. Juni 2026 abgekündigt, IoT Events am 20. Mai 2026. | Neue Vorhaben nur auf aktuelle Bausteine aufsetzen und alte Abhängigkeiten vermeiden. |
Mein wichtigster Rat ist deshalb nüchtern: neue Projekte nicht auf auslaufenden Diensten aufbauen und die Datenrate früh realistisch rechnen. Wenn ein Netz streng gefiltert ist, teste außerdem vor dem Rollout, ob 443 und 8883 zuverlässig durchgehen und wie sich Zertifikatswechsel im Betrieb auswirken. Solche Details entscheiden oft mehr als die reine Serviceauswahl.
Wer diese Grenzen ignoriert, baut schnell ein System, das in der Demo sauber aussieht und im Alltag unnötig teuer oder fragil wird. Genau deshalb braucht eine gute Einführung nicht nur Architektur, sondern auch einen klaren Umsetzungsplan.
Wie ich ein IoT-System heute aufsetzen würde
-
Ich beginne mit den Gerätetypen und den Datenklassen. Erst sollte klar sein, welche Geräte überhaupt sprechen, wie oft sie senden und welche Daten geschäftskritisch sind. Ohne diese Einteilung wird später jedes Topic-Design unnötig chaotisch.
-
Danach definiere ich Identität und Vertrauen. Jedes Gerät braucht eine saubere Identität, Zertifikate und eine klare Zuordnung zu Gruppen oder Standorten. Das ist kein Sicherheitsdetail am Rand, sondern die Basis für alles Weitere.
-
Dann entscheide ich, was lokal bleibt und was in die Cloud geht. Wenn ein Standort offline sein kann, muss Pufferung am Edge funktionieren. Ich würde nie Rohdaten ungefiltert nach oben schicken, wenn 80 Prozent davon später ohnehin keine operative Wirkung haben.
-
Im nächsten Schritt plane ich Updates und Rollback sauber ein. Fernwartung ist nur dann nützlich, wenn ein fehlerhaftes Update auch wieder zurückgenommen werden kann. Für einen Pilot würde ich mit 50 bis 100 Geräten starten, nicht mit der kompletten Flotte.
-
Zum Schluss ergänze ich Monitoring und Security. Device Defender, Alarme und Betriebsmetriken gehören früh in den Prozess, nicht erst nach dem ersten Vorfall. Wer erst nach dem Rollout darüber nachdenkt, zahlt später mit Ausfällen und manueller Fehlersuche.
So entsteht ein System, das nicht nur Daten empfängt, sondern über seinen gesamten Lebenszyklus steuerbar bleibt. Der entscheidende Punkt ist dabei nie die Show im Dashboard, sondern die Frage, ob das System auch nach sechs Monaten und fünf Updates noch sauber läuft.
Worauf ich bei Projekten mit schwacher Konnektivität zuerst achte
In Regionen mit instabiler Verbindung ist die Cloud nie der erste, sondern der zweite Schritt. Erst muss das System lokal weiterarbeiten können: puffern, zusammenfassen, Alarme auslösen und nach dem Wiederaufbau der Verbindung geordnet synchronisieren. Genau hier liefert die Edge-Schicht den größten Nutzen.
Ich achte zuerst auf drei Dinge: Wie lange läuft das Gerät ohne Verbindung, welche Daten dürfen lokal bleiben und wie schnell lässt sich ein Gerät aus der Ferne neu versorgen, wenn ein Fehler auftritt. Wer diese drei Fragen sauber beantwortet, baut kein Demo-System, sondern eine belastbare Infrastruktur. Für Insel-, Rand- oder Bergregionen ist das oft der Unterschied zwischen einer netten Idee und einer echten Lösung.
Darum würde ich Amazons IoT-Bausteine nicht als Selbstzweck einsetzen, sondern als Werkzeugkasten für Systeme, bei denen Sicherheit, Fernwartung und Edge-Betrieb zusammengehören. Wenn diese Ebenen sauber geplant sind, trägt die Architektur auch dort, wo die Verbindung nicht perfekt ist.
