AWS IoT 物聯網系列部落格

當前物聯網環境中，裝置型別多種多樣，連線方式不一而足。為了幫助讀者更好的理解並運用 AWS IoT 相關服務，我們提供了一個完整的 IoT 起步指南，包含裝置的註冊及上線、裝置管理、使用者身份及許可權管理以及成本控制，通過這一系列的起步指南，也可以快速瞭解到 AWS IoT 服務如何與 Amazon Alexa 語音助手進行整合。AWS IoT 物聯網系列共8篇，本篇是該系列的第一篇，其他篇連結請在本文結尾處檢視。

背景介紹

在進行物聯網裝置連線時，每個裝置都需要通過訊息的形式與 IoT Core 進行資料互動。隨著訊息互動數量的增加，如果不對整體架構進行優化，很容易造成訊息成本的指數增長，甚至是不必要的浪費。本文結合 AWS IoT Core 的相關計費方式，探討潛在的成本優化模型，從而更好的幫助在有限預算下提升產業效能及使用體驗。

AWS IoT Core物聯網服務計費模型：

AWS IoT Core 服務的計費模型主要包括四個部分，每個部分獨立計費，使得成本優化的顆粒度更細。以下計費報價參考 AWS 美國東部區域的報價，詳細點這裡。

1.    連線性：

裝置閘道器負責維護 IoT 解決方案中的所有互聯裝置的會話。AWS IoT 裝置閘道器支援通過 MQTT、MQTT Over WebSockets 和 HTTP 實現的互聯裝置與 AWS 平臺之間的安全、雙向通訊。MQTT 和 HTTP 等通訊協議使公司能夠利用行業標準協議，而不必使用會限制將來的互操作性的專屬協議。其中連線費用與描述如下：

• $0.08每1百萬個裝置/每分鐘

每個裝置以全年每時每刻連線計算共525,600分鐘（60分鐘*24小時*365天）計算，每個裝置的連線一年的總費用為$0.042

• PING 訊息包括 MQTT PINGREQ，MQTT PING RSP 訊息沒有費用。

2.    收發訊息:

物聯網裝置連線時，裝置的狀態需要通過訊息的形式與 IoT 平臺進行資料互動。AWS IoT 訊息代理就是這麼一項釋出/訂閱訊息的代理服務，可是與 IoT 裝置相互發送和接收訊息。在與 AWS IoT 通訊時，客戶端（裝置）將經過編址的訊息傳送到 Sensor/temp/room1 之類的主題。進而，訊息代理將訊息傳送到已註冊接收該主題訊息的所有客戶端。傳送訊息的操作被稱為釋出。已註冊接收該主題篩選訊息的操作被稱為訂閱。其中訊息型別包含：

• 裝置發到 AWS IoT 服務的訊息數量
• AWS IoT 發到裝置的訊息數量

每條訊息以5KB長度計費，多於5KB，等價到多個5KB進行費用收取，例如8KB的訊息，按照2條5KB訊息收取費用。每條訊息長度最大128KB

3.    裝置影子與設備註冊:

Device Shadow 服務可以為您連線到 AWS IoT 的每臺裝置在雲中保留一個“影子”。無論該裝置是否連線到 Internet，您都可以使用該影子通過 MQTT 或 HTTP 獲取和設定裝置的狀態（呼叫 AWS IOT API 中的 GetThingShadow 或者 UpdateThingShadow）。每臺裝置的影子都由相應事物的名稱唯一標識。具體請參考“適用於 AWS IoT 的 Device Shadow 服務”

裝置影子與設備註冊費用如下：

• $1.25每1百萬個裝置影子操作
• $1.25每1百萬個設備註冊操作
• 資料大小以1KB 為單位進行收費

4.    規則引擎:

收到 IoT 裝置的訊息之後，AWS 將對訊息進行資料儲存，分析等操作。這個操作由規則引擎來觸發。

AWS IoT 規則由 SQL SELECT 語句、主題篩選條件和規則操作組成。裝置通過將訊息釋出到 MQTT 主題來向 AWS IoT 傳送資訊。利用 SQL SELECT 語句，您可以從傳入的 MQTT 訊息提取資料。AWS IoT 規則的主題篩選條件用於指定一個或多個 MQTT 主題。當與主題篩選條件匹配的主題收到 MQTT 訊息時，規則將被觸發。藉助規則操作，您可以獲取從 MQTT 訊息提取的資訊並將其傳送到其他 AWS 服務做儲存與分析等。規則操作是針對 Amazon DynamoDB、AWS Lambda、Amazon SNS 和 Amazon S3 等 AWS 服務定義的。使用 Lambda 規則，您可以呼叫其他 AWS 服務或第三方 Web 服務。有關規則操作的完整列表，請參閱 AWS IoT 規則操作。規則引擎的觸發與執行費用如下：

• $0.15 每1百萬次規劃引擎觸發
• $0.15 每1百萬次規劃引擎執行
• 每條觸發的訊息以5KB為單位收取費用，多於5KB，以多條5KB進行計費

費用計算案例:

1.  如下以10,000臺裝置為例，來計算 AWS IoT 服務收費，例子中每臺裝置操作包括：

• 每5分鐘 Ping 主服務一次，全年保持活躍
• 約每30分鐘傳送1條訊息，每天共傳送50條訊息，每條訊息1KB
• 約每30分鐘收到1條訊息，每天共收到50條訊息，每條訊息1KB
• 每天裝置影子100次更新，訊息容量1KB
• 每天觸發規則引擎100次，執行100次

a.  每個裝置計算過程如下:

• 連線時長：
  • 全年保持活躍，連線時間共525,600分鐘（60分鐘*24小時*365天）
• 訊息數：
  • 發50條，收50條，共100條，每條1KB，按5KB計算
• 裝置影子與設備註冊訊息：
  • 每條訊息都更新裝置影子，共100條，每條1KB
• 訊息引擎觸發數：
  • 共觸發100次，執行100次

b.  10,000（1萬）臺裝置，每臺裝置每月費用，每年費用，裝置總年費用按表格統計如下：

由下圖可以看出連線方面的費用比較固定，訊息，裝置影子，引擎在收費專案中所佔比例比較大。那麼在使用當中，如何調整這3個專案，來優化費用比較？

費用優化：

下面只是給出一個優化思路，真正優化方案的前提，還是以使用者實際需求出發

思路1：調整訊息資料與內容：

1. 假設裝置狀態在30分鐘內改變非常少，如夜間的家用 IoT 裝置如淨水器、掃地機器人等。可以調整（減少）資訊傳送間隔，聚合資訊長度，比如上例中，可以每隔60分鐘傳送一次資訊，或者轉為終端觸發式（啟動或者關閉前傳送）。減少傳送次數。如在裝置啟動後與關閉前傳送訊息。
2. 豐富傳送內容，對於例行訊息，可以在觸發式，一起傳送到平臺，比如過去3條聚合在一起，成為1條3KB 資訊，傳送總數減少，每條容量5KB 內不額外收費。如 IoT 裝置淨水器在開啟時連線3條訊息傳送開水時間，濾芯狀態，是否漏水等，可以合併為一條一起傳送。
3. 由於 IoT 訊息多與裝置相關，有一些與裝置應用相關的資訊資料，如裝置採集的影象與視訊等，可以由裝置其它通道傳入到雲端儲存進行儲存，如檔案儲存到 AWS S3，流式資料可以通過 AWS Kinesis 客戶端儲存。

思路2：關於裝置影子

1. 裝置影子的主要目的是方便雲端在裝置離線時進行管理。所以有關此類狀態資訊會發給裝置影子，相應的，不需要此功能的，可以不傳送給影子訊息主題。以節省費用。比如家用電器接入 WIFI 之後網路暢通場景。可以減少裝置影子使用。
2. 舉例而言，對100條訊息進行分類，以其中50條不需要裝置影子為例。

思路3：細化規則引擎邏輯，消除訊息引發的規則引擎的重複判斷與執行。

1. 合併規則引擎執行，比如具有 IoT 功能的家用電器發訊息到 IoT 規則引擎後，對某個符合條件訊息的規則進行以下動作
   • 本條訊息儲存到 AWS S3 物件級儲存中
   • 本條訊息儲存到 AWS DynamoDB 方便展現
   • 本條訊息觸 AWS SNS 進行通知或者報警
   • 本條訊息啟用 AWS Lambda 進行復雜邏輯判斷，比如是否觸發購買提醒等
2. 對於上述動作，可以由最後一條 AWS Lambda 執行邏輯程式碼中寫入前4條邏輯，由 Lambda 來完成訊息儲存到 S3，寫到 DynamoDB,判斷是否 SNS 通知報警等。這樣觸發由過去5條轉為1條，節約成本。AWS Lambda 相關文件點選這裡，關於 Lambda 的限制文件參考這裡

以此思路優化之後，費用減少近54%（使用者請以實際使用為準）如下：

參考文件:

本篇作者