IoT Event Detection - AWS IoT Events Is Discontinued: Migration Guide

AWS IoT Events ended on May 20, 2026. Covers the official migration paths, such as re-implementing state monitoring with Kinesis Data Streams and Lambda, and how detector models worked.

End of Support and Migration Paths

AWS IoT Events reached its end of support on May 20, 2026, and had stopped accepting new customers on May 20, 2025. The official AWS migration guidance shows how to re-implement detector-model style state monitoring with Amazon Kinesis Data Streams and AWS Lambda, and how to migrate AWS IoT SiteWise alarms. This article remains available as a historical reference and migration guide.

Challenges of IoT Device State Monitoring

IoT device monitoring requires detecting not just simple threshold breaches but complex state transitions. For example: "Alert if temperature exceeds 80°C for more than 5 minutes," "Notify the maintenance team if vibration exceeds the normal range and doesn't return to normal within 10 minutes," or "Mark the device as offline if three consecutive heartbeats are missed." Implementing these with Lambda and DynamoDB leads to complex state management logic, and scaling challenges grow as device counts increase. AWS IoT Events was a service that defined IoT device state transitions as detector models and executed automated actions based on conditions. State machines could be defined using a visual editor, and independent detector instances were automatically created for each device.

Detector Models and Alarms

A detector model was a state machine composed of states, transition conditions, and actions. For example, a temperature monitoring detector model would define three states - "Normal," "Warning," and "Critical" - with state transitions based on temperature thresholds. Actions could be executed on state entry (onEnter), while in a state (onInput), and on state exit (onExit). By specifying a key (device ID) per device, independent detector instances were created for each device, enabling individual state management for thousands of devices. The alarm feature was a simplified version of detector models for single-threshold monitoring, executing SNS notifications or Lambda invocations when thresholds were breached. When complex state transitions weren't needed, the alarm feature was sufficient.

Actions and Integrations

Detector models could execute a wide range of actions on state transitions: send SNS notifications to operators, run custom logic with Lambda, send SQS messages to trigger downstream processing, publish MQTT messages via IoT Core to send commands to devices, write event logs to DynamoDB, and send data to Firehose for accumulation in S3. The most common setup was configuring an IoT Core rule action to send data to IoT Events: when a device sent telemetry via MQTT, an IoT Core rule forwarded the data to IoT Events, where the detector model evaluated the state. The BatchPutMessage API also allowed sending data directly without going through IoT Core.

IoT Events Pricing

With the shutdown, the following pricing no longer exists (kept as a historical record). IoT Events charged based on message evaluation count. Message evaluations were metered in 1 KB increments and cost $15 per million evaluations in US East (N. Virginia) for the first 100 million per month, with tiered rates dropping to $10, $5, and $3 per million as volume grew. Alarms were billed separately at $0.10 per month for each active alarm (one that evaluated at least one message that month), with the associated message evaluations charged at the standard rate. As an example, 1,000 devices each sending a 1 KB message every minute generated roughly 43.2 million evaluations per month, or about $648 in US East. In environments where thousands of devices sent messages every minute, evaluation counts escalated quickly, so the standard cost optimization was to pre-filter with the IoT Core rules engine and forward only values near thresholds to IoT Events.

Summary - Migration Guidelines

AWS IoT Events detected complex state transitions in IoT devices and executed automated actions, but it reached end of support on May 20, 2026. The official migration procedure shows telemetry flowing into Kinesis Data Streams, state-transition logic evaluated in Lambda, and actions executed through services such as SNS. Design ideas from this article, such as pre-filtering near thresholds and keeping per-device state isolated, carry over directly to the re-implemented architecture.

References (Official AWS Resources)

The primary sources for this page are the official AWS website and documentation. Check the official pages below for the latest specifications and pricing.

If this page and the official documentation disagree, treat the official documentation as authoritative.