Azure IoT 中樞帳單資訊
Azure IoT 中樞價格提供關於 IoT 中樞之不同 SKU 和價格的一般資訊。 本文包含如何依IoT 中樞將各種IoT 中樞功能計量為訊息的詳細資料。
注意
本文中提及的某些功能 (例如雲端對裝置傳訊、裝置對應項和裝置管理) 僅適用於 IoT 中樞的標準層。 如需基本和標準/免費IoT 中樞層的詳細資訊，請參閱為您的解決方案選擇正確的IoT 中樞層。
每種作業的費用
使用下表來協助判斷要收費的作業。 基本和標準層 IoT 中樞上的所有可計費的作業都會以 4K 位元組區塊為單位計費。 作業是以免費層 IoT 中樞上的 0.5K 位元組區塊來計量。 帳單資訊資料行會提供每個類別的詳細資料。 此資料行包含下列資訊：
- 基本和標準層 IoT 中樞上可計費作業如何計量的詳細資料。 並非所有作業都可在基本層中使用。
- 產生費用的作業包含下列其中一項：
- REST API 文件 (如果存在) 的連結。
- 如果 REST API 文件無法使用，或作業僅在透過 MQTT 和/或 AMQP 時適用，則為作業端點。 端點值省略目標 IoT 中樞的前置參考；
{fully-qualified-iothubname}.azure-devices.net。
- 遵循每個作業 (或端點) 的一或多個斜體字詞。 這些字詞代表針對 IoT 中樞配額計費的可計費作業。 當您在 Azure 入口網站上起始支援要求時，您可能會看到在配額使用方式深入解析中提供的這些字詞。 客戶支援也可能會傳回這些字詞。 您可以使用下表來交叉參考這些字詞與對應的作業，以協助您瞭解 IoT 解決方案的配額使用方式和帳單。 如需詳細資訊，請參閱範例 4。
| 作業類別 | 帳單資訊 |
|---|---|
| 身分識別登錄作業 (建立、更新、取得、列出、刪除、大量更新、統計資料) |
不收費。 |
| 裝置到雲端的訊息 | 成功傳送的訊息在輸入至「IoT 中樞」時會以 4 KB 區塊為單位來收費。 例如，100 位元組的訊息會以一則訊息的形式計費，而 6 KB 訊息則會以兩則訊息的形式計費。 傳送裝置事件：裝置到雲端遙測或裝置到雲端遙測路由，視 IoT 中樞是否已設定訊息路由功能而定。 |
| 雲端到裝置的訊息 | 成功傳送的訊息會以 4 KB 區塊為單位來計費。 例如，6 KB 訊息會以兩個訊息計費。 接收裝置系結通知： 雲端到裝置命令 |
| 檔案上傳 | IoT 中樞不會對 Azure 儲存體進行檔案傳輸計量。 檔案傳輸的啟始和完成訊息會以每 4 KB 的增量方式來就訊息計量收費。 例如，傳輸 10 MB 的檔案時，除了「Azure 儲存體」費用之外，還會收取兩則訊息的費用。 建立檔案上傳 Sas URI： 裝置到雲端檔案上傳 更新檔案上傳狀態： 裝置到雲端檔案上傳 |
| 直接方法 | 成功的方法要求會以 4 KB 區塊為單位來計費，而回應會以額外訊息的形式並以 4 KB 區塊為單位來計費。 沒有承載的要求或回應會以一則訊息計費。 例如，具有 4 KB 本文的方法如果導致裝置傳回沒有承載的回應，將會視為兩則訊息來計費。 具有 6 KB 本文的方法如果導致裝置傳回 1 KB 的回應，則收費方式是將要求視為兩則訊息，再將回應視為另一則訊息。 對已中斷連線裝置的要求會以 4 KB 區塊中的訊息來收費，再加上一則訊息來表示裝置未上線的回應。 Device - Invoke 方法： 裝置直接叫用方法、 模組 - 叫用方法： 模組直接叫用方法 |
| 裝置與模組對應項讀取 | 來自裝置或模組和解決方案後端的對應項讀取是以 4 KB 區塊為單位的訊息來計費。 例如，讀取 8 KB 對應項會以兩則訊息計費。 取得對應項： 取得對應項 取得模組對應項： 取得模組對應項 從裝置讀取裝置和模組對應項： 端點： /devices/{id}/twin (MQTT、僅限 AMQP) ： D2C Get Twin 端點： /devices/{deviceid}/modules/{moduleid}/twin (MQTT、僅限 AMQP) ： 模組 D2C 取得對應項 |
| 裝置與模組對應項更新 (標籤和屬性) | 來自裝置或模組和解決方案後端的對應項更新，是以 4 KB 區塊為單位的訊息來計費。 例如，對應項的 12 KB 更新會以三則訊息計費。 更新對應項： 更新對應項 更新模組對應項： 更新模組對應項 取代對應項： 取代對應項 取代模組對應項： 取代模組對應項 從裝置更新裝置或模組對應項報告屬性： 端點： /twin/PATCH/properties/reported/ (MQTT、AMQP 僅) ： D2 Patch ReportedProperties 或 Module D2 Patch ReportedProperties 接收裝置上所需的屬性更新通知： 端點： /twin/PATCH/properties/desired/ (MQTT、AMQP 僅) ： D2C 通知 DesiredProperties 或 模組 D2C Notify DesiredProperties |
| 裝置與模組對應項查詢 | 根據 4 KB 區塊的結果大小而定，針對 裝置 或 devices.modules 的查詢會以訊息的形式收費。 不會對 作業 進行查詢。 取得 對應項 (查詢 裝置 或 devices.modules 集合) ： 查詢裝置 |
| 數位對應項讀取 | 來自解決方案後端的數位對應項讀取是以 4 KB 區塊為單位的訊息來計費。 例如，讀取 8 KB 對應項會以兩則訊息計費。 取得 Digital Twin： 取得 Digital Twin |
| 數位對應項更新 | 來自解決方案後端的數位對應項更新是以 4 KB 區塊為單位的訊息來計費。 例如，對應項的 12 KB 更新會以三則訊息計費。 更新 Digital Twin： Patch Digital Twin |
| 數位對應項命令 | 成功的命令會以 4 KB 區塊為單位來計費，而會將回應視為額外的訊息並以 4 KB 區塊為單位來計費。 沒有本文的要求或回應會以一個訊息的形式計費。 例如，具有 4 KB 本文的命令如果導致裝置傳回沒有本文的回應，將會視為兩則訊息來計費。 具有 6 KB 本文的命令如果導致裝置傳回 1 KB 的回應，則計費方式是將命令視為兩則訊息，再將回應視為另一則訊息。 中斷連線裝置的命令會以 4 KB 區塊中的訊息來收費，再加上一則訊息，以表示裝置未上線的回應。 叫用元件命令： Digital Twin 元件命令 叫用根層級命令： Digital Twin 根命令 |
| 作業的操作 (建立、取消、取得、查詢) |
不收費。 |
| 作業的每一裝置操作 | 作業作業 (例如對應項更新，以及) 的方法會以 4 KB 區塊計費。 例如，產生 1000 個方法呼叫的作業具有 1 KB 要求，而空承載回應則需支付 2000 個訊息的費用， (每個要求和回應) 一個訊息。 更新對應項裝置作業 叫用方法裝置作業 |
| 設定作業 (建立、更新、取得、列出、刪除、測試查詢) |
不收費。 |
| 每個裝置的設定作業 | 設定作業會以 4 KB 區塊中的訊息形式來計費。 不會收取回應費用。 例如，具有 6 KB 本文的套用設定作業會以兩則訊息的形式計費。 在 Edge 裝置上套用： 設定服務套用。 |
| 保持連線訊息 | 使用 AMQP 或 MQTT 通訊協定時，交換的訊息會建立交涉中交換的連線和訊息，或讓連線保持開啟且保持運作不會收費。 |
| 裝置串流 (預覽) | 裝置串流處於預覽狀態，但尚未收取作業費用。 端點： /twins/{deviceId}/streams/{streamName} ： 裝置串流 端點： /twins/{deviceId}/modules/{moduleId}/streams/{streamName} ： 裝置串流模組 |
注意
所有大小在計算時都會考量到以位元組為單位的承載大小 (通訊協定框架則會忽略)。 針對訊息 (具有屬性和本文)，則會以不限通訊協定的方式計算大小。 如需詳細資訊，請參閱 IoT 中樞訊息格式。
不同作業類型的訊息大小上限不同。 若要深入瞭解，請參閱 IoT 中樞配額和節流。
對於某些作業，您可以使用批次處理和壓縮策略來降低成本。 如需使用裝置到雲端遙測的範例，請參閱範例 #3。
範例 #1
某裝置每分鐘會傳送一則 1 KB 的裝置到雲端訊息給 IoT 中樞，再由 Azure 串流分析讀取。 解決方案後端會每 10 分鐘，在裝置上叫用方法 (具有 512 位元組的承載) 來觸發特定動作。 裝置會對方法回應 200 位元組的結果。
此裝置會耗用：
1 則訊息 * 60 分鐘 * 24 小時 = 每天 1440 則訊息 (用於裝置到雲端的訊息)。
兩則訊息 (要求加上回應) * 每小時 6 次 * 24 小時 = 288 則訊息 (用於方法)。
此計算所得出的總計為每天 1728 則訊息。
範例 2：
某裝置每小時傳送一則 100 KB 的裝置到雲端訊息。 此外，每 4 小時還會以 1 KB 的承載更新其裝置對應項。 解決方案後端每天讀取一次 14 KB 的裝置對應項，並以 512 位元組的承載來更新以變更設定。
此裝置會耗用：
25 (100 KB / 4 KB) 則訊息 * 24 小時 (用於裝置到雲端的訊息)。
一則訊息 (1 KB / 4 KB) * 每天六次 (用於裝置對應項更新)。
此計算所得出的總計為每天 606 則訊息。
解決方案後端會取用 4 則訊息 (14 KB / 4 KB) 來讀取裝置對應項，加上一則訊息 (512 / 4 KB) 來加以更新，總計 5 則訊息。
裝置和解決方案後端每天合計取用 611 則訊息。
範例 #3
根據您的情節，批次處理訊息可以降低配額使用方式。
例如，假設裝置的感應器每次讀取時只會產生 100 個位元組的資料：
如果裝置將 40 個感應器讀取批次處理到具有 4 KB 承載的單一裝置到雲端訊息 (40 * 100 個位元組)，則只會針對配額收取一則訊息的費用。 如果裝置每小時讀取感應器 40 次，並將讀取批次處理至每小時的單一裝置到雲端訊息，則每天會傳送 24 則訊息。
如果裝置針對每個感應器讀取傳送具有 100 位元組承載的裝置到雲端訊息，則會針對相同資料量的配額取用 40 則訊息。 如果裝置每小時讀取感應器 40 次，並個別傳送每則訊息，則每天會傳送 960 則訊息 (40 則訊息 * 24)。
您的批次處理策略取決於您的案例，以及資料的時間關鍵性。 如果您要傳送大量資料，您也可以考慮實作資料壓縮，以進一步降低對訊息配額的影響。
範例 #4
當您在 Azure 入口網站上開立支援要求時，系統便會執行您回報問題的特定診斷。 結果會顯示為要求的 [解決方案] 索引標籤上的深入解析。 其中一個這類深入解析會使用稍早資料表中斜體中的詞彙來報告 IoT 中樞的配額使用量。 是否傳回此特定深入解析，取決於您在 IoT 中樞上針對所報告問題所執行的診斷結果。 如果回報配額使用量深入解析，您可以使用資料表來交叉參考所報告使用量字詞，或與作業 () 所參考的作業。
例如，下列螢幕擷取畫面顯示針對裝置到雲端遙測問題起始的支援要求。
選取 [下一個解決方案] 之後，診斷會在 IoT 中樞每日訊息配額明細下傳回配額使用方式深入解析。 其會顯示傳送至 IoT 中樞之裝置到雲端訊息的明細。 在此案例下，會在 IoT 中樞上啟用訊息路由，因此訊息會顯示為裝置到雲端遙測路由。 請注意，不同 IoT 中樞上的相同問題可能不會傳回配額使用方式深入解析。 傳回的內容取決於該 IoT 中樞的活動和狀態。
