AWS 的 IoT解決方案 — Part 1

35 min readDec 22, 2021

本文中我們將介紹AWS IoT的技術概觀，並且討論將IoT Application放置在AWS IoT解決方案中的技術優勢是什麼，以及如何架構一般IoT Application架構在AWS中．最後我們會解釋針對在AWS IoT中各種會使用的開發，部署與管理工具．

針對IoT來選擇不同的AWS產品與服務

這一部分有三個重點，分別是:

IoT現在是一個快速成長的市場，而ＡＷＳ是一家IoT Application的市場領導品牌．因為AWS的 IoT深度解決方案可以無縫的與其他AWS服務整合，例如AI,多層次的資安，大規模運作的經驗，以及透明的價格．
AWS專注於幾個戰略細分市場，包括工業物聯網和聯網家庭，AWS的客戶包括大眾汽車、Vizio、Comcast、拜耳作物科學和 iRobot。我們會指出關鍵的 AWS IoT 差異化因素。
討論了從edge到outcome的合作夥伴價值鏈，以解釋AWS如何與廣泛的 AWS合作夥伴合作以幫助客戶加速採用．

根據分析師社區群的說法，未來 5 年是物聯網數據驅動的機遇。到 2025 年，IDC 預計全球將擁有 415 億台物聯網設備。預計這些IoT設備將生成 74.1 ZB 的物聯網資料，佔預計產生的總資料 (175 ZB) 的 42.3%。到 2025 年，全球物聯網技術支出預計將達到 1.2 兆億美元。

我們在 AWS IoT Core 上花費的每一塊元都會產生額外的多個下游 AWS 服務。這個乘數擷取了我們因採用物聯網而發生的費用 — 如我們們不採用物聯網，則支出超出了我們在 AWS 上的費用。

一旦我們的IoT設備連接到 AWS 雲端，我們下游的收入潛力將遠遠超出在 AWS IoT的費用。IoT是AI、機器學習、機器人、影像分析、移動和語音等新興技術的關鍵推動因素。它是這些新興技術的核心。訪問設備資料對於訓練 ML 模型、提供智能和提高業務效率至關重要。IoT代表了幾個我們專案的重要機會。

IoT展現的業務成果

沒有人只是購買IoT技術 — — 我們尋求的是業務成果。

雖然IoT是描述這個領域workload和技術的好術語，但這並不是我們考慮如何購買這些解決方案的方式。我們面臨業務挑戰，例如如何簡化運營和節省費用，如何使用資料獲得更好的洞察力，以及如何創造讓我們的客戶滿意的新方法。當我們考慮其業務的未來時，我們希望使用IoT資料來推動業務成長、開發新產品和服務或提高運營效率。

換句話說，IoT是推動數位轉型的基礎。 AWS IoT 幫助我們解決我們的業務問題。
這就是AWS IoT策略可以為我們做的事情：

為我們提供構建新服務和業務模型所需的智能
隨著時間的推移改進我們的產品和服務
通過了解我們的需求
提高業務運營效率
推動智能決策
幫助我們發展資料驅動的專業

這些優勢可以讓我們營收增長還有更高的運營效率。

IoT可以使用的場景

數十億台設備存在於我們的工廠、家庭、汽車、醫院和其他數千個地方。隨著設備的激增，我們越來越需要解決方案來連接它們，並收集、存儲和分析設備數據。

產業的

建構用於預測質量和維護的工業物聯網應用程序，並遠程監控操作。
預測質量分析從產業資料來源中提取可行動的見解，例如製造設備、環境條件和人類觀察到的資料。這些見解用於優化工廠輸出的質量。使用 AWS IoT，我們(產業製造商)可以建立預測質量模型，幫助我們改進的產品。更高質量的產品可提高客戶滿意度並減少產品召回。

資產狀況監控擷取機器和設備的狀態以確定資產性能。借助 AWS IoT，我們可以擷取所有 IoT 資料，例如溫度、振動和錯誤代碼。資料呈現設備是否處於最佳運行狀態。隨著可視性的提高，我們可以最大限度地利用資產並最大限度地提高我們的投資。

預測性維護分析擷取我們工廠設備的狀態，以在可能的故障影響生產之前識別它們。這會延長設備使用壽命、工人安全和供應鏈優化。借助 AWS IoT，我們可以持續監控和推斷設備狀態、運行狀況和性能，以即時檢測問題。

家庭連網

為家庭自動化、安全、監控和網路構建家庭連聯網應用程式。

使用 AWS IoT，我們可以讓任何設備連接到 Internet 並快速可靠地執行所需的操作。這些設備可以單獨工作，也可以與其他設備一起工作，以獲得集成的智慧家居體驗。此外，設備還可以與 Alexa 等語音服務配合使用，以獲得無縫的使用者體驗。

使用 AWS IoT 建構的門鎖、安全攝影鏡頭和漏水檢測器等設備可以使用機器學習 (ML) 來偵測威脅、採取行動並向屋主發送警報。 AWS IoT 使設備能夠以低延遲運行並在本地計算資料，而無需連接網路。

網路運營商會定期尋找新方法來幫助客戶發現、排除故障和修復家庭網路問題，包括 Wi-Fi 和有線電視連接。啟用 AWS IoT 的機上盒可以自動記錄網路診斷並將其主動發送到客戶服務中心，或允許客戶通過手機 App監控和排除網路健康狀況。

IoT是複雜與多面向的

IoT解決方案可能是複雜和多面向的。IoT不是單一的服務。其中必須包含的不僅僅是 AWS IoT。例如，IoT解決方案中涉及的其他 AWS 功能包括機器學習、AI、comouter vision、serverless和data lakes。

數位轉型可能很困難。我們已經嘗試過IoT。但很多時候，這些專案永遠還在試驗階段。

AWS IoT 可以承擔大量的作業，因此我們可以從試驗階段過渡到生產階段。我們消除了在企業中實施物聯網的複雜性。AWS幫助我們：

將任意數量的設備安全地連接到雲端
根據需要進行擴展，以便我們深入了解IoT資料
構建物聯網應用程式和服務
將我們的業務轉向物聯網

AWS IoT概觀

AWS IoT 提供廣泛而深入的功能，從edge到cloud，因此我們幾乎可以為各種設備上的任何use case建立 IoT 解決方案。由於 AWS IoT 與AI服務整合，即使沒有互聯網連接，我們也可以使設備更智能。 AWS IoT 內建於 AWS cloud中，可以隨著device fleets的增長和業務需求的發展而擴展。 AWS IoT 還提供全面的安全功能，因此我們可以建立預防性安全策略並立即回應應潛在的安全性問題。

廣泛而深入的功能
AWS 廣泛而深入，從edge跨越到cloud。我們幾乎可以為各種設備的任何use case建立IoT解決方案。通過與edge 服務和 AWS Lambda 的整合，設備可以在沒有網路連接的情況下運行。如果可以連接，我們可以連接 130 多種 AWS 服務以及第三方服務。

多層安全
IoT應用需要預防措施和主動監控，以及保持資料和設備安全的回應。 AWS IoT 包括預防性安全機制，例如device identity和authentication、加密以及對設備資料的access control。此外，AWS IoT 會持續監控和審核安全配置以符合資安的最佳實踐。

與AI完全整合
我們可以在AWS中建立、訓練和優化模型，然後將它們部署到具有 AWS IoT Greengrass 的設備，以便隨著事件的發展採取行動。 AWS IoT 通過將資料發送回AWS來不斷改進機器學習模型。

經過驗證的大規模經驗
AWS IoT 建立在高度可擴展、安全且經過驗證的雲上，主要在支援數千萬台設備和數十億條messages。

透明定價
AWS IoT用的是pay-as-you-go model，沒有最低費用或強制性服務使用。我們只需為我們消耗的運算時間和他們使用的功能付費，這可以顯著節省成本。

IoT的良性循環

與其在Stack中考慮 AWS IoT 服務，不如讓我們視覺化 IoT 平台中三種不同類型服務的循環。這被稱為IoT良性循環。以下是三種類型的 AWS IoT 服務：

Device software連接device並在edge操作它們。

我如何建立在edge運作並連接的任何類型的devcie到 AWS IoT？
如何將AWS cloud功能延伸到edge？
我如何知道我的設備可以與AWS IoT 配合使用？

連接和控制服務協助我們控制和管理現場設備。

我如何安全的連接我的資料，並大規模處理它們產生的資料？
如何大規模管理不斷增長的連接設備群？
如何確保我連接的設備保持安全？

分析服務提供資料服務以從資料中提取有意義的訊息來推動業務成果。

如何釋放曾經被鎖在工業設備中的資料？
如何從帶有雜訊的IoT資料中產生價值？
如何偵測複雜工業系統的變化？
我如何可視化地建立包含舊設備和AWS 服務的IoT Application？

IoT 核心技術

在這一部分我們會學習到簡單的描述一些通用的IoT概念，術語，與協定．我們還將了解哪些 AWS 服務和實踐主要在解決 IoT 業務目標和挑戰。

通用的IoT協定

我們將會介紹IoT三種常用的協定，分別是
MQTT(Message Queuing Telemetry Transport), HTTPs與WebSocket．

MQTT是一種用於連接設備的傳輸協定。它主要在最大限度地減少網路頻寬和設備資源的需求，同時還試圖確保可靠性和傳送保證。MQTT 為設備提供雙向通訊通道。與基於request-response的 REST-based system相比，這是一個優點。它允許與防火牆後面的設備進行通訊。 MQTT 協定還具有低延遲和low throughtput的特點，因此非常適合低頻寬環境 — — 甚至是行動網路。

MQTT 是一種輕量級、message-based protocol，其資訊按topic hierarchy結構組織。它使用publish-subscribe paradigm，而不是基於 HTTP 的request-response。

MQTT 通常使用 TCP，但它可以支持其他網路協議。它使用底層是 TCP 傳輸和安全措施，例如TLS。與broker的每個connection都可以指定 QoS)度量。MQTT 協定定義了兩種類型的網路實體：message broker和client數量。
Broker是一個服務器，它接收來自client端的所有message，然後將message路由到適當的destination client。 MQTT client是一種可以通過網路與 MQTT broker交互的設備，可以subscribe和publish 任何topic。

我們可以指定某些cleint只能與某些message交互。例如，下圖顯示的感測器在 sensor_data topic下publish並subscribe config_change topic。User可以訂閱或發布任意數量的topic。

上圖的第一步是，client連接Broker. client可以subscribe 任何message topic．第二步client 在 topic之下publish message．第三步Broker會forward message給所有subscribe這個topic的所有client．

MQTT的 message與 topics

MQTT message具有規定的格式以包含topic和payload。我們設計topics以符合他們的設備和data mapping要求。 MQTT topic使用小寫字母、數字和破折號。由於 MQTT topic區分大小寫，因此在設計 MQTT topic時應使用一組標準的命名規則(如下圖所示)。因此，我們在建立每個topic level時應僅使用小寫字母、數字和破折號。更多的MQTT協定可以參考此篇文件．

MQTT的QoS(quality of service)

MQTT使用了三種不同level的publish message,以保證message的送達：

在 QoS 0 中，broker 最多發送一條message，稱為 fire and forget。這是最快的方法，但最不可靠。 message被發送一次並且不被確認。
在 QoS 1 中，broker至少發送一條message，稱為確認交付(acknowledged delivery)。這保證message至少傳遞一次，但可能會重複。
在 QoS 2 中，message只發送一次，稱為assured delivery。這保證message只傳遞一次。這是最慢的方法，因為它需要message來在broker和client之間建立handshake。

下圖分別是QoS 0–2:

其他可用的協定

Message broker 支援cleints使用MQTT協定publish 和subscribe message，支援HTTP/S協定publish message。 IP v4 和 IP v6 均支持這兩種協定。message broker還通過 MQTT protocol over WebSocket protocol ．client連接到message broker的方式取決於所使用的協定。
HTTP/S 和 WebSocket 連接都通過 TLS 1.2 並使用 AWS Sigv4 signing algorithms進行身份驗證。
Signature Version 4 是向 HTTP 發送的 AWS request添加authentication information的過程。有關更多資訊，請參閱此文件．

一般性的通訊模式

IoT applications支援多種通訊場景，例如device to device、device to cloud、cloud to device、device to or from users。儘管模式的範圍各不相同，但大多數 MQTT 通訊模型都源自我們將在本部分中了解的 MQTT 模式。

Direct publishing pattern

Direct publishing communication pattern(如下圖)，也稱為點對點通訊，是設備在 MQTT 中通常如何發送和接收message的基本building block之一。
有兩種事使用單一 MQTT topic作為communication channel和broker來中relay message。接收事件的event subscribes一個 MQTT topic。發送message的事物publish到相同的已知 MQTT topic。這種方法在智慧家庭場景中很常見，最終用戶接收有關家中事物的更新。在下圖中，手機的App publish關於訂水壺topic的message。

Fan-out notification模式

點對點通訊不限於設備之間的一對一。 Fan out模式還用於一對多。在這種情況下，單一publisher可以使用每個設備不同的 MQTT topic發佈到各個設備。這種方法在notificatiob場景中很常見，管理員向特定設備發送不同的updates。在上面的範例中，維修服務使用一組點對點通訊以編程方式loop through設備清單並publish message。

廣播模式

廣播模式用於一對多訊息傳遞。廣播模式向大量設備發送相同的訊息。在一次廣播中，多個設備subscribe同一個 MQTT topic，並且sender publish一個message給這個被share多個設備的topic．廣播模式的典型用途是根據設備的類別或群組向設備發送通知。例如，氣象站根據設備的當前地理位置發送廣播訊息，而設備按位置分組。在此上面的範例中，廣播模式發送有關天氣topic的訊息。狀態中的所有車輛都subscribe這個message。根據車輛的當前位置，它可以忽略或回應訊息。

Fan-in (聚合)模式

Fan-in模式是一種多對一的通訊模式。這種模式與廣播模式相反。多個設備在一個shared topic上publish，只有一個訂閱者subscribe該topic。使用Fan-in模式，訂閱者俱有使用wildcard的附加能力，因為發布者都使用相似但獨有的 MQTT topic。

Fan-in模式通常用於促進將監控資料聚合到 IoT Application。 Rule engine可以應用user-defined rules來過濾有關特定topic的message，以減少不必要的message。

在處理gateway設備時也使用Fan-in模式。例如，智慧家庭可能管理 30 多台設備。屋主不會從gateway subscribe每個設備的每個shadow topic。如果這樣做，gateway將會有無法管理的subscriptions數量並超出連接限制。相反，我們將在雲端進行Fan-in，並且gateway將只會對到少數Fan-in topic的subscriptions。

IoT的網路安全

在這一部分我們會討論到IoT的網路安全，包括一般的設備連線，驗證機制，憑證，與金鑰．

TLS與交互身份驗證

重點在於確保traffic是安全且在client與server之間通訊是可信任的．具有交互身份驗證的TLS(Transport Layer Security)確保client和server之間的流量是安全和可信的。它非常適合不用靠identity provider login 的IoT設備。

TLS 有兩種configuration options。
Option1 — 是執行JITR(just-in-time registration)建立CSR(certificate signing request)，使用CSR建立X.509 certificate，在AWS中 activate certificate，然後建立權限並關聯certificate與權限。 certificate可以由多個設備共享，但最佳做法是每個設備使用一個key pair。這一切都是使用 AWS 作為CA(certificate authority)完成的。

Options 2 — 是更簡單的方法。它用在JITP(just-in-time provisioning)，而不是更複雜的JITR，後者需要infrastructure在設備連接時即時註冊、創建事物等。

Create keys與certificate的步驟

基本上包含以下三個步驟：

在AWS CLI/Console/API其中一個介面create key.例如以下用CLI的方式

aws iot create-keys-and-certificate --set-as-active --certificate-pem-outfile certs/certificate.pem.crt --public-key-outfile certs/public.pem.key --private- key-outfile certs/private.pem.key --region ap-northeast-1

2. Apply private key與certificate到設備中，並activate certificate．

3.最後register 這個device並attach IoT policies上去．

IoT Service

這一部分討論的是不同的AWS IoT服務，主要聚焦在device software, connectivity與control service還有分析服務．

Device software

主要分成下圖三種

Connectivity 與 Control services

連接與控制服務AWS提供了以下三種

分析服務

支援 AWS IoT的其他AWS服務

AWS的其他非 IoT服務同樣可以支援IoT服務之後的其他需求，如下圖所示：

連接與控制服務

在這一部分我們將更詳細的介紹 AWS IoT在這一方面的的技術細節，包括如何安全地連接IoT Devices，包護我們在porduce and consume的資料，管理大規模的的IoT資料．所以會使用AWS IoT Core/ IoT Device Management / IoT Device Defender這三種服務來完成上面提到的作業．之後我們會舉一個實際的connectivity and control service的範例．

AWS IoT Core提供了在IoT Device與AWS雲端之間一個安全的通訊(如下圖)．並包含了下列功能：

identity service and security — 提供身份驗證與授權
Device gateway — 安全且可以大規模的連結設備
Message broker — 處理與路由data message到Cloud
Rule Engine — 在device或雲端觸發actions
Device shadow — 保持設備狀態幫助間歇性連接
Device registry — 啟用自動設備註冊並追踪設備的身份

而AWS IoT Device Management能夠讓我們對IoT device進行整個產品的生命週期管理，從onboarding到 updates．AWS IoT Device Defender則可以讓我們稽核device configurations, 對資安的標準進合規管理，已達到降低風險的目的．

而上述説得這些功能可以讓我們實行以下的功能：

identity and registration
Indexing and searching
Logging and monitoring
Audits and alerts
Bulk actions
Secure access

AWS IoT Core

AWS IoT Core 可以達成以下要求

安全地連接數百萬台設備，以便它們可以與Cloud Application和其他設備進行交互
處理連接設備後產生大規模的資料
路由、處理來自連接設備的資料
使Application能夠與設備交互，即使它們處於離線狀態
與其他 AWS 產品和服務完全整合以建立更強大的物聯網
應用

IoT Core Components

AWS IoT 使有聯網能力的設備能夠連接到 AWS 雲端，並讓雲端中的Application與聯網設備進行交互。常見的物聯網應用式要嘛收集和處理來自設備的監控資料，要嘛啟動它。

AWS IoT 包括以下component：

Identity service提供authentication和authorization以管理設備授權和提供unique identities．
Device gateway將設備安全地連接到AWS 雲端和其他大規模設備群，以管理針對物聯網工作負載優化的連接。
Message Broker處理data message並將其路由到Cloud，以便在整個fleet之間進行可靠和快速的通訊。
Rule engine觸發IoT設備上的操作，以汲取大量資料並對其進行預處理，使其可用於其他服務進行分析、報告和可視化。
Device shadow使Application能夠與設備交互，即使它們處於離線狀態。
Registry 支持將設備自動註冊到device catalog，AWS 服務可使用這個catalog 遠端控制設備。

AWS IoT Core的identity service支援以下功能：

Root certificate authority (CA) 和client certificate，或讓 AWS IoT Core 為我們產生certificates
SigV4、X.509 和token-based authentication
通過即時註冊自動配置設備
為靈活和fine-grained的access control建立IoT policy
能夠將policy與identity或registry items相關聯
能夠大規模管理device authorization和提供unique identities
MQTT topic level的access control

Device和client必須擁有credentials才能與 AWS IoT 交互。進出 AWS IoT 的流量通過TLS發送。當資料在 AWS IoT 和其他 AWS 產品和服務之間移動時，AWS 雲端安全機制可以保護資料。

我們需要在 AWS IoT 中管理設備憑證（X.509 certificate、AWS credentials、Amazon Cognito identities、federated users和custom authentication tokens）還有Policies。
需要為每台設備分配unique identities並管理每台設備或每組設備的權限。
設備通過TLS 連接使用X.509 certificate或Amazon Cognito identities連接到AWS IoT。在研發過程中，對於一些呼叫 API 或使用 WebSockets 的應用程式，我們還可以使用 AWS IAM user和group或custom authentication tokens進行身份驗證。
使用AWS IoT 身份驗證時，message broker對設備進行身份驗證，安全地拮取設備資料，並授予或拒絕AWS IoT policies為設備指定的access permissions。
使用custom authentication tokens時，custom authorizer authenticates對設備進行身份驗證，並授予或拒絕我們為設備指定的access permissions使用 AWS IoT 或 IAM policies。
AWS IoT rule engine將設備資料轉發到其他設備或其他 AWS根據我們定義的規則提供服務。它使用 IAM 將資料安全傳輸到其最終目的地。

當device或其他client嘗試連接到 AWS IoT Core 時，AWS IoT Core server會發送設備用於對服務器進行身份驗證的 X.509 certificate。身份驗證通過 X.509 certificate chain的驗證在 TLS layer進行。

AWS IoT Core 要求明確信任每個certificate。在 TLS handshake期間，雙方（device和cloud）的身份通過各自的cert/key對進行驗證。此外，不信任的certificate chain允許 AWS 避免嚴重的語義問題，即chains of trust被視為“不可信”。但是，AWS IoT Core 繼續支援這些certificate．

AWS IoT 支持三種類型的identity principals進行device或client身份驗證：

X.509 client certificates
IAM users, groups, and roles
AWS Cognito identities

我們可在device, mobile, web, desktop與AWS CLI上使用身份驗證．

AWS IoT 允許我們定義custom authorizers，以便我們可以管理設備身份驗證和授權。為此，我們使用 AWS Lambda function將device credentials發送到我們的authentication service。

通常，AWS IoT 設備使用 X.509 certificate，而mobile application使用 Amazon Cognito identities。 Web 和desktop application使用 IAM 或federated users。 AWS CLI 使用 IAM。 IAM user、group和roles是在 AWS 中管理身份和身份驗證的標準機制。我們使用它們通過 AWS SDK和 AWS CLI 連接到 AWS IoT HTTP interface。 IAM roles還允許 AWS IoT 代表我們access 我們的aws account中的其他 AWS resource。
我們可以實施custom authentication。 custom authentication使用 HTTP publish operations或通過 WSS connections的 MQTT 來接收 HTTP header內的bearer token（例如 JSON Web token [JWT] 或 OAuth token）中的device credentials。

Authorization

是向經過身份驗證的身份授予權限的過程。我們使用 AWS IoT Core 和 IAM policies在 AWS IoT Core 中授予權限。

AWS IoT Core policies確定經過身份驗證的ientify後可以做什麼。經過身份驗證的identity由device、mobile application、Web application和desktop application使用。經過身份驗證的identity甚至可以是輸入AWS IoT Core CLI command的用戶。僅當identity具有授予其操作權限的policies時，這個identity才能運行 AWS IoT Core operation。

AWS IoT Core policies和 IAM policies都與 AWS IoT Core 一起使用來控制identity（也稱為principal）可以執行的操作。policies類型取決於用於向 AWS IoT Core 進行身份驗證的身份類型。

AWS IoT Core 操作分為兩組：

Control Plane API 允許我們執行管理任務，例如建立或更新certificate、事物、rule等。
Data Plane API 允許我們向AWS IoT Core 發送和接收資料。我們使用的policies類型取決於我們使用的是control plane API 還是data plane API。

Device gateway

這是用來橋接IoT device與AWS Cloud.我們後面會介紹IoT如何連接gateway並subscribe相關的message．

Device gateway安全地且大規模的將IoT連接到 AWS cloud和其他設備：

全面管理針對IoT workload優化的連接
1. 用於通過 MQTT 進行雙向通訊的長期連接，WebSockets、HTTPS
2. 通過 TLS 1.2 相互身份驗證的安全通訊
3. 每個設備 x509 certificate
每個設備和每個用戶的Fine-grained policies
1.具有即時註冊的自動設備配置
2. 例如，custom-fitted的加密晶片，如 Microchip ECC508，產生unique key chained到在我們 AWS account的 preregistered singer certificate中
受限設備的優化：
1.ECC(Elliptic-curve cryptography)key change and certificates
2.Maximum fragment length negotiation

在傳送資料的JSON payload範例內容如下：

Device gateway使設備能夠安全有效地與 AWS IoT 通訊。 IoT可以通過Device gateway相互通訊，即使它們使用不同的協定(如下圖)。

上面的範例說明了兩件事情 — — 一個連接的燈泡和一個控制單元(RGB) — — 連接到Device gateway。控制單元可以向Device gateway發布命令，燈泡可以subscribe 和監聽相關命令。

Message Broker

Message Broker是用於decoupled devices和application的可擴展的publish-subscribe broker。它支援：

Customizable topic space with support for wildcard topic filters
QoS0 and QoS1 messaging
JSON and binary payloads

Rule engine

主要能觸發一些action，包含了：

以低成本擷取大量資料，對其進行預處理，並將其提供給許多用於分析、報告和可視化的服務
使用內置函數轉換資料，用於數學、string manipulation、dates等
可以使用 SELECT 語法和 WHERE 子句
通過內聯 AWS Lambda instance 從device shadow、AWS ML 或外部來源獲取context來enrich data
通過將資料發送到 AWS service和第三方服務（如 Salesforce 等）來路由資料

Rule Engine

在 AWS 服務之間路由Device data (使用AWS SQS) 對messages做出回應
在 AWS EMR 中進行ML預測
使用 AWS Kinesis 分析streaming data
使用 AWS Redshift 檢查資料的長期趨勢
在 AWS DynamoDB 中及時索引資料

以下為一個rule engine的案例，當房間溫度大於78時就發出一個email通知

Rule engine評估發佈到 AWS IoT 的inbound message。然後，它根據我們定義的業務規則轉換message並將其傳送到另一個IoT或cloud。

以下案例例說明了以下規則：
• 評估控制單元發布的命令
• 確定命令是否為 B
• 如果命令是 B，則rule將消息轉換為 G 並將 G relay到燈泡

Rule engine還可以將message路由到Cloud endpoint，例如 AWS Lambda function或 DynamoDB table。
以下範例顯示了添加的第二條規則：

評估控制單元發布的命令
確定命令是否為 R
如果命令是 R，則Rule將message的副本傳送到三個端點 –DynamoDB DB table、Lambda compute function和用於向行動裝置推送通知的AWS SNS.

Device shadow

Device Shadow隨時會知道和控制設備的狀態 — — 它是所有命令和控制操作的主要功能。Device Shadow是 AWS IoT Core 的一部分，不需要使用額外軟體。

Device Shadow不是設備的digital twin，但它構成了digital form的一部分。
它回報給設備的最後已知狀態，例如燈泡最後已知的顏色是紅色的。
它可以更改設備的狀態，例如將燈泡的顏色更改為綠色。
可以使用MQTT 即時通知我們狀態變化。
可與離線設備非同步通訊。
可以使用設備 SDK 整合在設備上實作它。
可以使用Application的 REST API 與設備交互。

使用Device Shadow有助於避免以下問題：

直接發布 — — 開發人員通常想要這樣做，他們應該意識到其中的缺陷
設備離線 — — 設備永遠不會一直在線，IT人員必須注意，不要只在LAB環境中進行測試。
無順序message — — 在大量訊息的情況下，IoT message可能不照順序到達。

使用Device shadow進行命令和控制解決了message timing和傳遞可靠性問題。這可以導致更一致的狀態變動。

以下範例，Device Shadow配置有實際燈泡的顏色。當我們關閉燈泡時，Device shadow會記住實際燈泡的顏色(如下圖)。

AWS IoT 使開發人員能夠構建與互聯IoT交互的companion applications。
以下顯示了一個反映燈泡顏色的手機App。 App從不直接與燈泡通訊。相反，App使用 REST API 來讀取和設置燈泡的device shadow的狀態。

Device registry

這一個服務協助我們達成以下功能：

定義和編目設備以供 AWS 服務使用
進行簡單的搜索，範例：哪些設備是 2019 年生產的？
定義 ThingTypes 以實現跨屬性和policies的標準化設備，範例：本田和豐田屬於 ThingType 汽車。
定義group以實現更簡單的管理（運行作業、設置策略和等等），範例：汽車中的Sensors．

AWS IoT Device Management

我們可以使用 AWS IoT Device Management來追蹤、監控和管理我們的Device fleeys。在本節中，我們將了解 AWS IoT Device Management涵蓋的四個主要領域 — onboarding、organizing、monitoring和updating：

借助AWS IoT Device Management，我們可以批量加入和註冊大量設備
可以將設備組織成group並管理group policies。他們可以根據業務需求通過將group分配到層次結構來追踪、操作和管理設備。設備根據group hierarchies結構中assign的policies繼承訪問權限。
監控允許我們追踪和排除設備故障。
借助 AWS IoT Device Management，我們可以遠端更新設備上的轉體，並執行重新啟動或恢復出廠預設置。

我們只需點擊幾下即可批量加載IoT設備的連接。我們可以：

註冊設備信息，例如整個fleet的metadata、certificayes和policies
通過Console上傳或呼叫 StartThingRegistrationTask API 以註冊所有設
追踪註冊進度或下載已完成task 的report
註冊新設備或重新註冊設備（例如，輪換certificates）

我們可以了解其設備群的健康狀況和狀態。我們能：

根據設備屬性的任意組合找尋設備群中的設備，範例：“查找 2018 年之後製造的所有當前連接的firmware version為 1.3 的設備”
通過根據查詢動態update一群設備來自動化設備組織，範例：“將位於台北市的所有硬體版本 1.2 燈泡分群”
在Console中使用one-click activation

我們可以收集設備日誌以識別和修復問題。我們能：

基於每台設備或一組設備配置logging level
要對問題進行故障排除，選擇性提高整個子集的diagnostic levels故障設備
使用 AWS CloudWatch 配置告警和搜索日誌

我們可以在設備群上組織和觸發action。我們可以：

接收單個設備的status update以便在它們運作時監控update
運行一連串job以標準要批量update的設備組或要精確update的單一設備
控制部署速度並設置failure criteria以減少任何update的blast radius
在將作業發送到我們的設備之前對其進行Digitally sign jobs以保護設備免遭入侵

我們可以安全地access防火牆後的設備。我們可以：

使用 API 或Console打開和關閉tunnel
使用remote shell 或遠remote desktop operation access單一設備
使用 IAM 權限管理每個tunnel session的設備授權和session timeout可以達12 小時
通過 MQTT message自動接收每個設備的access token

AWS IoT Device Defender

AWS IoT Device Defender 可確保設備群的安全。借助 AWS IoT Device Defender，我們可以：

審核以驗證 IoT configuration是否安全
使用安全儀表板持續監控configuration以了解security posture
檢測異常設備群的異常行為
通過管理告警來了解告警紀錄的時間和內容
通過採取糾正行動和修復潛在問題來執行mitigation

我們可以驗證 IoT 配置安全性。我們可以：

根據一組內建的IoT security best practice audit我們的IoT資源
了解一組standard audit check如何作用在不同的IoT資源，如 Certificates/Policies/Connection settings/ Account settings
Schedule audits(例如每天或每週)或在易受攻擊的時期（例如設備部署）on-demand進行Audit．

我們可以識別IoT設備行為中的異常情況。我們可以：

為一個帳戶中的所有設備或一組具有相似行為特徵的設備建立security profiles
為安全指標和來自IoT設備的資料以及security profiles中的 AWS IoT Core 定義規則或基於統計的行為

當告警發生時，我們應該知道何時進行查驗以及查驗什麼。我們必須：

查看根據識別出的異常和audit結果產生告警
查看發送到 AWS IoT console、AWS CloudWatch 和 AWS SNS 的告警
檢查audit non-compliance或IoT設備的歷史和上下文資訊的行為異常檢測
查看設備或資源level的資訊
查看recommended actions以最大限度地減少潛在security issues的影響

我們修復潛在問題。我們可以：

採取緩解措施，修補潛在的安全問題並對IoT設備是有意義的。使用自automated action或建立custom action：如： Revoke permission(automated)/Revoke certificates(automated)/ Quarantine device(automated)/ Reboot a device / Push security fixes
使用 AWS SNS 自動執行custom action

未完待續…….