Detección de eventos IoT - Fin del soporte de AWS IoT Events y guía de migración
AWS IoT Events llegó al fin de su soporte el 20 de mayo de 2026. Este artículo explica los destinos oficiales de migración, como la reimplementación de la supervisión de estados con Kinesis Data Streams + Lambda, y el funcionamiento de los modelos de detector cuando el servicio estaba disponible.
Fin del soporte y destinos de migración
AWS IoT Events llegó al fin de su soporte (End of Support) el 20 de mayo de 2026. La aceptación de nuevos usuarios terminó el 20 de mayo de 2025. Para la migración, las opciones típicas son una configuración que reimplementa la supervisión de estados equivalente al modelo de detector con una combinación como Amazon Kinesis Data Streams + AWS Lambda, y una configuración que sustituye la función de alarmas por las alarmas de AWS IoT SiteWise. Ambas son opciones de migración que combinan servicios estándar de AWS, y el diseño se adapta a los requisitos. Este artículo se conserva como material histórico que documenta el funcionamiento del servicio cuando estaba disponible + guía de migración.
Desafíos de la supervisión del estado de los dispositivos IoT
En la supervisión de dispositivos IoT es necesario detectar no solo simples superaciones de umbrales, sino también transiciones de estado complejas. Se trata, por ejemplo, de condiciones como «alertar si la temperatura se mantiene por encima de 80°C durante 5 minutos o más» o «notificar al equipo de mantenimiento si el valor de vibración supera el rango normal y no vuelve a la normalidad en un plazo de 10 minutos». Otra es «considerar el dispositivo fuera de línea si se pierden 3 heartbeats consecutivos». Si se implementan por cuenta propia con Lambda y DynamoDB, la lógica de gestión del estado se vuelve compleja y, a medida que aumenta el número de dispositivos, también surgen problemas de escalado. AWS IoT Events era un servicio que definía las transiciones de estado de los dispositivos IoT como un modelo de detector (Detector Model) y ejecutaba acciones automáticas en función de condiciones. La máquina de estados se podía definir en un editor visual, y se generaba automáticamente una instancia de detector independiente para cada dispositivo.
Modelos de detector y alarmas
El modelo de detector era una máquina de estados compuesta por estados (State), condiciones de transición (Transition) y acciones (Action). Por ejemplo, en un modelo de detector para la supervisión de temperatura se definían tres estados, «normal», «advertencia» y «anomalía», y se configuraban las transiciones de estado en función de los umbrales de temperatura. Se podían ejecutar acciones al entrar en cada estado (onEnter), durante la permanencia en él (onInput) y al salir (onExit). Al especificar una clave (el ID del dispositivo) por dispositivo, se creaba una instancia de detector independiente para cada uno, lo que permitía gestionar por separado el estado de miles de dispositivos. La función de alarmas era una versión simplificada del modelo de detector que configuraba una supervisión basada en un único umbral y enviaba notificaciones de SNS o invocaba Lambda al superarse el umbral. Su posición era la de una función suficiente cuando no se necesitaban transiciones de estado complejas.
Acciones e integración
Las acciones que se podían ejecutar en las transiciones de estado de un modelo de detector eran muy variadas. Eran posibles integraciones como notificar a los operadores con SNS, ejecutar lógica personalizada con Lambda y enviar mensajes a SQS para activar el procesamiento posterior. También se podían publicar mensajes MQTT en IoT Core para enviar comandos a los dispositivos, escribir registros de eventos en DynamoDB y enviar datos a Firehose para almacenarlos en S3. La configuración más habitual era enviar datos a IoT Events mediante una acción de regla de IoT Core. Cuando un dispositivo enviaba telemetría por MQTT, la regla de IoT Core reenviaba los datos a IoT Events y el modelo de detector evaluaba el estado. Con la API BatchPutMessage, también se podían enviar datos directamente sin pasar por IoT Core.
Precios de IoT Events
Con el fin del soporte, la estructura de precios siguiente ya no existe (registro de cuando el servicio estaba disponible). IoT Events se cobraba por número de evaluaciones de mensajes. Las evaluaciones de mensajes se medían en unidades de 1 KB. En la región Este de Estados Unidos (Norte de Virginia), costaban 15 USD por cada millón de evaluaciones hasta 100 millones al mes, y el precio bajaba de forma escalonada a 10 USD, 5 USD y 3 USD por cada millón a medida que aumentaba el uso. Las alarmas se facturaban en una categoría aparte: se sumaban 0,10 USD al mes por cada alarma activa que hubiera evaluado al menos un mensaje en el mes, y las evaluaciones en sí se cobraban por separado a la tarifa normal de evaluación de mensajes. Por ejemplo, si 1.000 dispositivos enviaban un mensaje de 1 KB a intervalos de 1 minuto, se generaban unos 43,2 millones de evaluaciones al mes, lo que equivalía a unos 648 USD en la región Este de Estados Unidos. En entornos donde las evaluaciones aumentaban bruscamente, la práctica habitual para optimizar costes era un diseño que prefiltraba con el motor de reglas de IoT Core y reenviaba a IoT Events solo los valores cercanos al umbral.
Lógica de detección mediante máquinas de estados
El núcleo de IoT Events era el modelo de detector, que representaba cómo cambiaba el estado de un dispositivo. Se diseñaba como una máquina de estados que definía los estados que podía adoptar un dispositivo y las condiciones para pasar de un estado a otro. Por ejemplo, se describían transiciones como pasar al estado «advertencia» cuando la temperatura superaba cierto nivel, al estado «peligro» si seguía subiendo y al estado «normal» cuando volvía a la normalidad. Su punto fuerte era que permitía una detección que tenía en cuenta los cambios de estado y su duración, difíciles de captar con una simple supervisión de umbrales. Esta idea de organizar el comportamiento de los dispositivos como estados para gestionar de forma comprensible condiciones complejas sigue siendo válida en una reimplementación con Kinesis Data Streams + Lambda.
Casos de uso y operación
IoT Events se utilizaba en situaciones en las que se supervisaba el estado de muchos dispositivos y se respondía automáticamente a las anomalías. Los ejemplos típicos eran supervisar el estado de funcionamiento de los equipos de fabricación y activar procesos de notificación o parada al detectar indicios de anomalía, o enviar alertas a la persona responsable cuando la temperatura de los equipos de climatización o refrigeración se salía del valor de referencia. La detección podía ejecutar automáticamente acciones como enviar notificaciones o iniciar procesos en otros sistemas, y la misma lógica de detección se podía aplicar a muchos dispositivos para supervisar toda la flota. Por ello, se podía mantener una supervisión coherente incluso a gran escala. Este patrón operativo de captar los cambios de estado y responder automáticamente es una forma básica que respalda el ahorro de trabajo operativo y una respuesta rápida a las anomalías. Se puede trasladar tal cual a la configuración reimplementada.
Resumen - Directrices de migración
AWS IoT Events era un servicio que detectaba transiciones de estado complejas de los dispositivos IoT y ejecutaba acciones automáticas, pero llegó al fin de su soporte el 20 de mayo de 2026. En una configuración habitual después de la migración, Kinesis Data Streams recibe la telemetría, Lambda evalúa la lógica de transición de estados y servicios como SNS ejecutan las acciones. Esta combinación es un ejemplo de configuración que permite reproducir un procesamiento equivalente al del modelo de detector solo con servicios estándar de AWS. Los diseños de este artículo, como el prefiltrado que procesa solo los valores cercanos al umbral y la gestión del estado independiente por dispositivo, siguen siendo una referencia directa en la configuración reimplementada.
Referencias (recursos oficiales de AWS)
Las fuentes primarias de esta página son el sitio web y la documentación oficiales de AWS. Consulta las páginas oficiales siguientes para conocer las especificaciones y los precios más recientes.
- AWS IoT Events (página oficial)
- AWS IoT Core (página oficial)
- AWS Lambda (página oficial)
- Documentación de AWS (oficial)
Si esta página y la documentación oficial difieren, prevalece la documentación oficial.