Detección de eventos IoT - AWS IoT Events ha finalizado: guía de migración
AWS IoT Events finalizó el 20 de mayo de 2026. Cubre las rutas oficiales de migración, como reimplementar la supervisión de estados con Kinesis Data Streams y Lambda, y cómo funcionaban los modelos detectores.
Fin del soporte y rutas de migración
AWS IoT Events llegó al fin de su soporte el 20 de mayo de 2026 y había dejado de aceptar nuevos clientes el 20 de mayo de 2025. La guía oficial de migración de AWS muestra cómo reimplementar la supervisión de estados tipo modelo detector con Amazon Kinesis Data Streams y AWS Lambda, y cómo migrar las alarmas de AWS IoT SiteWise. Este artículo se conserva como referencia histórica y guía de migración.
Desafíos de la monitorización de estado de dispositivos IoT
En la monitorización de dispositivos IoT, es necesario detectar no solo simples superaciones de umbrales, sino transiciones de estado complejas. Por ejemplo, condiciones como "alertar si la temperatura supera los 80°C durante más de 5 minutos", "notificar al equipo de mantenimiento si el valor de vibración supera el rango normal y no vuelve a la normalidad en 10 minutos", o "determinar que el dispositivo está offline si se pierden 3 heartbeats consecutivos". Implementar esto manualmente con Lambda y DynamoDB requiere gestionar la persistencia de estado, los temporizadores y la lógica de transición, lo que resulta en código complejo y difícil de mantener. AWS IoT Events resolvía este problema proporcionando un motor de máquina de estados gestionado.
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 de monitoreo de temperatura, se definían 3 estados: "normal", "advertencia" y "anomalía", y se configuraban las transiciones de estado basadas en umbrales de temperatura. Se podían ejecutar acciones al entrar en un estado (onEnter), durante la permanencia (onInput) y al salir (onExit). Se creaba una instancia de detector por dispositivo (clave de dispositivo), gestionando el estado de forma independiente. La función de alarma simplificaba la monitorización de umbrales simples, generando automáticamente alarmas cuando un valor superaba un umbral configurado.
Acciones e integración
Las acciones que se podían ejecutar durante las transiciones de estado del modelo de detector eran diversas. Notificar a operadores con SNS, ejecutar lógica personalizada con Lambda, enviar mensajes a SQS para activar procesamiento downstream, publicar mensajes MQTT a IoT Core para enviar comandos a dispositivos, escribir logs de eventos en DynamoDB, enviar datos a Firehose para acumular en S3, entre otras. Estas acciones se podían combinar para construir flujos de trabajo de respuesta automática complejos. Por ejemplo, cuando se detectaba una anomalía de temperatura, se podía notificar simultáneamente al equipo de mantenimiento, registrar el evento y enviar un comando de apagado al dispositivo.
Precios de IoT Events
Con el cierre del servicio, los siguientes precios ya no existen (se conservan como registro histórico). Los precios de IoT Events se cobraban por número de evaluaciones de mensajes. Las evaluaciones se medían en incrementos de 1 KB y costaban 15 USD por millón de evaluaciones en EE. UU. Este (Norte de Virginia) para los primeros 100 millones al mes, con tarifas escalonadas que bajaban a 10, 5 y 3 USD por millón a mayor volumen. Las alarmas se facturaban aparte, a 0,10 USD al mes por cada alarma activa (la que evaluaba al menos un mensaje en el mes), y sus evaluaciones de mensajes se cobraban a la tarifa estándar. Por ejemplo, 1.000 dispositivos enviando un mensaje de 1 KB por minuto generaban unos 43,2 millones de evaluaciones al mes, equivalentes a unos 648 USD. En entornos donde miles de dispositivos enviaban mensajes cada minuto, el número de evaluaciones aumentaba rápidamente, por lo que la práctica habitual era prefiltrar con el motor de reglas de IoT Core y enviar solo valores cercanos al umbral a IoT Events para optimizar costos.
Resumen - Directrices de migración
AWS IoT Events detectaba transiciones de estado complejas en dispositivos IoT y ejecutaba acciones automáticas, pero llegó al fin de su soporte el 20 de mayo de 2026. El procedimiento oficial de migración muestra la telemetría entrando en Kinesis Data Streams, la lógica de transición de estados evaluada en Lambda y las acciones ejecutadas mediante servicios como SNS. Las ideas de diseño de este artículo, como el prefiltrado cerca de los umbrales y el estado aislado por dispositivo, se trasladan directamente a la arquitectura reimplementada.