AWS IoT Coreとは？機能・料金・MQTT接続方法をまとめて解説

AWS IoT Coreは、多数のIoTデバイスとAWSクラウドをMQTTなどのプロトコルで安全につなぐ、フルマネージドのメッセージ基盤です。サーバーの構築や運用をせずに、数百万台規模のデバイスからのデータ受信・状態管理・他サービスへのルーティングを任せられます。この記事では「そもそも何ができるのか」から、接続に使うポートとエンドポイントの確認方法、X.509証明書による認証、料金の課金ディメンション、boto3での操作、そしてどんな場面では向かないのかまで、実務で判断に必要な情報を一通り整理します。

まとめ：AWS IoT Coreの要点

• 正体：AWS IoT CoreはマネージドなMQTT/HTTPメッセージブローカー。デバイスの接続・認証・状態保持・ルーティングをサーバーレスで提供する。
• 接続：MQTTはポート8883（TLS）、WebSocket経由は443、HTTPSは8443。接続先はアカウント固有のATSエンドポイントで、aws iot describe-endpointで取得する。MQTTペイロード上限は128KB。
• 認証：デバイスはX.509クライアント証明書による相互TLSが基本。権限はAWS IoT Coreポリシーで接続・購読・発行の単位まで絞る。
• 料金：接続時間・メッセージ数・Device Shadow/レジストリ操作・ルールエンジンの4系統で課金。12か月の無料枠がある。高頻度テレメトリはメッセージ課金が膨らみやすい。
• 終了の噂：AWS IoT Core本体は継続。終了したのはIoT Analytics（2025年12月）やIoT Events（2026年5月）などの周辺サービス。

AWS IoT Coreとは：マネージドなIoTメッセージ基盤

AWS IoT Coreは、IoTデバイスとクラウドの間の通信を仲介するマネージドサービスです。中核はMQTTに対応したメッセージブローカーで、デバイスは特定のトピックにメッセージを発行（publish）し、別のデバイスやAWSサービスがそれを購読（subscribe）します。ブローカー本体はAWSが運用するため、利用者はEC2やロードバランサを立てる必要がなく、接続数やメッセージ量に応じて自動的にスケールします。

「IoTサーバー」や「IoTプラットフォーム」を自前で用意する代わりにAWS IoT Coreを使う、という位置づけで理解すると分かりやすいです。デバイス台数が少ないうちからサーバーレスで始められ、認証・状態管理・他サービス連携といったIoT特有の面倒をサービス側が引き受けます。自前でMQTTブローカー（Mosquittoなど）を運用する場合との違いは、可用性・スケール・AWSサービスとの統合を自分で作り込まなくてよい点にあります。

AWS IoT Coreで何ができるか：主要機能

「AWS IoT Coreで何ができるのか」は、次の5つの機能群に分けると整理できます。それぞれが別の役割を担い、組み合わせて1つのIoTシステムを構成します。

メッセージブローカー（MQTT/HTTPのpub/sub）

デバイスとアプリケーションの間でメッセージを中継します。MQTT、WebSocket上のMQTT、HTTPSに対応し、トピック階層（例：devices/sensor-01/telemetry）で送信先を制御します。1メッセージのサイズ上限は後述のとおり128KBです。

デバイスレジストリ

接続するデバイスを「モノ（Thing）」として登録・管理する台帳です。デバイスに属性やグループを付与し、証明書やポリシーと関連付けます。台数が増えたときに、どのデバイスがどの権限を持つかを一元管理できます。

Device Shadow（デバイスシャドウ）

各デバイスの「あるべき状態」と「現在の状態」をJSONドキュメントとしてクラウドに保持する機能です。デバイスがオフラインの間にアプリ側から設定変更を指示しておき、次にオンラインになった時点で同期させる、といった非同期の状態管理を実現します。電波が不安定な現場デバイスで特に効きます。

ルールエンジン

受信メッセージをSQLライクな構文でフィルタ・変換し、Lambda・DynamoDB・Amazon S3・Kinesisなど他のAWSサービスへ転送します。デバイス側にロジックを持たせず、クラウド側でデータの振り分けを完結できるのが利点です。

SELECT temperature, deviceId FROM 'devices/+/telemetry' WHERE temperature > 30

上の例は、全デバイスのテレメトリトピックから温度が30を超えたメッセージだけを抜き出す指定です。+はトピック階層のワイルドカードです。

デバイス管理（Jobs・Fleet Provisioning・Device Defender）

大量デバイスの一括操作を支える機能群です。Jobsはファームウェア更新などのリモート実行、Fleet Provisioningは初回接続時の証明書自動発行、Device Defenderは通信量やポートの異常を監視するセキュリティ機能を担います。数千台規模の運用でオンボーディングと監視を自動化するために使います。

デバイス接続：プロトコル・ポート・エンドポイント

接続でつまずきやすいのが、どのポートにどのエンドポイントで繋ぐか、という点です。ここは検索でも「mqtt aws」「port 8883」「aws iot core endpoint」として個別に調べられている論点なので、分けて説明します。

対応プロトコルとポート

いずれもTLS 1.2以上で暗号化されます。ファイアウォールで8883が塞がれている環境では、ALPNを使ってMQTTを443で通す方法があります。「aws iot core https」で調べられるのはこのHTTPS経由の発行を指します。

エンドポイントの確認方法

接続先はアカウントごとに固有で、AWS CLIまたはコンソールから取得します。データ通信用のエンドポイントはiot:Data-ATSタイプを指定します。

aws iot describe-endpoint --endpoint-type iot:Data-ATS

返ってくるのはxxxxxxxxxxxxxx-ats.iot.ap-northeast-1.amazonaws.comのような値で、これがMQTT接続のブローカーアドレスになります。ATS（Amazon Trust Services）版を使うのが現在の推奨で、対応するルートCA証明書とセットで使います。

MQTTメッセージサイズの上限と超過時の対応

1メッセージのペイロード上限は128KBです。これを超えるデータ（画像・ログのまとまり等）はブローカー経由では送れません。分割送信するか、デバイスからAmazon S3へ直接アップロードし、参照情報だけをMQTTで流す設計にします。テレメトリを高頻度で送る場合は、1回あたりのサイズだけでなく後述の課金（5KB単位のメッセージ計上）も意識する必要があります。

認証とセキュリティ：X.509相互TLSと最小権限ポリシー

AWS IoT Coreはデフォルトで暗号化・認証必須です。ここを緩めるとデバイスが乗っ取られる入口になるため、仕組みを押さえておきます。

X.509証明書による相互TLS認証

デバイス認証の基本は、デバイスごとに発行するX.509クライアント証明書を使った相互TLSです。デバイスはサーバー証明書を検証し、AWS IoT Core側もクライアント証明書でデバイスを検証します。証明書はデバイスレジストリの「モノ」と紐づけ、失効させれば即座に接続を遮断できます。IAMユーザーのアクセスキーをデバイスに配る運用は避けます。

AWS IoT Coreポリシーで権限を絞る

証明書には接続・購読・発行の許可範囲を定めたAWS IoT Coreポリシーを添付します。デバイスは自分のトピックだけを扱えれば十分なので、ワイルドカードで全トピックを許可せず、クライアントIDやトピックを限定します。

{
  "Effect": "Allow",
  "Action": ["iot:Publish"],
  "Resource": ["arn:aws:iot:ap-northeast-1:123456789012:topic/devices/${iot:ClientId}/telemetry"]
}

${iot:ClientId}のポリシー変数を使うと、各デバイスが自分のクライアントID配下のトピックにしか発行できないよう縛れます。最小権限を証明書単位で徹底するのがセキュリティ設計の要です。

通信とデータの暗号化

デバイスとブローカー間はTLSで暗号化され、平文通信は許可されません。ルールエンジンから連携するS3やDynamoDB側でも保存時暗号化を有効にし、経路と保管の両方を保護します。異常な接続や権限逸脱の検知はDevice Defenderで自動化できます。

SDK・API・boto3での開発

「aws iot core sdk」「boto3 iot」「aws iot core api」で調べられるとおり、AWS IoT Coreの操作は用途で使うライブラリが分かれます。ここを取り違えると「publishできない」といった詰まり方をします。

デバイス側：AWS IoT Device SDK v2

デバイスからMQTTで接続・発行・購読するには、AWS IoT Device SDK v2を使います。C++・Python（awsiotsdk）・JavaScript・Java・Swiftなどが提供され、証明書とエンドポイントを指定して接続を確立します。証明書ベースの相互TLSを前提にした接続処理が組み込まれているため、自前でTLSハンドシェイクを書く必要はありません。

コントロールプレーン：boto3・AWS CLI

「モノ」の作成やポリシー付与といった管理操作（コントロールプレーン）は、boto3のiotクライアントやAWS CLIで行います。一方、サーバー側からメッセージを発行するデータ操作はiot-dataクライアントを使う点に注意します。

import boto3

# 管理操作（モノの登録）
iot = boto3.client("iot")
iot.create_thing(thingName="sensor-01")

# データ操作（メッセージ発行）
data = boto3.client("iot-data")
data.publish(topic="devices/sensor-01/telemetry", qos=1, payload=b'{"temp":28}')

公式ドキュメントとリファレンス

APIやSDKの詳細は「AWS IoT Core デベロッパーガイド」と各言語SDKのリファレンスが一次情報です。仕様・上限値・料金は改定されるため、実装時は公式ドキュメントで最新値を確認してください。

AWS IoT Coreの料金体系とコスト管理

料金は「使った分だけ」の従量課金で、単一の月額ではなく複数のディメンションの合算です。ここを理解しないと、デバイス台数が同じでも送信頻度で請求額が大きく変わります。

4つの課金ディメンション

注意したいのは計上単位です。メッセージングは5KB単位なので、8KBのメッセージは2件として数えられます。料率はリージョンで異なり、東京リージョンは米国東部より高めです。最新の正確な料率は公式の料金ページで確認してください。

無料枠：12か月の対象範囲

アカウント作成から12か月間、無料枠が用意されています。接続225万分、メッセージ50万件、Device Shadow/レジストリ操作22.5万回、ルール25万件とアクション25万件が目安です。小規模なPoCや検証はこの範囲で始められます。

コストを膨らませない設計

コストが跳ねる典型は、多数のデバイスが高頻度で小さなメッセージを送り続けるケースです。メッセージは5KB単位で計上されるため、1秒ごとの送信を数十秒〜数分にまとめるだけで件数を大きく削れます。ルールを通さずデータストアへ直接取り込む「Basic Ingest」を使うと、メッセージング課金を回避してルールへ流せます。送信頻度・バッチ化・Basic Ingestの3点が、請求額を左右する主なレバーです。

他のAWSサービスとの連携とエッジ処理

AWS IoT Core単体はメッセージの受け口であり、データの保存・分析・可視化は他サービスと組み合わせて実現します。ルールエンジンが連携のハブになります。

ルールエンジンからの転送先

ルールで抽出したメッセージは、Lambda（任意の処理）、DynamoDB（低レイテンシな保存）、Amazon S3（生データの蓄積）、Kinesis（ストリーム分析）などへ振り分けます。可視化はS3やデータストアを経由してAmazon QuickSightで行う構成が定番です。デバイス側を変えずに、後段の分析基盤だけ差し替えられるのが疎結合の利点です。

エッジ処理はAWS IoT Greengrass

ネットワークが不安定な現場や、クラウド往復の遅延が許容できない用途では、デバイス近傍でLambdaや推論を動かすAWS IoT Greengrassを併用します。役割分担と使い分けの詳細はAWS IoT Greengrassの概要と特徴を解説した記事で整理しています。全デバイスがオンライン前提で軽量な通信だけなら、Greengrassを入れずAWS IoT Coreだけで足ります。

AWS IoT Coreが向かない場面とコストの落とし穴

どんなIoT要件でもAWS IoT Coreが最適とは限りません。導入前に外すべきでない判断ポイントを挙げます。

超高頻度・大量デバイスのテレメトリでは、メッセージング課金（5KB単位）が想定外に膨らむことがあります。数万台が秒単位でデータを送る用途は、Basic Ingestやバッチ化を前提に試算し、場合によってはKinesisへの直接取り込みや、EMQXなどのセルフホスト型MQTTブローカーとの比較検討が必要です。

大きなペイロードの転送は128KB制限に阻まれます。画像や動画を扱うなら、MQTTで運ぶのではなくS3へ直接アップロードする設計が前提です。

逆に、状態管理と安全な双方向通信が要件の中心で、AWSの他サービスと組み合わせて分析まで行いたいなら、認証・スケール・連携を自前で作らずに済むAWS IoT Coreの利点が明確に出ます。要件が「大量の一方向ストリーム」なのか「双方向の制御と状態管理」なのかで、採否を分けるのが実務的です。

よくある質問

AWS IoT Coreはサービス終了しますか？

いいえ、AWS IoT Core本体は継続しています。終了したのはIoT Analytics（2025年12月15日でサポート終了）やIoT Events（2026年5月20日でサポート終了）といった周辺サービスで、これらとCore本体は別物です。混同して「AWS IoTが終わる」と誤解されがちですが、メッセージ基盤であるCoreは提供が続いています。

AWS IoT Coreとは一言でいうと何ですか？

IoTデバイスとAWSクラウドをMQTTなどで安全につなぐ、フルマネージドのメッセージブローカーです。サーバーを構築せずに、デバイスの接続・認証・状態管理・データのルーティングを任せられます。

MQTTの接続に使うポートは何番ですか？

MQTT（TLS）は8883、WebSocket経由のMQTTは443、HTTPSは8443（または443）です。デバイスの常時接続では8883を使うのが標準です。CoAPは受け付けないため、機器側でCoAPを使うならCoAP（IoTプロトコル）とMQTTへの変換をゲートウェイで挟む構成になります。

エンドポイントはどこで確認できますか？

AWS CLIでaws iot describe-endpoint --endpoint-type iot:Data-ATSを実行すると、アカウント固有のATSエンドポイントが返ります。コンソールの設定画面からも確認できます。

無料で試せますか？

アカウント作成から12か月間の無料枠があり、接続225万分・メッセージ50万件などの範囲で費用をかけずに検証できます。無料枠を超えた分から従量課金になります。

関連記事

• AWS IoT Greengrassとは何か？その概要と特徴を解説
• MQTTの概要とその歴史：プロトコルの基本的な仕組みと進化
• AWS DynamoDBとは？特徴・使い方・料金・RDSとの違いを実装目線で解説