TL

Cloud Service

AWS IoT Core

大量のIoTデバイスを安全に接続し、MQTT等でメッセージを送受信するマネージドなIoT基盤。

中級SAA-C03セキュリティ信頼性
最終更新: 2026-06-14公式ドキュメント ↗
TL;DR要点だけ先に
  • 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 CoreAmazon 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、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
  • 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。

次に確認する観点

IoTsecurityreliabilitySAA-C03