メッセージサイズとバッチ処理が IoT のクラウド費用を変える仕組み
IoT の料金の多くは、バイト数ではなくメッセージやデータのブロックを数えて課金します。そのため、デバイスが測定値をどうまとめて送るかは、自分で制御できる最大級のコスト要因となり、どのクラウドを選ぶかより大きいことも珍しくありません。
各サービスの数え方
| サービス | 使用量の数え方 |
|---|---|
| Azure IoT Hub | 4 KB ブロック単位のメッセージ数。ユニットごとの 1 日の上限と照合 |
| AWS IoT Core | 5 KB ブロック単位のメッセージ数に、実行されたルールとアクションを加算 |
| Azure Event Hubs | 64 KB ブロック単位のイベント数に、毎秒のイベント数で決まるスループットユニットを加算 |
| Amazon Kinesis (オンデマンド) | 書き込んだ GB と読み取った GB |
| Google Pub/Sub | データ量 (1 リクエストあたりの最小サイズあり) |
| OCI Streaming | 送信した GB と読み取った GB、保持するデータ |
| Oracle IoT Platform | コンピューティングの時間 (ECPU) で、メッセージ数ではありません。バッチ処理で節約できるのは下流のサービスだけです |
ここから 2 つの傾向がわかります。
- 極小のメッセージは割高です。 200 バイトの測定値も、ゲートウェイでは 4 KB または 5 KB のメッセージ 1 件、Event Hubs ではイベント 1 件として課金されます。
- わずかに大きすぎるメッセージも割高です。 4.1 KB のメッセージは IoT Hub では 2 件、5.1 KB のメッセージは IoT Core では 2 件になります。
バッチ処理: 単独で最大の節約
センサーの測定値を取得のたびに送信するのではなく、デバイス (またはエッジゲートウェイ) が数秒分の測定値を集め、1 つのメッセージとして送信します。
20 個のセンサーがそれぞれ毎秒 1 回、1 回あたり約 100 バイトを測定する機械を考えます。
- バッチ処理なし: 毎秒 20 メッセージで、それぞれが 1 ブロックとして課金されます。1 台の機械だけで月 5,000 万件を超えます。
- 1 秒ごとにバッチ処理: 毎秒約 2 KB のメッセージ 1 件。1 ブロックに収まり、メッセージ数は 20 分の 1 です。
- 5 秒ごとにバッチ処理: 5 秒ごとに約 10 KB のメッセージ 1 件。ゲートウェイでは 2〜3 ブロックですが、下流のすべてでイベント数が大きく減ります。
トレードオフは遅延です。5 秒のバッチでは、アラートが最大 5 秒遅れて届きます。ほとんどの工場の監視ではそれで問題ありません。安全インターロックでは許されませんが、そうした処理はクラウド経由ではなく現場で実行すべきです。
送信間隔: 10 秒、30 秒、60 秒
各デバイスの送信頻度は、最も簡単な調整手段です。頻度を半分にすればメッセージが半分になり、メッセージ単位の課金もすべて半分になります。次は、1,000 台の中規模工場を 4 つの間隔で比べたもので、ほかの条件は同じです。
| クラウド | 5 秒ごと | 10 秒ごと | 30 秒ごと | 60 秒ごと |
|---|---|---|---|---|
| Amazon Web Services | ₹139,836最安 | ₹97,531最安 | ₹69,366最安 | ₹62,405最安 |
| Microsoft Azure | ₹189,374 | ₹154,100 | ₹112,809 | ₹99,153 |
| Oracle Cloud | ₹80,315不完全 | ₹76,353不完全 | ₹73,712不完全 | ₹73,052不完全 |
| Google Cloud | ₹93,929不完全 | ₹87,438不完全 | ₹83,111不完全 | ₹82,030不完全 |
Oracle Cloudの合計には エッジランタイム (提供なし), 時系列データベース (提供なし)、IoT デバイスゲートウェイ (公開情報では規模を算出できません) が含まれていません。 不完全な合計が最安と表示されることはありません。
Google Cloudの合計には IoT デバイスゲートウェイ (提供なし)、エッジランタイム (提供なし) が含まれていません。 不完全な合計が最安と表示されることはありません。
ライブ見積もり: インド (ムンバイ / プネ)、リスト価格は 2026年10月27日 更新、更新のたびに再計算します。見積もりツールで開くと、入力を変更できます: 5 秒ごと, 10 秒ごと, 30 秒ごと, 60 秒ごと。
目立つ点が 3 つあります。
- 短い間隔はすぐに高くなります。 10 秒から 5 秒にするとメッセージが倍になります。IoT ゲートウェイの項目は、メッセージ単位で課金する AWS では倍に、ユニットを段階的に追加する Azure では約 5 割増えます。
- 長い間隔の節約は思ったより小さくなります。 30 秒から 60 秒にするとメッセージはまた半分になりますが、合計の減少はわずかです。その時点では、費用の大半が固定費 (時系列データベース、ストリーム処理、アプリサーバー) で、メッセージ数に依存しないためです。
- Azure は段階的に動きます。 IoT Hub は 1 日の上限があるユニットで販売されるため、間隔のわずかな変更でユニット数が変わったり、別のユニットサイズに移ったりすることがあります。
各信号が許容できる最も長い間隔を選んでください。振動や高速なプロセス値は秒単位が必要かもしれません。温度、カウンター、電力量計は、変化時のみ送信 (下記) と組み合わせれば、30 秒や 60 秒で問題ないことが多いです。
費用を下げるその他の方法
- スケジュールではなく変化時に送信する。 動いていない温度を毎秒再送する必要はありません。多くのデバイスやエッジランタイムは不感帯 (値が設定した量を超えて変化したときだけ送信) に対応しています。
- コンパクトな形式を使う。 フィールド名が長い JSON は、Protocol Buffers や CBOR のようなバイナリ形式、または短いキーの JSON と比べて、数倍の大きさになることがあります。
- ブロックサイズ未満を狙う。 メッセージが 4 KB や 5 KB をわずかに超える場合、いくつかのフィールドを削るだけでゲートウェイの課金が半分になることがあります。
- エッジで集約する。 生の測定値 60 件の代わりに 1 分間の最小・最大・平均を送り、生データはトラブルシューティング用に現場に残します。エッジランタイムの比較を参照してください。
数値で効果を確認する
当サイトのインダストリー 4.0 の見積もりツールでは、メッセージサイズと送信間隔を入力できます。現在の設定とバッチ処理後の設定を試して、ゲートウェイとストリーミングの項目を比べてみてください。各ゲートウェイの料金モデルの詳細は、IoT プラットフォームの料金のしくみをご覧ください。