AWS IoT Events Is Dead (EOL May 20, 2026): Migrate Detector Models to ThingsBoard

WZ-IT operates thingshost. Current hosting starts from €159.80 net/month; setup and service level follow the proposal. Former package prices, location lists and cost comparisons in this dated article describe the previous offer, not current WZ-IT terms. View current service scope.

AWS has officially deprecated AWS IoT Events, effective May 20, 2026. After that date the console and resources are no longer accessible, and there is no automatic migration tool. AWS provides only a how-to guide for rebuilding the logic of your detector models yourself from Kinesis, Lambda, DynamoDB, and EventBridge, explicitly as an illustrative example, not a production-ready replacement. Rather than rebuilding a fragile, self-maintained multi-service pipeline inside the same US cloud lock-in, the state and alarm logic can be mapped declaratively onto ThingsBoard 4.3 with Alarm Rules 2.0, hosted sovereignly in Germany. This article is a practical migration roadmap away from end of life.

Also worth reading: ThingsBoard vs. AWS IoT Core: Open Source vs. Amazon Cloud · EU Data Act and IoT Platforms 2026

Quick Overview: AWS IoT Events EOL vs. ThingsBoard

Table of Contents

• AWS IoT Events: What Happens on May 20, 2026
• No Migration Tool: What AWS Offers Instead
• The AWS Self-Build in Detail: Kinesis, Lambda, DynamoDB, EventBridge
• The Bigger Picture: AWS Is Pruning the IoT Family
• Understanding Detector Models: States, Conditions, Timers
• The ThingsBoard Equivalent: Alarm Rules 2.0 in 4.3
• Mapping Table: Detector Model Concepts to ThingsBoard
• Migrating SiteWise Alarms: CloudWatch vs. ThingsBoard Alarms
• Migration Roadmap: Seven Steps from IoT Events to ThingsBoard
• Cost and Data Sovereignty: Self-Build Pipeline vs. Managed ThingsBoard
• Not Legal Advice: What to Decide Before May 20, 2026
• Sources

AWS IoT Events: What Happens on May 20, 2026

The facts are unambiguous. AWS ends support for AWS IoT Events effective May 20, 2026. The official developer guide states verbatim that after May 20, 2026 you will no longer be able to access the AWS IoT Events console or AWS IoT Events resources [1]. This is not a soft deprecation with years of grace, but a hard cutoff.

A year earlier, AWS already closed the door to new customers: since May 20, 2025, AWS IoT Events no longer accepts new customers [1]. Existing customers set up before that date may keep using the service until the final end of support. If you run detector models in production today, the message is clear: May 20, 2026 is your deadline for a complete migration.

For most teams, this is more than a technical detail. Detector models often drive safety-relevant state machines: machine running hot, tank running empty, sensor silent for minutes. If that logic disappears after the cutoff, a piece of operational safety goes with it. A migration is therefore not optional, but forced.

No Migration Tool: What AWS Offers Instead

The uncomfortable truth: there is no automatic migration tool. Instead, AWS provides migration guides with code samples, but stresses itself that these solutions are meant to serve as illustrative examples, not as production-ready replacements for AWS IoT Events functionality, and that you should customize the code, workflow, and related AWS resources to your business needs [1].

Read that sentence again. AWS tells you directly that the supplied code is not a finished product but a sketch you must build out into a reliable, tested, and maintained solution yourself, including error handling, scaling, monitoring, and on-call. What used to be a managed service with a visual editor becomes a software project under your responsibility.

This is exactly where the comparison with a finished platform pays off. If you have to rebuild the logic anyway, the question is whether you rewire it into a self-maintained AWS pipeline or port it into a declarative alarm engine that expresses this state logic as configuration rather than code. We recommend not reflexively rebuilding within the same ecosystem here, but treating the migration as an opportunity.

The AWS Self-Build in Detail: Kinesis, Lambda, DynamoDB, EventBridge

AWS's outlined replacement for detector models is a classic multi-service pipeline [2]:

• IoT Core with two MQTT topics: one topic for incoming data (input) and a second for results (output). Previously, a single logical entry point was enough.
• Kinesis Data Streams: replaces AWS IoT Events input functionality and buffers the data stream [2].
• Evaluator Lambda (NodeJS): replaces the detector model and provides the customizable state logic in code instead of a visual workflow [2]. The sample uses a NodeJS 22.x runtime. All the transition logic that was declarative in the detector model you now write by hand.
• DynamoDB table: replaces the internal state management of AWS IoT Events and holds the current device state [2].
• EventBridge Scheduler: handles the timers that were built into detector models.
• A single IAM role: ties all of these services together with the necessary permissions.

This is not a replacement, this is an architecture. Five services, one code component, and a permission mesh that all have to work together to turn telemetry into a correct state transition. Each service has its own pricing, limits, and failure modes. And the central logic sits in a Lambda that AWS itself explicitly labels an illustrative example [1]. That is the definition of a fragile, self-maintained pipeline.

The Bigger Picture: AWS Is Pruning the IoT Family

AWS IoT Events is not an isolated case. The company is systematically thinning out its specialized IoT services. We have documented the complete 2026 retirement list with all deadlines and a strategy framework in a separate overview.

AWS IoT Analytics is already past its end of support: December 15, 2025 [7]. Here too, console and resources ended with the cutoff, and new customers were no longer accepted starting July 24, 2024 [7].

AWS IoT FleetWise is affected as well, but with different mechanics. The developer guide makes it clear: FleetWise is no longer open to new customers, but existing customers can keep using it. AWS will not add new features, but continues to provide security updates [3]. No shutdown date is given. In a service availability announcement on March 31, 2026, AWS additionally moved FleetWise to Maintenance status; the services listed there are no longer accessible to new customers starting April 30, 2026 [4].

A note for context: AWS IoT Events and AWS IoT Analytics are not part of that March announcement. Their deprecations live on their own service EOL pages with their own dates (IoT Events: May 20, 2026; IoT Analytics: December 15, 2025) [1][7]. AWS distinguishes clearly defined lifecycle stages: Maintenance (no onboarding, no new features), Sunset (migration required, typically with a sunset timeline of around twelve months), and Full Shutdown (fully removed) [5].

The pattern is clear: anyone betting on a single, highly specialized AWS IoT service carries a platform lifecycle risk. That is a strong argument for an open-source platform, as we also detail in ThingsBoard vs. AWS IoT Core: Open Source vs. Amazon Cloud.

Understanding Detector Models: States, Conditions, Timers

Before we migrate, it pays to look at what makes a detector model. At its core it is a state machine per device or asset:

• States such as Normal and Alarm, between which the device switches.
• Conditions on incoming telemetry that trigger a transition, e.g., temperature above a threshold.
• Timers that trigger a transition on their own after a deadline, e.g., when a sensor stays silent too long.
• Actions on transition, e.g., a notification or an output event.

These four building blocks are exactly what you would have to rebuild in the AWS world from Lambda code, DynamoDB state, and EventBridge timers. In ThingsBoard you express them as configuration instead.

The ThingsBoard Equivalent: Alarm Rules 2.0 in 4.3

ThingsBoard 4.3 was released on January 20, 2026 as an Active LTS version and ships Alarm Rules 2.0 [10][9]. This alarm engine is precisely the declarative equivalent of a detector model.

The state logic is expressed via three condition types [8]:

• Simple: triggers immediately when the expression becomes true. This matches a direct state transition on a threshold.
• Duration: the condition must remain true continuously for a defined period. This replaces the classic detector model timer, e.g., temperature too high for five minutes.
• Repeating: triggers only after a specified number of consecutive occurrences, ideal against sensor flapping and false alarms.

Add to that automatic clear conditions for the path back to normal, plus dynamic thresholds from attributes or telemetry and static as well as dynamic schedules [8]. Alarm Rules 2.0 extends this with multi-signal alarms that combine several signals (e.g., trigger if temperature > 50 OR humidity < 70), with the new Missing For operation for absent telemetry, and with a script mode for edge cases. Existing alarm rules from device profiles remain fully compatible and do not break [9]. Rules can apply to device and asset profiles or directly to individual devices, assets, and customers [9].

The decisive point: all of this is configuration, not code. Where the AWS self-build requires a Lambda that AWS itself does not call production-ready, in ThingsBoard you define a rule and you are done.

Mapping Table: Detector Model Concepts to ThingsBoard

The middle column is code and infrastructure, the right column is configuration. Exactly this difference decides maintenance effort and operational risk.

In ThingsBoard, an alarm is also clearly structured: five severities (Critical, Major, Minor, Warning, Indeterminate), a four-state lifecycle (Active/Cleared combined with Acknowledged/Unacknowledged), and uniqueness per originator and type, so that only one active alarm exists per combination [9]. You would have to model this lifecycle semantics by hand in the AWS self-build as well.

Migrating SiteWise Alarms: CloudWatch vs. ThingsBoard Alarms

Anyone using AWS IoT SiteWise with alarms running through IoT Events is doubly affected. For this case AWS recommends migrating to CloudWatch alarms: SiteWise property notifications (MQTT) go to a Lambda that converts them into CloudWatch metrics, which CloudWatch alarms in turn react to; CloudWatch alarms thereby replace the former AWS IoT Events alarms [6].

This too is another multi-service self-build, not a 1:1 replacement. In ThingsBoard, by contrast, alerting is a core feature of the platform: telemetry comes in, an alarm rule evaluates it, an alarm with severity and lifecycle is created, notifications go out, all in the same application and without a separate metrics pipeline. How asset and alarm logic interlock in practice is something we also discuss in ThingsBoard vs. Grafana in an IoT comparison.

Migration Roadmap: Seven Steps from IoT Events to ThingsBoard

1. Inventory and export. List all detector models and SiteWise alarms and export the definitions as a reference (console export or aws iotevents describe-detector-model) while access still exists. After May 20, 2026 the console is gone [1].
2. Extract states and conditions. Translate each detector model into a table of states, transition conditions, timers, and actions, in neutral language, without target syntax yet.
3. Map onto Alarm Rules. Assign each condition a type: Simple, Duration, or Repeating [8]. Timers become Duration or the Missing For operation, linked sensors become multi-signal alarms [9].
4. Model devices and assets. Create device and asset profiles in ThingsBoard and decide whether the rule applies per profile or directly on the device [9].
5. Wire up actions. Map output events and notifications via the Rule Engine. The Action category provides Create Alarm and Clear Alarm nodes; for edge cases there is the script mode [12].
6. Test in parallel. Mirror telemetry to both systems for a while and compare the triggered states before you switch over.
7. Cut over before the cutoff. Switch the production data route to ThingsBoard before AWS IoT Events is shut off on May 20, 2026 [1].

Operating the platform itself, i.e., updates, backups, and monitoring, is handled by thingshost, so your team can focus on the business logic of the alarm rules instead of infrastructure.

Cost and Data Sovereignty: Self-Build Pipeline vs. Managed ThingsBoard

On cost, two worlds face each other. The AWS self-build pipeline sums up several billing-relevant services: Kinesis Data Streams, Lambda invocations, DynamoDB, EventBridge, and CloudWatch, each with its own pricing. On top of that comes the ongoing engineering effort to operate and maintain logic that AWS itself supplies only as an illustrative example [1][2]. Costs scale with data volume and complexity, and they are hard to predict.

By contrast, thingshost offers Managed ThingsBoard as a flat rate: EUR 149.90/month in the Standard variant (Community Edition, Germany region; other regions EUR 169.90), Premium with an official PE license from EUR 249.90/month, Enterprise on request, cancellable monthly, with no per-message and no per-device fees [13]. Predictable costs instead of a pipeline of five metered services. The full tiering is listed under flat-rate pricing without per-message fees.

At least as important is data sovereignty. An AWS self-build stays inside the US cloud lock-in: a US corporation subject to the CLOUD Act, and a tightly coupled service pipeline that makes switching practically impossible. ThingsBoard, by contrast, is open source under Apache 2.0 and supports MQTT, CoAP, HTTP, LwM2M, and SNMP [11]. thingshost hosts it in eight regions: Germany, the Netherlands, the US, Canada, Singapore, Japan, Australia (Sydney), and India [13]. The German region runs in data centers with ISO 27001 and BSI C5, the other regions in data centers with ISO 27001 and SOC 2 Type II; the certificates are held by the respective data center operator [13]. If you want to make the switch without your own operations team, the details are under managed ThingsBoard without DevOps overhead. Which hosting model fits which case we explore in ThingsBoard Hosting: Cloud vs. Self-Hosted vs. Managed, and which edition you need is clarified in ThingsBoard CE vs. PE 2026.

Not Legal Advice: What to Decide Before May 20, 2026

To sum up. May 20, 2026 is a hard deadline: after it, the AWS IoT Events console and resources are gone [1]. There is no automatic migration tool, only a how-to guide that AWS itself does not call production-ready [1]. Anyone who has to rebuild anyway should not reflexively continue inside the same ecosystem, but port the state and alarm logic declaratively onto ThingsBoard 4.3 Alarm Rules 2.0.

Concretely before the cutoff: export your detector model definitions as a reference before access ends. Translate states, conditions, and timers into the alarm rules mapping. And deliberately decide between a self-maintained AWS pipeline and a managed open-source platform.

One important final note: compliance questions, e.g., on GDPR or the CLOUD Act, should be reviewed legally. This article frames the technical and economic aspects of the migration; it is not legal advice.

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

On the question of whether the new platform should run with the vendor or as a managed instance, the price comparison is on the ThingsBoard Cloud alternative page.

Sources

1. AWS IoT Events end of support (official developer guide)
2. Migration procedure for detector models in AWS IoT Events
3. AWS IoT FleetWise availability change (official developer guide)
4. AWS Service Availability Updates (What's New, March 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 (official user guide)
8. ThingsBoard Alarm Rules documentation (Simple/Duration/Repeating)
9. ThingsBoard 4.3 Release: Alarm Rules 2.0, Calculated Fields, API Keys
10. ThingsBoard releases overview (version history)
11. ThingsBoard GitHub repository (Apache 2.0, protocols)
12. ThingsBoard Rule Engine getting started (node categories, Create/Clear Alarm)
13. thingshost.io - Managed ThingsBoard Hosting (regions, pricing, certifications)