IoT イベント検知 - AWS IoT Events 提供終了と移行ガイド
AWS IoT Events は 2026 年 5 月 20 日に提供終了。Kinesis Data Streams + Lambda による状態監視の再実装など公式移行先と、提供当時の検出器モデルの仕組みを解説します。
提供終了と移行先
AWS IoT Events は 2026 年 5 月 20 日をもって提供終了 (End of Support) となりました。新規利用の受付は 2025 年 5 月 20 日に終了しています。移行にあたっては、検出器モデル相当の状態監視を Amazon Kinesis Data Streams + AWS Lambda などの組み合わせで再実装する構成や、アラーム機能を AWS IoT SiteWise のアラームへ置き換える構成が代表的な選択肢になります。いずれも標準的な AWS サービスを組み合わせた移行先の選択肢で、要件に合わせて設計します。本記事は提供当時の仕組みを記録した歴史的資料 + 移行ガイドとして残しています。
IoT デバイスの状態監視の課題
IoT デバイスの監視では、単純な閾値超過だけでなく、複雑な状態遷移を検知する必要があります。たとえば「温度が 80°C を超えた状態が 5 分以上継続したらアラート」「振動値が正常範囲を超えた後、10 分以内に正常に戻らなければ保守チームに通知」「3 回連続でハートビートが途絶えたらデバイスオフラインと判定」といった条件です。これらを Lambda と DynamoDB で自前実装すると、状態管理のロジックが複雑になり、デバイス数の増加に伴いスケーリングの課題も生じます。AWS IoT Events は、IoT デバイスの状態遷移を検出器モデル (Detector Model) として定義し、条件に基づく自動アクションを実行するサービスでした。状態マシンをビジュアルエディタで定義でき、デバイスごとに独立した検出器インスタンスが自動生成される仕組みでした。
検出器モデルとアラーム
検出器モデルは状態 (State)、遷移条件 (Transition)、アクション (Action) で構成される状態マシンでした。たとえば温度監視の検出器モデルでは、「正常」「警告」「異常」の 3 状態を定義し、温度の閾値に基づいて状態遷移を設定しました。各状態の入場時 (onEnter)、滞在中 (onInput)、退場時 (onExit) にアクションを実行でき、デバイスごとにキー (デバイス ID) を指定すると、各デバイスに独立した検出器インスタンスが生成され、数千台のデバイスを個別に状態管理できました。アラーム機能は検出器モデルの簡易版で、単一の閾値に基づく監視を設定し、閾値超過時に SNS 通知や Lambda 呼び出しを実行するものでした。複雑な状態遷移が不要な場合はアラーム機能で足りる位置づけでした。
アクションと統合
検出器モデルの状態遷移時に実行できるアクションは多岐にわたりました。 SNS でオペレーターに通知、 Lambda でカスタムロジックを実行、 SQS にメッセージを送信してダウンストリーム処理をトリガー、 IoT Core に MQTT メッセージをパブリッシュしてデバイスにコマンドを送信、 DynamoDB にイベントログを書き込み、 Firehose にデータを送信して S3 に蓄積、といった連携が可能でした。 IoT Core のルールアクションで IoT Events にデータを送信する設定が最も一般的で、デバイスが MQTT でテレメトリを送信すると、 IoT Core のルールが IoT Events にデータを転送し、検出器モデルが状態を評価する流れでした。 BatchPutMessage API を使えば、 IoT Core を経由せずに直接データを送信することもできました。
IoT Events の料金
提供終了に伴い、以下の料金体系は現在は存在しません (提供当時の記録)。IoT Events の料金はメッセージ評価回数で課金されました。メッセージ評価は 1 KB 単位で計測され、米国東部 (バージニア北部) では月間 1 億回までが 100 万回あたり 15 ドルで、利用量の増加に応じて 100 万回あたり 10 ドル、5 ドル、3 ドルへ段階的に下がる体系でした。アラームは別区分の課金で、月内に 1 回以上メッセージを評価したアクティブなアラーム 1 件につき月額 0.10 ドルが加算され、評価そのものには通常のメッセージ評価料金が別途かかりました。たとえば 1,000 台のデバイスが 1 分間隔で 1 KB のメッセージを送信すると月間約 4,320 万回の評価となり、米国東部では約 648 ドルに相当しました。評価回数が急増する環境では、IoT Core のルールエンジンで事前フィルタリングし、閾値に近い値のみを IoT Events に転送する設計がコスト最適化の定石でした。
状態機械による検知ロジック
IoT Events の中核は、デバイスの状態の移り変わりを表現する検出器モデルでした。デバイスが取りうる状態と、ある状態から別の状態へ移る条件を定義した状態機械として設計する方式で、たとえば温度が一定を超えたら「警告」状態へ移り、さらに上がれば「危険」状態へ、正常に戻れば「通常」状態へ、という具合に遷移を記述しました。単純なしきい値の監視では捉えにくい、状態の変化や継続時間を考慮した検知ができる点が強みでした。デバイスの振る舞いを状態として整理して複雑な条件を分かりやすく管理するこの考え方自体は、Kinesis Data Streams + Lambda での再実装でも変わらず有効です。
ユースケースと運用
IoT Events は、多数のデバイスの状態を監視し、異常に自動対応する場面で使われました。製造設備の稼働状態を監視し、異常の兆候を検知したら通知や停止の処理を起動する、空調や冷蔵設備の温度が基準を外れたら担当者にアラートを送る、といった用途が典型例でした。検知をきっかけに通知の送信や他システムの処理起動といったアクションを自動実行でき、同じ検知ロジックを多数のデバイスに適用してフリート全体を監視できるため、規模が大きくても一貫した監視を保てました。状態の変化を捉えて自動で対応するという運用の型は、運用の省力化と異常への迅速な対応を支える基本形として、再実装後の構成にもそのまま引き継げます。
まとめ - 移行の指針
AWS IoT Events は、IoT デバイスの複雑な状態遷移を検出して自動アクションを実行するサービスでしたが、2026 年 5 月 20 日に提供を終了しました。移行後の一般的な構成では、Kinesis Data Streams でテレメトリを受け、Lambda で状態遷移ロジックを評価し、SNS などでアクションを実行します。この組み合わせは AWS の標準サービスだけで検出器モデル相当の処理を再現できる構成例です。閾値付近のみ処理する事前フィルタリングや、デバイスごとに独立した状態管理といった本記事の設計は、再実装後の構成でもそのまま参考になります。
参考資料 (AWS 公式)
本ページの一次情報は AWS 公式サイトおよび公式ドキュメントです。最新の仕様 / 料金は次の公式ページで確認できます。
本ページと公式ドキュメントの記述が食い違う場合は、公式ドキュメントを正としてください。