はじめに
AWS IoT Eventsは、IoT機器の状態遷移管理ができ、サーバーレスで動作する便利なサービスである。一方、IoTルールなど他のサービスと連携して使う前提で作られているようで、デメリットも多い。
本記事では、筆者が感じたIoT Eventsのメリットとデメリットとその一部の回避策についてまとめる。
IoT Eventsサービス終了のお知らせ（2026/5/20に完全終了）
本記事執筆中に、IoT Eventsのサービス終了が発表された。
https://docs.aws.amazon.com/iotevents/latest/developerguide/iotevents-end-of-support.html
また、2025/5/20以降は新規利用不可能となっている。本記事は、IoT Eventsを利用した記録として残しておく。
動作確認環境
- AWS IoT Events
メリット
- 簡単に状態遷移を作成でき、アクションを定義できる
- 単純な状態遷移を持つ場合に、マネージドサービスで利用できて良い
- マネージドサービスなので、負荷分散など考慮しなくてよい
- デバイスごとに一意のキーを設定できるので、各デバイスごとに状態を保持することができる
デメリット
利用できる関数が少ない
利用できる関数は、こちらを参照。IoT Ruleと比べると利用できる関数が少なく、複雑なことを実現するのは難しい。
利用できるイベント（アクション）が少ない
利用できるイベント（アクション）は、こちらを参照。基本的なものはそろっているが数が少ない。イベント（アクション）で実現できないことは、Lambda関数で処理しなければならないことが多い。
オブジェクト配列を扱いづらい
条件式でオブジェクト配列は扱えない
IoT Eventsの条件式で、MQTTトピック内のオブジェクト配列は扱えない。
オブジェクトをカスタムペイロードに直接設定できない
オブジェクトをカスタムペイロードで送るには、エスケープ処理する必要がある。
IoT Coreに送られるオブジェクト配列をIoT Eventsを経由して別のサービスへカスタムペイロードして送信するには、IoTルールのcast関数で、オブジェクトをJSON文字列として変換しておく必要がある。JSON文字列は、エスケープ処理されるので、そのままペイロードとして使うことができる。詳細は筆者の以前の記事を参照。
IoT Events利用のポイント
IoTルールでフィルタしたMQTTトピックを上手く活用すると良い。IoTルールで出来る限り単純なトピックにフィルタした上で、状態遷移を作成するとIoT Eventsで扱いやすくなる。
- 複雑な条件の処理は、IoTルール側でやる
- IoT Eventsでは、処理を単純化しておく
- 上記で解決できない場合は、Lambda関数を併用する
まとめ
本記事では、AWS IoT Eventsのメリットとデメリットをまとめた。簡単にサーバーレスで利用できる、一方、複雑なことをしようとすると、IoTルールやLambda関数を駆使する必要がある。状態管理をできる便利なサービスで、代替がないためサービス終了（EOL）の発表が悔やまれるが、カスタマイズ性が低く本番サービスで利用するには機能が不足しているのも感じるので致し方ないとも思える。今は、AWSは生成AIをはじめとするサービスに注力しているが、今後、IoT関連のサービスがまた盛り上がってほしい。
参考