AWS IoT Events is shutting down — here's your migration path

Amazon has been quiet about this. A deprecation notice buried in the AWS docs, a brief mention in re:Invent 2025 slides. No migration tool, no automatic transition. Just a date and a suggestion to look at IoT SiteWise or "build your own."

If you are reading this and still running IoT Events in production, the time to move is now. Not next sprint. Not after Q2 planning. Now.

What IoT Events actually did for most teams

AWS IoT Events was marketed as a state machine service for IoT. It could model complex event-driven workflows: multi-condition alarms, cascading state transitions, detector models with branching logic. On paper, it was powerful.

In practice, the vast majority of IoT Events deployments did one thing: "alert me when device X stops reporting."

Here is what a typical detector model looked like:

That is a heartbeat check. A timer that resets when a signal arrives. IoT Events wrapped it in a state machine definition language, CloudFormation templates, IAM roles, and five AWS service integrations. But the core logic was always: "did the device ping? If not, yell."

AWS suggests IoT SiteWise. It's overkill.

Amazon's official recommendation is to migrate to AWS IoT SiteWise for asset monitoring, or build a custom solution using IoT Core rules, Lambda, and Step Functions.

IoT SiteWise is an industrial asset modeling platform. It was built for factories running OPC-UA gateways with hundreds of data streams per asset. If you are monitoring which Raspberry Pis are still alive, SiteWise is a freight train for a bicycle delivery.

The custom Lambda path is worse. You are rebuilding IoT Events from scratch: a DynamoDB table for device state, a Lambda that processes incoming messages, a Step Functions workflow for timeout logic, CloudWatch alarms for the Lambda itself, and SNS for notifications. That is five services to replace one — and you own all the operational complexity.

There is a simpler path for the heartbeat use case. One that does not require AWS at all.

Before and after: 5 services to 1

Here is what your AWS IoT Events setup looks like today, and what it can look like after migration:

BEFORE (AWS IoT Events):
Device → MQTT → IoT Core → IoT Events Detector Model
       → Lambda → SNS → Email/PagerDuty

5 AWS services. IAM roles for each. CloudFormation templates.
$0.25/million messages + $0.10/detector/month + Lambda + SNS.
Months of CloudWatch dashboards to debug when it breaks.

AFTER (HTTP heartbeat):
Device → HTTP GET → Uptrack → Slack / Discord / Email

1 service. 1 HTTP request per interval. No IAM. No MQTT.
Free for 50 devices. Setup time: 10 minutes.

The device does not need the AWS SDK. It does not need MQTT libraries. It does not need an IoT Core certificate. It needs curl.

Migration code: it's embarrassingly simple

Create a heartbeat monitor in Uptrack. You get a unique URL. Then replace your IoT Events integration with one of these:

Bash — any Linux device

# Add to crontab: */5 * * * * /usr/local/bin/heartbeat.sh
#!/bin/bash
curl -fsS -m 10 -o /dev/null \
  https://uptrack.app/api/heartbeat/hb_abc123def456

Python — Raspberry Pi / edge devices

import requests, time, logging

HEARTBEAT_URL = "https://uptrack.app/api/heartbeat/hb_abc123def456"
INTERVAL = 300  # 5 minutes — match your Uptrack monitor config

while True:
    try:
        resp = requests.get(HEARTBEAT_URL, timeout=10)
        logging.info(f"Heartbeat sent: {resp.status_code}")
    except Exception as e:
        logging.warning(f"Heartbeat failed: {e}")
        # Uptrack will alert if enough pings are missed
    time.sleep(INTERVAL)

That is the entire migration for most devices. Remove the AWS IoT SDK, the MQTT connection logic, the certificate management, and the IoT Core policy. Replace it with one HTTP request on a timer.

Step-by-step migration plan

You can complete this migration in an afternoon. Here is the sequence:

What Uptrack heartbeat monitoring gives you

The clock is ticking

May 20 is not a soft deprecation. AWS will stop processing detector model evaluations. Your devices will keep sending MQTT messages into a void. No alerts will fire. Your team will not know a device is down until a customer calls.

The migration takes an afternoon. The cost of not migrating is silent device failures across your entire fleet. Do not wait for the deadline to prove that point.