AWS IoT Core

解決する課題

• 数万から数百万台規模のデバイスを安全に接続したい
• 不安定な回線でも軽量プロトコルで双方向通信したい
• デバイスからのデータを他のAWSサービスへ流し込みたい
• デバイスがオフラインでも最新の状態を保持・同期したい

主要概念と用語

• メッセージブローカ: デバイスとアプリの間を仲介する Pub/Sub の中核。MQTT のトピックでやり取りする
• トピック: メッセージの宛先となる文字列の階層。送信側と受信側はトピックで疎結合につながる
• モノ（Thing）: デバイスを表すレジストリ上の論理的な表現。属性やグループで管理する
• デバイス証明書: 個々のデバイスに紐づく X.509 証明書。セキュアMQTTでは一般に相互TLS認証へ使う
• ポリシー: 証明書に紐づけ、接続・購読・発行など許可する操作を細かく定義する
• ルールエンジン（Rules）: トピックに届いたメッセージを SQL ライクな式で抽出し、Lambda・S3・DynamoDB・SNS 等へ転送する
• デバイスシャドウ: デバイスの希望状態と報告状態を保持する JSON ドキュメント。オフライン時の状態同期に使う

仕様・制限・クォータ

• 主に MQTT を用い、WebSocket 上の MQTT や HTTPS にも対応
• MQTTの配信品質はQoS 0とQoS 1に対応する。QoS 1は1回以上の配信であり、重複を許容する処理が必要
• セキュアMQTTはX.509証明書、MQTT over WebSocketはSigV4、HTTPSはSigV4またはX.509を利用でき、各プロトコルでカスタムオーソライザーも選べる
• MQTTの発行ペイロードは最大128KBで、1接続あたりの発行要求は既定で毎秒100件。超過分は破棄されるため送信側で抑制する
• 通常の発行メッセージを長期保存する基盤ではない。永続セッションは切断中のQoS 1メッセージを保持し、既定の有効期間は3,600秒、再接続後の保存メッセージ配信は毎秒10件まで
• 保持メッセージはトピックごとに最新1件を保持する。永続セッションの上限超過分や期限切れメッセージは破棄される
• 大量デバイスの一括プロビジョニングや、専用エンドポイントの利用も可能

内部の仕組み

横にスクロール

一般的なMQTTデバイスは AWS IoT Core のエンドポイントへX.509証明書を使う相互TLSで接続し、メッセージブローカに対してトピックへ発行（publish）したり、トピックを購読（subscribe）したりします。Webアプリ等はSigV4、既存の独自認証を使う端末はカスタムオーソライザーを選べます。ブローカは Pub/Sub なので、送信側と受信側は互いの存在を意識せず疎結合につながります。

届いたメッセージはルールエンジンが評価し、条件に合致したものを Lambda・S3・DynamoDB・Kinesis・SNS などへ転送します。転送先の失敗やクォータ超過を前提に、エラーアクション、監視、下流の重複排除を設計します。

デバイスシャドウは、各デバイスの「あるべき状態（desired）」と「報告された状態（reported）」を JSON で保持します。デバイスがオフラインでもクラウド側はシャドウを更新でき、再接続時に差分を同期できます。

設計パターン / ベストプラクティス

• デバイス1台＝証明書1枚＋最小権限ポリシーで、漏洩時の影響を局所化する
• 取り込んだデータはルールで S3 へ蓄積し、Athena 等で分析する
• リアルタイム処理が必要ならルールから Lambda や Kinesisへつなぐ
• オフライン耐性が要る制御はデバイスシャドウで状態同期する
• トピック階層を機種・テナント・用途で設計し、ポリシーでトピック単位に絞る

運用・監視

• CloudWatch メトリクスで接続数・発行/購読数・ルール実行・エラーを監視する
• 接続イベントや認証失敗はCloudWatch Logsへ出力して原因を追う
• ルールの転送先でエラーが起きた場合に備え、エラーアクションで別トピックや DLQ 相当へ退避する
• 証明書の有効期限切れや失効を運用フローに組み込む

コスト

• 接続時間・メッセージ数・ルール実行・デバイスシャドウ操作などの使った分だけ課金が基本
• 不要なトピック購読や過剰なメッセージ頻度を抑えると費用を最適化できる
• 大量デバイスではメッセージ頻度とペイロードサイズの設計が費用に効く

セキュリティ

• MQTTデバイスは通常 X.509 証明書による相互TLS で認証する。WebSocketではSigV4、要件に応じてカスタムオーソライザーも使える
• 証明書に紐づく IoT ポリシーで、接続・購読・発行を最小権限に絞る
• 証明書を無効化（失効）すれば、漏洩したデバイスを即座に遮断できる
• ルールから他サービスへ渡す際は IAM ロールで権限を限定する

Well-Architected の観点

• セキュリティ: デバイス単位の証明書・最小権限ポリシー・失効による即時遮断
• 信頼性: Pub/Sub による疎結合、デバイスシャドウによるオフライン同期、ルールのエラーアクション
• 運用上の優秀性: CloudWatch によるメトリクス/ログ監視と一括プロビジョニング

試験で問われるポイント

関連サービス・比較

ハンズオン / CLI例

# モノ（デバイス）を登録 → 証明書を発行（アクティブ化）
aws iot create-thing --thing-name sensor-001

aws iot create-keys-and-certificate \
  --set-as-active \
  --certificate-pem-outfile cert.pem \
  --public-key-outfile public.key \
  --private-key-outfile private.key

# 受信したメッセージをDynamoDBへ転送するルールを作成（topicRulePayloadは別途定義）
aws iot create-topic-rule \
  --rule-name SaveToDynamo \
  --topic-rule-payload file://rule.json