Cloud Service
AWS IoT Core
大量のIoTデバイスを安全に接続し、MQTT等でメッセージを送受信するマネージドなIoT基盤。
- 1.膨大な台数のデバイスを安全につなぎメッセージを中継するマネージド基盤。
- 2.デバイスごとの証明書とポリシーで認証認可し、ルールで他サービスへ連携。
- 3.デバイスシャドウでオフラインでも最新状態を保持し同期できる。
解決する課題
- 数万から数百万台規模のデバイスを安全に接続したい
- 不安定な回線でも軽量プロトコルで双方向通信したい
- デバイスからのデータを他のAWSサービスへ流し込みたい
- デバイスがオフラインでも最新の状態を保持・同期したい
主要概念と用語
- メッセージブローカー: デバイスとアプリの間を仲介する Pub/Sub の中核。MQTT のトピックでやり取りする
- トピック: メッセージの宛先となる文字列の階層。送信側と受信側はトピックで疎結合につながる
- モノ(Thing): デバイスを表すレジストリ上の論理的な表現。属性やグループで管理する
- デバイス証明書: 個々のデバイスに紐づく X.509 証明書。これで相互 TLS 認証を行う
- ポリシー: 証明書に紐づけ、接続・購読・発行など許可する操作を細かく定義する
- ルールエンジン(Rules): トピックに届いたメッセージを SQL ライクな式で抽出し、Lambda・S3・DynamoDB・SNS 等へ転送する
- デバイスシャドウ: デバイスの希望状態と報告状態を保持する JSON ドキュメント。オフライン時の状態同期に使う
仕様・制限・クォータ
- 主に MQTT を用い、WebSocket 上の MQTT や HTTPS にも対応
- 接続・購読・発行のスループットや 1 メッセージあたりのサイズには上限があり、リージョンやアカウントごとのクォータが定められている
- メッセージブローカーはメッセージを長期保持しない。永続化が必要ならルールで他サービスへ送る
- 大量デバイスの一括プロビジョニングや、専用エンドポイントの利用も可能
内部の仕組み
デバイスは AWS IoT Core のエンドポイントへ相互 TLS で接続し、メッセージブローカーに対してトピックへ発行(publish)したり、トピックを購読(subscribe)したりします。ブローカーは Pub/Sub なので、送信側と受信側は互いの存在を意識せず疎結合につながります。
届いたメッセージはルールエンジンが評価し、条件に合致したものを Lambda・S3・DynamoDB・Kinesis・SNS などへ転送します。これによりブローカー自身は保持を持たずとも、データを必要なサービスへ確実に流せます。
デバイスシャドウは、各デバイスの「あるべき状態(desired)」と「報告された状態(reported)」を JSON で保持します。デバイスがオフラインでもクラウド側はシャドウを更新でき、再接続時に差分を同期できます。
メッセージブローカーはキューのように長期保持しません。データを残したい・後で集計したいなら、ルールエンジンで S3 や DynamoDB へ転送するのが基本です。
設計パターン / ベストプラクティス
- デバイス1台=証明書1枚+最小権限ポリシーで、漏洩時の影響を局所化する
- 取り込んだデータはルールで S3 へ蓄積し、Athena 等で分析する
- リアルタイム処理が必要ならルールから Lambda や Kinesisへつなぐ
- オフライン耐性が要る制御はデバイスシャドウで状態同期する
- トピック階層を機種・テナント・用途で設計し、ポリシーでトピック単位に絞る
運用・監視
- CloudWatch メトリクスで接続数・発行/購読数・ルール実行・エラーを監視する
- 接続イベントや認証失敗はCloudWatch Logsへ出力して原因を追う
- ルールの転送先でエラーが起きた場合に備え、エラーアクションで別トピックや DLQ 相当へ退避する
- 証明書の有効期限切れや失効を運用フローに組み込む
コスト
- 接続時間・メッセージ数・ルール実行・デバイスシャドウ操作などの使った分だけ課金が基本
- 不要なトピック購読や過剰なメッセージ頻度を抑えると費用を最適化できる
- 大量デバイスではメッセージ頻度とペイロードサイズの設計が費用に効く
セキュリティ
- デバイスは X.509 証明書による相互 TLS で認証し、通信は常に暗号化される
- 証明書に紐づく IoT ポリシーで、接続・購読・発行を最小権限に絞る
- 証明書を**無効化(失効)**すれば、漏洩したデバイスを即座に遮断できる
- ルールから他サービスへ渡す際は IAM ロールで権限を限定する
ポリシーで全トピックを許可すると、1台の侵害が全体に波及します。トピックとアクションを限定し、デバイスごとに権限を分けてください。
Well-Architected の観点
- セキュリティ: デバイス単位の証明書・最小権限ポリシー・失効による即時遮断
- 信頼性: Pub/Sub による疎結合、デバイスシャドウによるオフライン同期、ルールのエラーアクション
- 運用上の優秀性: CloudWatch によるメトリクス/ログ監視と一括プロビジョニング
試験で問われるポイント
- 大量デバイスを安全に接続=AWS IoT Core。軽量プロトコルは MQTT
- 認証はデバイスごとの X.509 証明書(相互 TLS)、認可はIoT ポリシー(最小権限)
- 届いたメッセージを他サービスへ流すのはルールエンジン(保持はしない)
- オフライン状態の同期=デバイスシャドウ
関連サービス・比較
| 観点 | AWS IoT Core | Amazon SNS |
|---|---|---|
| 主な対象 | IoTデバイスの双方向通信 | アプリ間の同報通知 |
| プロトコル | MQTT中心(軽量・双方向) | AWS API経由のプッシュ |
| 認証 | デバイス証明書(相互TLS) | IAM/トピックポリシー |
| 特徴 | シャドウやルールで状態同期と連携 | Pub/Subでファンアウト |
ハンズオン / 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
AWS Service
AWS IoT Coreを実務で読む
TL;DRは入口です。実際に選ぶ・使う段階では、何を解決するか、何と比較するか、導入後にどこで詰まるかまで見る必要があります。
解決すること
IoT
比較で見る軸
クラウド: AWS / カテゴリ: IoT / 難易度: intermediate
導入後に効く点
デバイスごとの証明書とポリシーで認証認可し、ルールで他サービスへ連携。
先に潰すリスク
サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。
- クラウド
- AWS
- カテゴリ
- IoT
- 難易度
- intermediate
- 関連資格
- SAA-C03
- 設計柱
- security / reliability
判断チェックリスト
- 自社の用途が「IoT / security」に近いか確認する。
- 強みである「膨大な台数のデバイスを安全につなぎメッセージを中継するマネージド基盤。」が本当に評価軸になるか確認する。
- 注意点の「サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。」を運用で吸収できるか確認する。
- 公開値や仕様値は、対象プラン・対象機種・対象リージョンまで確認する。
- 既存システム、ID、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
- 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。