AWS IoT Events ist tot (EOL 20.05.2026): Detector Models zu ThingsBoard migrieren

WZ-IT führt thingshost weiter. Aktuelles Hosting ab 159,80 € netto/Monat; Einrichtung und Service Level gemäß Angebot. Frühere Paketpreise, Standortlisten und Kostenvergleiche in diesem datierten Artikel beschreiben das damalige Angebot, nicht die aktuellen WZ-IT-Konditionen. Aktuellen Leistungsumfang ansehen.

AWS hat AWS IoT Events offiziell zum 20. Mai 2026 abgekündigt. Nach diesem Datum sind Konsole und Ressourcen nicht mehr erreichbar, und es gibt kein automatisches Migrationswerkzeug. AWS liefert nur eine Bauanleitung, um die Logik Ihrer Detector Models aus Kinesis, Lambda, DynamoDB und EventBridge selbst nachzubauen, ausdrücklich als illustratives Beispiel, nicht als produktionsreifen Ersatz. Statt eine fragile, selbstgewartete Multi-Service-Pipeline im gleichen US-Cloud-Lock-in neu zu bauen, lässt sich die Zustands- und Alarmlogik deklarativ auf ThingsBoard 4.3 mit Alarm Rules 2.0 abbilden, souverän gehostet in Deutschland. Dieser Beitrag ist eine praktische Migrations-Roadmap weg vom End of Life.

Auch interessant: ThingsBoard vs. AWS IoT Core: Open Source gegen Amazon-Cloud · EU Data Act und IoT-Plattformen 2026

Kurzüberblick: AWS IoT Events EOL vs. ThingsBoard

Inhaltsverzeichnis

• AWS IoT Events: Was zum 20. Mai 2026 passiert
• Kein Migrationstool: Was AWS Ihnen stattdessen anbietet
• Der AWS-Eigenbau im Detail: Kinesis, Lambda, DynamoDB, EventBridge
• Das größere Bild: AWS räumt die IoT-Familie auf
• Detector Models verstehen: Zustände, Bedingungen, Timer
• Die ThingsBoard-Entsprechung: Alarm Rules 2.0 in 4.3
• Mapping-Tabelle: Detector-Model-Konzepte zu ThingsBoard
• SiteWise-Alarme migrieren: CloudWatch vs. ThingsBoard-Alarme
• Migrations-Roadmap: In sieben Schritten von IoT Events zu ThingsBoard
• Kosten und Datenhoheit: Selbstbau-Pipeline vs. Managed ThingsBoard
• Kein Rechtsrat: Was Sie vor dem 20. Mai 2026 entscheiden sollten
• Quellen

AWS IoT Events: Was zum 20. Mai 2026 passiert

Die Fakten sind unmissverständlich. AWS beendet den Support für AWS IoT Events zum 20. Mai 2026. Im offiziellen Developer Guide heißt es wörtlich, dass Sie nach dem 20. Mai 2026 keinen Zugriff mehr auf die AWS-IoT-Events-Konsole oder AWS-IoT-Events-Ressourcen haben werden [1]. Das ist kein Soft-Deprecation mit jahrelanger Schonfrist, sondern ein harter Stichtag.

Schon ein Jahr früher hat AWS die Tür für Neukunden geschlossen: Seit dem 20. Mai 2025 nimmt AWS IoT Events keine neuen Kunden mehr auf [1]. Bestandskunden, die vor diesem Datum eingerichtet waren, dürfen den Dienst bis zum endgültigen Support-Ende weiternutzen. Wenn Sie Detector Models heute produktiv betreiben, ist die Botschaft klar: Der 20. Mai 2026 ist Ihre Deadline für eine vollständige Migration.

Für die meisten Teams ist das mehr als ein technisches Detail. Detector Models steuern oft sicherheitsrelevante Zustandsmaschinen: Maschine läuft heiß, Tank läuft leer, Sensor meldet seit Minuten nichts mehr. Fällt diese Logik nach dem Stichtag weg, fehlt ein Stück Betriebssicherheit. Eine Migration ist deshalb nicht optional, sondern erzwungen.

Kein Migrationstool: Was AWS Ihnen stattdessen anbietet

Die unbequeme Wahrheit: Es gibt kein automatisches Migrationswerkzeug. AWS stellt stattdessen Migrationsleitfäden mit Codebeispielen bereit, betont aber selbst, dass diese Lösungen als illustrative Beispiele gedacht sind und nicht als produktionsreifer Ersatz für die AWS-IoT-Events-Funktionalität. Sie sollen Code, Workflow und die zugehörigen AWS-Ressourcen an Ihre geschäftlichen Anforderungen anpassen [1].

Lesen Sie diesen Satz noch einmal. AWS sagt Ihnen direkt, dass der gelieferte Code kein fertiges Produkt ist, sondern eine Skizze, die Sie selbst zu einer betriebssicheren, getesteten und gewarteten Lösung ausbauen müssen. Was vorher ein gemanagter Dienst mit visuellem Editor war, wird damit zu einem Software-Projekt in Ihrer Verantwortung, inklusive Fehlerbehandlung, Skalierung, Monitoring und Bereitschaft.

Genau hier lohnt der Vergleich mit einer fertigen Plattform. Wenn Sie die Logik ohnehin neu aufbauen müssen, stellt sich die Frage, ob Sie sie in einer selbstgewarteten AWS-Pipeline neu verdrahten oder in eine deklarative Alarm-Engine portieren, die diese Zustandslogik als Konfiguration statt als Code abbildet. Wir empfehlen, an dieser Stelle nicht reflexhaft im selben Ökosystem weiterzubauen, sondern die Migration als Gelegenheit zu nutzen.

Der AWS-Eigenbau im Detail: Kinesis, Lambda, DynamoDB, EventBridge

Der von AWS skizzierte Ersatz für Detector Models ist eine klassische Multi-Service-Pipeline [2]:

• IoT Core mit zwei MQTT-Topics: ein Topic für eingehende Daten (Input) und ein zweites für Ergebnisse (Output). Bisher genügte ein einziger logischer Eingang.
• Kinesis Data Streams: ersetzt die Input-Funktionalität von AWS IoT Events und puffert den Datenstrom [2].
• Evaluator-Lambda (NodeJS): ersetzt das Detector Model und liefert die anpassbare Zustandslogik als Code statt als visuellen Workflow [2]. Das Beispiel verwendet eine NodeJS-22.x-Runtime. Die gesamte Übergangslogik, die im Detector Model deklarativ war, schreiben Sie hier von Hand.
• DynamoDB-Tabelle: ersetzt die interne Zustandsverwaltung von AWS IoT Events und hält den aktuellen Gerätezustand vor [2].
• EventBridge Scheduler: bildet die Timer ab, die in Detector Models eingebaut waren.
• Eine IAM-Rolle: spannt alle diese Dienste mit den nötigen Berechtigungen zusammen.

Das ist kein Ersatz, das ist eine Architektur. Fünf Dienste, eine Code-Komponente und ein Berechtigungsgeflecht, die zusammenspielen müssen, damit aus einer Telemetrie ein korrekter Zustandsübergang wird. Jeder Dienst hat eigenes Pricing, eigene Limits und eigene Failure-Modi. Und die zentrale Logik liegt in einer Lambda, die AWS selbst ausdrücklich als illustratives Beispiel kennzeichnet [1]. Das ist die Definition einer fragilen, selbstgewarteten Pipeline.

Das größere Bild: AWS räumt die IoT-Familie auf

AWS IoT Events ist kein Einzelfall. Der Konzern dünnt seine IoT-Spezialdienste systematisch aus. Die vollständige Abbauliste 2026 mit allen Fristen und einem Strategie-Raster haben wir in einem eigenen Überblick dokumentiert.

AWS IoT Analytics hat sein Support-Ende bereits hinter sich: am 15. Dezember 2025 [7]. Auch hier endeten Konsole und Ressourcen mit dem Stichtag, und Neukunden wurden schon ab dem 24. Juli 2024 nicht mehr aufgenommen [7].

AWS IoT FleetWise ist ebenfalls betroffen, allerdings mit anderer Mechanik. Der Developer Guide stellt klar: FleetWise nimmt keine Neukunden mehr auf, Bestandskunden können den Dienst aber weiternutzen. AWS fügt keine neuen Funktionen mehr hinzu, liefert aber weiterhin Sicherheitsupdates [3]. Eine Abschaltfrist ist nicht genannt. In einer Service-Availability-Ankündigung vom 31. März 2026 hat AWS FleetWise zudem in den Maintenance-Status verschoben; die dort gelisteten Dienste sind für Neukunden ab dem 30. April 2026 nicht mehr erreichbar [4].

Ein Hinweis zur Einordnung: AWS IoT Events und AWS IoT Analytics gehören nicht zu dieser März-Ankündigung. Ihre Abkündigungen stehen auf eigenen Service-EOL-Seiten mit eigenen Daten (IoT Events: 20. Mai 2026; IoT Analytics: 15. Dezember 2025) [1][7]. AWS unterscheidet dabei klar definierte Lebenszyklus-Stufen: Maintenance (kein Onboarding, keine neuen Funktionen), Sunset (Migration nötig, typischerweise mit einer Sunset-Zeitleiste von rund zwölf Monaten) und Full Shutdown (vollständige Entfernung) [5].

Das Muster ist eindeutig: Wer auf einen einzelnen, hochspezialisierten AWS-IoT-Dienst setzt, trägt ein Plattform-Lebenszyklus-Risiko. Genau das ist ein starkes Argument für eine Open-Source-Plattform, wie wir es auch im Vergleich ThingsBoard vs. AWS IoT Core: Open Source gegen Amazon-Cloud ausführen.

Detector Models verstehen: Zustände, Bedingungen, Timer

Bevor wir migrieren, lohnt ein kurzer Blick auf das, was ein Detector Model ausmacht. Im Kern ist es eine Zustandsmaschine pro Gerät oder Asset:

• Zustände wie Normal und Alarm, zwischen denen das Gerät wechselt.
• Bedingungen auf eingehender Telemetrie, die einen Übergang auslösen, etwa Temperatur über Schwelle.
• Timer, die nach Ablauf einer Frist selbst einen Übergang auslösen, etwa wenn ein Sensor zu lange schweigt.
• Aktionen beim Übergang, etwa eine Benachrichtigung oder ein Output-Event.

Diese vier Bausteine sind genau das, was Sie in der AWS-Welt künftig in Lambda-Code, DynamoDB-Zustand und EventBridge-Timern nachbauen müssten. In ThingsBoard bilden Sie sie stattdessen als Konfiguration ab.

Die ThingsBoard-Entsprechung: Alarm Rules 2.0 in 4.3

ThingsBoard 4.3 wurde am 20. Januar 2026 als Active-LTS-Version veröffentlicht und bringt Alarm Rules 2.0 mit [10][9]. Diese Alarm-Engine ist genau die deklarative Entsprechung zu einem Detector Model.

Die Zustandslogik bilden drei Bedingungstypen ab [8]:

• Simple: löst sofort aus, sobald der Ausdruck wahr wird. Das entspricht einem direkten Zustandsübergang auf einen Schwellwert.
• Duration: die Bedingung muss über einen definierten Zeitraum durchgehend wahr bleiben. Das ersetzt den klassischen Detector-Model-Timer, etwa Temperatur über fünf Minuten zu hoch.
• Repeating: löst erst nach einer festgelegten Zahl aufeinanderfolgender Treffer aus, ideal gegen Sensor-Flattern und Fehlalarme.

Dazu kommen automatische Clear-Bedingungen für den Rückweg in den Normalzustand sowie dynamische Schwellwerte aus Attributen oder Telemetrie und statische wie dynamische Zeitpläne [8]. Alarm Rules 2.0 erweitert das um Multi-Signal-Alarme, die mehrere Signale verknüpfen (zum Beispiel auslösen, wenn Temperatur > 50 ODER Feuchte < 70), um die neue Missing-For-Operation für ausbleibende Telemetrie und um einen Script-Modus für Sonderfälle. Bestehende Alarmregeln aus Geräteprofilen bleiben dabei vollständig kompatibel und brechen nicht [9]. Regeln lassen sich auf Geräte- und Asset-Profile oder direkt auf einzelne Geräte, Assets und Kunden anwenden [9].

Entscheidend ist: Das alles ist Konfiguration, kein Code. Wo der AWS-Eigenbau eine Lambda verlangt, die AWS selbst nicht als produktionsreif bezeichnet, definieren Sie in ThingsBoard eine Regel und sind fertig.

Mapping-Tabelle: Detector-Model-Konzepte zu ThingsBoard

Die mittlere Spalte ist Code und Infrastruktur, die rechte Spalte ist Konfiguration. Genau dieser Unterschied entscheidet über Wartungsaufwand und Betriebsrisiko.

In ThingsBoard ist ein Alarm zudem klar strukturiert: fünf Schweregrade (Critical, Major, Minor, Warning, Indeterminate), ein vierstufiger Lifecycle (Active/Cleared kombiniert mit Acknowledged/Unacknowledged) und Eindeutigkeit pro Originator und Typ, sodass je Kombination nur ein aktiver Alarm existiert [9]. Diese Lifecycle-Semantik müssten Sie im AWS-Eigenbau ebenfalls von Hand modellieren.

SiteWise-Alarme migrieren: CloudWatch vs. ThingsBoard-Alarme

Wer AWS IoT SiteWise nutzt und dort Alarme über IoT Events betreibt, ist doppelt betroffen. AWS empfiehlt für diesen Fall die Migration auf CloudWatch-Alarme: SiteWise-Property-Notifications (MQTT) gehen an eine Lambda, die sie in CloudWatch-Metriken umwandelt, auf die wiederum CloudWatch-Alarme reagieren; CloudWatch-Alarme ersetzen damit die bisherigen AWS-IoT-Events-Alarme [6].

Auch das ist wieder ein Eigenbau aus mehreren Diensten, kein 1:1-Ersatz. In ThingsBoard hingegen ist Alarmierung ein Kernfeature der Plattform: Telemetrie kommt herein, eine Alarm Rule wertet sie aus, ein Alarm mit Schweregrad und Lifecycle entsteht, Benachrichtigungen gehen raus, alles in derselben Anwendung und ohne separate Metrik-Pipeline. Wie sich Asset- und Alarmlogik in der Praxis verzahnen, ordnen wir auch im Beitrag ThingsBoard vs. Grafana im IoT-Vergleich ein.

Migrations-Roadmap: In sieben Schritten von IoT Events zu ThingsBoard

1. Inventarisieren und exportieren. Listen Sie alle Detector Models und SiteWise-Alarme auf und exportieren Sie die Definitionen als Referenz (Konsole-Export oder aws iotevents describe-detector-model), solange der Zugriff noch besteht. Nach dem 20. Mai 2026 ist die Konsole weg [1].
2. Zustände und Bedingungen herausarbeiten. Übersetzen Sie jedes Detector Model in eine Tabelle aus Zuständen, Übergangsbedingungen, Timern und Aktionen, sprachlich neutral, noch ohne Zielsyntax.
3. Auf Alarm Rules abbilden. Ordnen Sie jede Bedingung einem Typ zu: Simple, Duration oder Repeating [8]. Timer werden zu Duration oder zur Missing-For-Operation, verknüpfte Sensoren zu Multi-Signal-Alarmen [9].
4. Geräte und Assets modellieren. Legen Sie Geräte- und Asset-Profile in ThingsBoard an und entscheiden Sie, ob die Regel pro Profil oder direkt am Gerät gilt [9].
5. Aktionen verdrahten. Bilden Sie Output-Events und Benachrichtigungen über die Rule Engine ab. Die Action-Kategorie liefert Create-Alarm- und Clear-Alarm-Knoten; für Sonderfälle gibt es den Script-Modus [12].
6. Parallel testen. Spiegeln Sie eine Zeit lang Telemetrie auf beide Systeme und vergleichen Sie die ausgelösten Zustände, bevor Sie umschalten.
7. Umschalten vor dem Stichtag. Schalten Sie die produktive Datenroute auf ThingsBoard, bevor AWS IoT Events am 20. Mai 2026 abgeschaltet wird [1].

Den Betrieb der Plattform selbst, also Updates, Backups und Monitoring, übernimmt thingshost, sodass sich Ihr Team auf die Fachlogik der Alarmregeln konzentrieren kann statt auf Infrastruktur.

Kosten und Datenhoheit: Selbstbau-Pipeline vs. Managed ThingsBoard

Kostenseitig stehen sich zwei Welten gegenüber. Die AWS-Selbstbau-Pipeline summiert mehrere abrechnungsrelevante Dienste: Kinesis Data Streams, Lambda-Invocations, DynamoDB, EventBridge und CloudWatch, jeweils mit eigenem Pricing. Dazu kommt der laufende Engineering-Aufwand für den Betrieb und die Wartung von Logik, die AWS selbst nur als illustratives Beispiel liefert [1][2]. Die Kosten skalieren mit Datenvolumen und Komplexität, und sie sind schwer vorhersehbar.

Demgegenüber bietet thingshost Managed ThingsBoard als Flatrate: 149,90 EUR/Monat in der Standard-Variante (Community Edition, Region Deutschland; andere Regionen 169,90 EUR), Premium mit PE-Lizenz ab 249,90 EUR/Monat, Enterprise auf Anfrage, monatlich kündbar, ohne Per-Message- und ohne Per-Device-Kosten [13]. Planbare Kosten statt einer Pipeline aus fünf metered Services. Die vollständige Staffelung steht bei den Flatrate-Preisen ohne Per-Message-Kosten.

Mindestens ebenso wichtig ist die Datenhoheit. Ein AWS-Eigenbau bleibt im US-Cloud-Lock-in: ein US-Konzern, der dem CLOUD Act unterliegt, und eine tief verzahnte Service-Pipeline, aus der ein Wechsel praktisch unmöglich wird. ThingsBoard hingegen ist Open Source unter Apache 2.0 und unterstützt MQTT, CoAP, HTTP, LwM2M und SNMP [11]. thingshost hostet es in acht Regionen: Deutschland, Niederlande, USA, Kanada, Singapur, Japan, Australien (Sydney) und Indien [13]. Die deutsche Region läuft in Rechenzentren mit ISO 27001 und BSI C5, die übrigen Regionen in Rechenzentren mit ISO 27001 und SOC 2 Type II; die Zertifikate hält der jeweilige Rechenzentrumsbetreiber [13]. Wer den Wechsel ohne eigenes Betriebsteam gehen will, findet die Details bei Managed ThingsBoard ohne DevOps-Aufwand. Welches Hosting-Modell für welchen Fall passt, vertiefen wir im Beitrag ThingsBoard Hosting: Cloud vs. Self-Hosted vs. Managed, und welche Edition Sie brauchen, klärt ThingsBoard CE vs. PE 2026.

Kein Rechtsrat: Was Sie vor dem 20. Mai 2026 entscheiden sollten

Fassen wir zusammen. Der 20. Mai 2026 ist eine harte Frist: Danach sind AWS-IoT-Events-Konsole und -Ressourcen weg [1]. Ein automatisches Migrationstool gibt es nicht, nur eine Bauanleitung, die AWS selbst nicht als produktionsreif bezeichnet [1]. Wer ohnehin neu bauen muss, sollte die Migration nicht reflexhaft im selben Ökosystem fortsetzen, sondern die Zustands- und Alarmlogik deklarativ auf ThingsBoard 4.3 Alarm Rules 2.0 portieren.

Konkret vor dem Stichtag: Exportieren Sie Ihre Detector-Model-Definitionen als Referenz, bevor der Zugriff endet. Übersetzen Sie Zustände, Bedingungen und Timer in das Alarm-Rules-Mapping. Und entscheiden Sie bewusst zwischen einer selbstgewarteten AWS-Pipeline und einer managed Open-Source-Plattform.

Ein wichtiger Hinweis zum Schluss: Compliance-Fragen, etwa zur DSGVO oder zum CLOUD Act, sollten Sie rechtlich prüfen lassen. Dieser Beitrag ordnet die technischen und wirtschaftlichen Aspekte der Migration ein, er ist kein Rechtsrat.

Zur Frage, ob die neue Plattform beim Hersteller oder als betriebene Instanz laufen soll, steht der Preisvergleich auf der Seite zur ThingsBoard Cloud Alternative.

Lesetipp: ThingsBoard vs. AWS IoT Core: Open Source gegen Amazon-Cloud · ThingsBoard Hosting: Cloud vs. Self-Hosted vs. Managed · ThingsBoard CE vs. PE 2026

Quellen

1. AWS IoT Events end of support (offizieller Developer Guide)
2. Migration procedure for detector models in AWS IoT Events
3. AWS IoT FleetWise availability change (offizieller Developer Guide)
4. AWS Service Availability Updates (What's New, März 2026)
5. AWS Lifecycle Changes (Maintenance / Sunset / Full Shutdown)
6. Migration procedure for AWS IoT SiteWise alarms in AWS IoT Events
7. AWS IoT Analytics end of support (offizieller User Guide)
8. ThingsBoard Alarm Rules Dokumentation (Simple/Duration/Repeating)
9. ThingsBoard 4.3 Release: Alarm Rules 2.0, Calculated Fields, API Keys
10. ThingsBoard Releases-Übersicht (Versionshistorie)
11. ThingsBoard GitHub Repository (Apache 2.0, Protokolle)
12. ThingsBoard Rule Engine Getting Started (Knotenkategorien, Create/Clear Alarm)
13. thingshost.de - Managed ThingsBoard Hosting (Regionen, Preise, Zertifizierungen)