AWS IoT 快速上手

當我們打開 AWS Console，我們可以在服務列表中的 Internet of Things 分頁，看到整排的 AWS IoT 服務，常常不知道從何開始。這邊我們先把 AWS IoT 服務分成三大類，分別是 AWS IoT 裝置軟體、AWS IoT 連線與控制服務，以及 AWS IoT 分析與串流服務。接下來我們會花一點篇幅，快速向大家導覽，AWS IoT 平台上提供的哪些功能編成。

在裝置軟體的部分，AWS 提供了開發團隊幾種跟 AWS IoT 平台串接的軟體工具，包括 FreeRTOS、AWS IoT ExpressLink、AWS IoT Greengrass，以及 AWS IoT Device SDK。
主要應對四種應用類型。第一種，目標開發裝置為 MCU，可以選擇採用 FreeRTOS 或是在既有韌體中整合 AWS IoT Device SDK，常見如感測器、智慧家電的 IoT 遠端控制模組，以及智慧穿戴裝置等。第二種，目標裝置為 MPU，運算能力較強，並且運行 Linux 或是 Windows 作業系統者，可以考慮整合 AWS IoT Device SDK 到自行開發的應用程式當中，或者是在作業系統中運行由AWS 開發的應用程式：AWS IoT Greengrass；Greengrass 除了可以透過 Component 的模組管理方式，去運行 MQTT Client 與 AWS IoT Core 進行連線通訊，也可以作為設備端應用程式的發布管理工具，甚至能作為 Local 網路中的 MQTT Message Broker 這樣的角色，常見如工業閘道器、智慧家庭應用中的 Hub，等等角色。第三種，則是當我們擁有一個既有的裝置，但之前尚未具有聯網能力，在這種情境下，可以透過串接 AWS IoT ExpressLink 這顆已經與 AWS IoT Core 做好整合的 Wi-Fi Module，快速的建立連線能力並且直接與 AWS IoT Core 進行連線，就可以展開 IoT 平台的建置與部署。第四種，透過 AWS IoT Device SDK 整合於系統監控軟體當中，協助做為資安監控，能電源使用效率紀錄等等，等純軟體客戶端使用情境。

AWS IoT 平台，在裝置連線與防護管理上，提供了三大模組，包括了 AWS IoT Core 作為裝置連線的 Gateway，並提供裝置驗證授權的機制。而當裝置順利連接上 AWS IoT Core 之後，AWS IoT 平台提供了包括裝置管理以及裝置防護的模組，可以讓開發團隊透過的流程，即可啟用，掌握包括裝置的連線狀態掌握，裝置端 OTA 更新，以及裝置行為異常的監測與排除。

AWS IoT Core 提供了多數 IoT 裝置與平台開發人員所需要的，可以快速建立，並能自動化擴展連線量能的一個 Message Broker 端點，讓裝置透過安全的方式進行認證並建立連線，從而開始收送資料與指令的任務。而因此 AWS IoT Core，也就是多數人接觸 AWS IoT 平台時，會第一個開始使用的服務。

AWS IoT Core 提供不管是感測器、制動器、嵌入式系統、智慧型裝置或穿戴式裝置等連線裝置，可以透過 HTTPS、WebSocket 或是 MQTT 甚至 LoRaWAN 的多樣化Protocol，來安全的建立連線。AWS IoT Core 作為連線裝置 Gateway，可在連線裝置及雲端與 Mobile App 之間進行安全、低延遲、低成本的雙向通訊。AWS IoT Core 還包含Rule Engine，可以在訊息抵達 AWS IoT Core時，掛載特定的規則，即時的進行資料過濾甚至觸發資料處理元件，並且提供 No Code 的訊息轉導設定，讓 IoT Core 收到的資料，可以非常輕易地就被送到 Downstream 服務像是 DynamoDB、Kinesis、Lambda、SNS、SQS、CloudWatch、OpenSearch 甚至其他非 AWS 服務，透過 HTTP 的 Protocol 派送。透過這樣的機制，可以加速開發後續的資料分析，追蹤等等應用加值。

而透過 Device Registry 以及 Device Shadow 等裝置 Metadata 儲存服務，可以做到裝置狀態的描述，以及裝置狀態的同步。尤其 AWS IoT Core 中提供的 Device Shadow 功能，透過 REST API 讓 Mobile App 或是 Web 端應用程式，可以讓我們不必直接對邊緣裝置進行查詢，應用程式開發團隊，不用應對裝置端多樣化的 Protocol，或是邊緣裝置所在網路環境的不穩定，只需要使用單一且高可用的 REST API 方式，就可以取得裝置最後對雲端更新的狀態，另外可以透過非同步的方式，在雲端操作裝置的狀態設定修改，由 Device Shadow 功能，在裝置與 AWS IoT Core 連線暢通時，進行裝置狀態上傳更新，與裝置命令的下載。

而裝置與 AWS IoT Core 間的通訊，透過 X.509 client certificate、AWS IAM 登入權限，或是透過 AWS Cognito 進行的第三方身份驗證，提供連線身份的安全驗證，雙向認證，與傳輸資料的加密。AWS IoT Core 的Authorization 機制，也提供了精確的授權隔離方式，來確保裝置間，使用者間，資料傳輸與使用的隔離性。

AWS IoT Device Management 服務，可以讓開發團隊，快速的建構 IoT 裝置的大規模註冊、分群組織、監控及遠端管理這些裝置的應用服務。 AWS IoT Device Management 的主要提供了以下幾個功能：

* 大規模裝置部署
* 裝置索引建立與查詢
* 啟動差異化的裝置連線 Logging
* 裝置任務派送
* 裝置遠端安全連線通道
* FleetHub 隨開即用裝置管理網頁介面

AWS IoT Device Defender 是針對連接 AWS IoT Core 的裝置，提供的一種安全防護模組。透過設定週期性的持續 IoT 裝置端組態監測，以及針對 IoT 使用情境下，裝置端與雲端平台端的多項指標，來去建立裝置行為的 Baseline，可以用條件式或者機器學習方式做到裝置異常行為的偵測。AWS IoT Device Defender 可以讓物聯網平台維運團隊，輕易地針對裝置做大規模的組態稽核，並且快速找到行為出現異常偏差的裝置，快速建立裝置清單，透過 OTA 方式派送修正程式碼，或是改正組態，讓物聯網產品保持在安全的使用。這些稽核與偵測結果，都能通過告警的信號，做到自動化的流程啟動，或是維運團隊通知，更為迅速、自動化的安全防禦機制。裝置的安全監測結果，都能跟前述的，裝置集群管理服務做整合，可以利用裝置集群的查詢，快速建立裝置清單，並進行威脅定位與排除。

隨著科技與邊緣裝置算力的提升，影像感測器也愈發進步，例如：網路攝影機，不但解析度愈來愈高，甚至來可以在邊緣端進行大量的機器視覺運算。而眾多的媒體影像串流資料，需要包括即時的影像上傳儲存，而有些即時影音設備，像是智慧家庭使用的門鈴，可以與手機應用程式做低延遲的雙向影音與訊息互傳。

Amazon Kinesis Video Stream 服務提供了包括 KVS Producer SDK 以及 GStreamer 的 sink 外掛元件：kvssink。協助有需要的開發團隊，可以快速導入，將手機端或是網路攝影機端的影音串流，上傳到 KVS 服務所提供的 Video Channel，資料的 Retention Period 可以從一小時，到目前最長為十年。 

( 參考連結：https://docs.thinkwithwp.com/kinesisvideostreams-webrtc-dg/latest/devguide/kvswebrtc-sdk-c.html )
( 參考連結：https://docs.thinkwithwp.com/kinesisvideostreams/latest/dg/producer-sdk.html )

AWS IoT SiteWise 服務，可以說是 AWS IoT 在工業物聯網當中，針對數位分身解決方案，底層所需要建立工業設備資訊進行收集、儲存、關聯與階層概念建構，以及可視化，所提供的解決方案。可以應對大量感測器資料串流，並且橫跨多個生產場址，可以建立針對單一設備、生產線上站點、工廠、甚至跨國型生產企業，建立其生產效率監控，設備稼動率的平台。

AWS IoT SiteWise 可以透過工業閘道器上整合的 SiteWise Connector，去抽取常見工業通訊Protocol，例如：OPC-UA 的伺服器資訊，或者與應用程式整合，利用 MQTT 或是 REST API 的方式，將生產現場的感測器資料串流，上傳與儲存。

透過 AWS IoT SiteWise 的導入，可以減少大量維運與開發成本，就能建立服務高可用且資料高持久性，並快速調用針對機器設備管理所需要建立的設備關聯與建模，以及內建的數學公式，打造可視化的雲端 SCADA 應用程式。

而 AWS IoT SiteWise 也提供了快速啟用的網頁應用程式，讓開發團隊可以快速利用網頁Dashboard 的方式，驗證設備感測器與稼動率計算結果的驗證。 

AWS IoT TwinMaker 從字面上就可以看出他與數位分身 ( Digital Twins ) 的關聯性，他除了可以直接使用前述的 AWS IoT SiteWise 內所儲存的設備數位模型，並且可以透過第三方資料擷取的連接器，去抽取更多企業內部的資料源，打造企業 High Level 的企業級數位分身，並提供 3D 的場景建模，讓整體數位分身的使用者體驗，更為直覺。另外TwinMaker還提供了線上的 3D 模型場景編輯器，讓我們可以隨需的使用，建立客製化的數位分身 3D 互動式 Dashboard。

這是針對 IoT 裝置數據搜集之後的 ETL pipeline。大多數物聯網裝置所提供的資訊，都非常原始並且難以閱讀，AWS IoT Analytics 提供了資料的 Pipeline，讓資料分析團隊，可以透過這個 Pipeline 對資料進行預處理、資訊補充、並且提供資料儲存的節點，建立資料集，提供後續包括 BI 工具，或是機器學習團隊的取用。

AWS IoT Events，顧名思義可以利用 IoT 裝置提供的資料，進行事件的觸發，可以做到複雜的資訊判斷進而產生有意義的事件做後續流程的觸發。AWS IoT Events 的 Console，提供了網頁版介面，讓開發團隊易於建立事件偵測的模型。而當事件成功產生後，就可以透過 Pub / Sub 的 downstream 服務例如 SNS，建立處理流程。

( 參考連結：https://docs.thinkwithwp.com/iotevents/latest/developerguide/iotevents-detector-model.html )

以下我們會集中在，當要開始導入 AWS IoT 平台時，所需要首先面對的 AWS IoT Core，去完成包括：裝置連線與驗證的機制確認、裝置部署流程的設計、裝置授權與資訊隔離、裝置狀態與描述、資料的預處理與 AWS 其他服務的串接，以及裝置連線評估工具，與跨區域災害復原架構設計。

AWS IoT Core 服務擔負了所有裝置進行 MQTT  以及 HTTP 通訊的工作，首先 AWS IoT Core 會在裝置連線階段，提供裝置 authenticate 的方式，包括 X.509 client certificate，或是Signature V4 的方式，而在 Protocol 的選擇上，可以透過 MQTT / MQTT over WebSocket / HTTPS 的方式。下表提供目前利用 AWS IoT Core 做裝置通訊時，可以選擇的 Protocol，以及其可以支援的裝置驗證方式，以及所需要的 Port。要注意的是 HTTPS 的方式僅能提供Publish，若在 Web client 想要做到訊息的 Pub/Sub 雙向通訊，可以選擇 MQTT over WebSocket 的 protocol 來進行串接。

(參考連結：https://docs.thinkwithwp.com/iot/latest/developerguide/protocols.html)

當我們了解了 AWS IoT Core 提供的連線與驗證方式後，接下來要確認裝置部署的流程。通常裝置端，我們會採用 X.509 的方式，進行裝置的連線。舉例來說，一個終端使用者購買了一台家用智慧監控攝影機，當攝影機首次設定好網路資訊，連接上網路，此時智慧監控攝影機需要對其對應的後端平台做首次連線。

而這個憑證是如何被安裝到設備上，這就是我們在裝置部署的流程上，需要考量到的。

又或是當我們已經有建置好的平台，而目前裝置上也已經有既有且無法更換的 X.509 憑證，在做裝置的連線驗證，是否可以直接利用既有的 X.509 憑證，來做 AWS IoT Core 的連線並通過驗證。

針對 X.509 裝置端憑證的驗證方式，AWS IoT Core 提供了多種 Device Provisioning 的機制，選擇前，可以先確認裝置生產製造或是配送流程上可以如何搭配。AWS IoT Core 針對裝置安全的最佳實踐準則，會建議每一台連線裝置，都要有其獨立的裝置憑證，以確保裝置授權上的精細度，以及當裝置出現疑似被滲透的狀況時，可以透過裝置憑證授權的終止，並搭配裝置憑證的更新，來達到物聯網應用上的安全性。以下講述裝置部署的流程，都是基於要做到每一台裝置會取得獨立裝置憑證的情境，來進行說明。

此種情境，是裝置憑證一律在出貨前，就在產線流程上，被安裝到設備內，這個情境下，又細分成產線流程可以為裝置燒錄個別的裝置憑證，以及只能統一燒錄一種憑證的狀況。

第一種狀況，可以利用 AWS 提供的 API，進行大量裝置憑證的產生並且完成對 AWS IoT Core 的註冊。透過產線流程，將每一個個別的裝置憑證，安裝燒錄到裝置上。

而第二種狀況，當裝置生產流程，只能為裝置安裝統一的裝置憑證，但在終端客戶要開始使用時，要能替換成個別的裝置憑證，此時可以利用 Provision by Claim 的機制，先在裝置上統一燒錄統一一組用於驗證的憑證與對應的私鑰，當裝置售出後，首次要進行設定部署時，這組統一的憑證與私鑰，就會觸發 Provision by Claim 的機制，幫裝置產生獨立的裝置憑證與其對應的私鑰，待裝置下載後，即可利用個別獨立的憑證與私鑰，對 AWS IoT Core 進行連線。

( 參考連結：Provision by Claim )
( 參考連結：Create Device Certificate )

這種情境，常見於消費性電子產品，回家做首次設定時，或是商用設備，由專業的安裝團隊進行現場的運送與設定時。這種情境，我們可以利用 Provision by Trusted user 的方式，透過例如終端消費者的手機 APP，或是安裝技師的安裝軟體等，在進行帳號登入後，經由 APP 或軟體，下載裝置個別獨立的裝置憑證與對應私鑰，在此時安裝到設備中。

( 參考連結：Provisioning by trusted user )

AWS IoT Core 提供了將裝置現有 X.509 憑證註冊的功能，可以在正式切換到 AWS IoT Core 之前，先行透過 AWS IoT Core 的 API，將憑證註冊過來。

(參考連結：aws iot CLI register-certificate-without-ca )

而裝置假設擁有 TPM 模組，由於私鑰是由 TPM 模組所保管，需要利用 TPM 所提供的 API，建立 CSR，並透過開發團隊自己的 Root CA 進行 X.509 的簽發。詳細做法可以參考 AWS IoT Device Management Workshop 所提供的參考範例 ( 參考連結：Bring Your Own CA )

( 參考連結：https://docs.thinkwithwp.com/iot/latest/developerguide/iot-provision.html )

( 參考連結：https://docs.thinkwithwp.com/whitepapers/latest/device-manufacturing-provisioning/device-manufacturing-provisioning.html )

最後也提供一份 AWS 針對裝置製造團隊，所提供的 X.509 裝置憑證在生產製造與部署流程的參考白皮書。
( 參考連結：Device Manufacturing and Provisioning with X.509 Certificates in AWS IoT Core )

當我們完成了前述的裝置部署，讓裝置取得裝置憑證後進行裝置連線與驗證，接著很重要的一步，是進行裝置的授權。例如當終端消費者，啟動訂閱後，我們才允許其獲得設備管理的資訊，例如裝置在線資訊，我們此時才允許設備對 AWS IoT Core 進行 connect 的動作，這部分可以透過 AWS IoT 所提供的 Policy 權限來進行管控。

由於在物聯網情境下，裝置的數量有機會非常龐大，所以直接為一個一個裝置去客製化 IoT Policy 是非常耗時的。 AWS IoT Policy 提供了方便的變數，可以讓我們依據連線的對象，快速套用並限縮其可使用的後端資源。

舉例來說，憑證內的資訊，例如：憑證簽署者的資訊，或是內含的序號值；或者是憑證所綁定的 Thing ， Thing 所被定義的 metadata 值，例如：Thing 的名稱或是種類。另外連線時使用的 MQTT Client ID，也是可以利用的 Policy 變數。

( 參考連結：AWS IoT Core policy variables )

如同會員系統，除了會員的帳號密碼作為認證之外，我們會對會員進行姓名、性別、生日、年齡、居住地，等等資訊，進行記錄描述。同樣的，對於物聯網裝置，我們也會需要對他進行描述，例如他的硬體版本，或是規格描述等資訊。而 AWS IoT Core，提供了 Thing 這樣一個概念，讓我們可以用一個虛擬的物件，去描述安裝了裝置憑證的設備，並提供資訊與權限的綁定。

AWS IoT Core，提供了兩個功能：Device Registry / Device Shadow，讓我們對於靜態以及動態的 Metadata，做到儲存與同步。免除要自行建置資料庫與打造同步流程的時間，可以直接透過 API 的方式串接前端網頁或是手機 App，讓不管是裝置維運團隊，或是一般消費者，都可以即時了解設備的狀態。

( 參考連結：Managing devices with AWS IoT )
( 參考連結：AWS IoT Device Shadow service )

裝置透過 AWS IoT 平台收集資料，常見的情境，包括了資料儲存，資料處理，資料分析，與發佈與訂閱。當裝置與 AWS IoT Core 連線，並且通過認證取得授權後，就可以開始發送訊息，當訊息抵達 AWS IoT Core 的 Message Broker，除了 Subscriber 直接訂閱取得訊息的場景之外，其他的應用多半需要將訊息轉送到下一站，例如資料庫、Queue、日誌系統、或是資料分析平台。

AWS IoT Core 提供了 Rule Engine 的功能，可以將自訂的規則，掛載到指定的 MQTT Topic 上，當指定的 Topic 收到訊息時，規則內定義的 SQL 語句，可以對資料進行Filter，並指定相對應的 action，例如：寫入 DynamoDB、寫入 OpenSearch 等，減少這些服務間整合的複雜度。

( 參考連結：Rules for AWS IoT )
( 參考連結：AWS IoT SQL reference)

此類的資料轉導工作，目前支援以下幾種 AWS 原生服務，請參考下圖。

其中我們有看到 HTTP 的 Rule action，這項 action 可以協助我們去將資料，轉導到第三方系統的端點，或是 Webhook，例如：自建的系統，不管是在第三方雲平台或是本地機房內，都可以透過標準的 HTTP Protocol 進行轉發。而 Salesforce 也已經被整合可以直接收到轉導的 IoT 訊息。

( 參考連結：AWS IoT rule actions)

AWS IoT Device Advisor 提供開發團隊在導入 AWS IoT 平台時，驗證裝置與 AWS IoT 平台功能模組的雲端測試工具，團隊可以依據所要導入的 AWS IoT 功能，建立 Test Suites，作為產品開發的 CICD 環節。感興趣的讀者可以參考趨勢科技與 AWS 所共同發布的 Blog：How Trend Micro improved their velocity and agility using AWS IoT Core Device Advisor，看看趨勢科技團隊是如何將 Device Advisor 導入開發流程當中。

另外 AWS 與硬體合作夥伴，透過 AWS Partner Device Catalog 的平台，建立了硬體設備的生態系，而這些設備在上架 AWS Partner Device Catalog 目錄 之前，也都會先透過 AWS IoT Device Advisor 所提供，針對 Device Qualification Program ( DQP ) 所設計的 Test Suite 進行驗證並產生驗證報告，作為上架流程的一環。

AWS IoT 的災難復原架構，是針對客戶的 IoT 平台關聯到其關鍵系統時，需要做到跨 AWS Region 等級的災難復原，例如：東京與奧勒岡。參考本篇架構的建置，可以做到自動化的 AWS IoT Core 端點狀態檢測，並且保持主要區域與備援區域的裝置資料同步，當主要區域出現服務不可用的狀況時，切換至備援區域，做到整體服務的高可用。原生單區域的 AWS IoT 平台，會利用 AWS Region 底下的多個區域，建立高可用的架構，可以應對絕大多數情況下對於高可用的要求，並且同時保持成本的優化與彈性。

( 參考連結: Disaster Recovery for AWS IoT ）

AWS IoT 除了協助全球多家知名企業建立物聯網解決方案之外，在台灣也有多家不同產業的實際應用案例。以下精選台灣客戶的使用案例。另外，全球案例請參考 AWS 官網 : https://thinkwithwp.com/tw/iot/customers

趨勢科技採用 AWS IoT 平台來應對數百萬個邊緣端 agent 的聯網需求，透過趨勢科技的 VP of Product Management 在 AWS re:Invent 2022 大會上與大家分享的 Why AWS IoT，讓大家了解，AWS IoT 平台的擴展性，對於像趨勢這樣擁有數百萬連線端的應用平台，所帶來的優勢。

* AWS re:Invent 2022 - Unlocking innovation: Differentiate your product with new IoT features (IOT201)：https://youtu.be/9gml6GKhGHc?t=1912

微電能源在台灣開發與管理數百個太陽能案場， 利用 AWS IoT 與其他服務打造一個由底層串接到現場監控箱等設備的軟硬體結合技術平台，將分散各地的光電案場、太陽能板、電動車/充電樁、儲能設備等，做最有效率的數據管理與利用，以貫徹「 太陽能即服務」（Solar as a Service）的任務。

* 運用全代管無伺服器 AWS 服務，微電能源打造低成本無門檻完美微電網
* 如何透過資料驅動協助製造業創新與永續轉型

昶懋國際與 AWS 合作多年，從單一的檢測設備，轉型成為智慧化電池管理系統服務商，打造結合電池測試、電池充電與雲端服務三位一體的智慧化管理平台，利用 AWS IoT 建立雲端管理平台，對已出廠的電子設備或載具(各式車輛)，內部電瓶狀態、電量、電瓶壽命等做有效的數據蒐集、管理與分析，提供多元服務給其全球客戶。來聽聽他們的總工程師 William Hsieh 在 AWS 新世代基礎設施線上研討會上分享如何利用 AWS IoT 打造物聯網電池管理系統。 

Turing Drive 透過與 AWS IoT Lab 物聯網實驗室的合作，利用 AWS IoT Core 與 AWS 雲端服務，搭建其自動駕駛車輛的數位基礎建設，對於運行數據包含車輛、路口、影像等巨量資料收集上雲, 進行有效率的儲存與梳理，將複雜的道路環境資訊再利用，持續地進行自駕車的路線優化與設備載具的管理。 來看看 Turing Drive 執行長 沈大維在 AWS 領袖觀點上的分享 : https://www.youtube.com/watch?v=rUclyZOiovc

AWS 在台灣不僅有完整的技術架構師團隊，還有後端技術支援團隊以及具備產業經驗的顧問與客戶服務團隊，可一起協助您針對不同的物聯網應用打造適合的 IoT 平台，以及在各階度與場景下進行應用的討論與架構規劃。除此之外，AWS 致力與您攜手搭建 IoT 生態圈，除了平台與軟硬體的技術合作，我們也希望邀集在各個場域開發 IoT 產品或是提供應用解決方案的夥伴與客戶們，透過我們既有的協銷與推廣方案，加入 AWS 的 IoT 平台與生態圈，齊力創新研發與拓展市場。

加入 APN(AWS Partner Network)，加速您尋找適合的 IoT 裝置與方案，以及推廣您的IoT產品

* 您可將與 AWS IoT 服務配搭的 IoT 裝置， 以自助的方式鑑定 IoT 裝置資格，並上架於AWS Partner Device Catalog 目錄中，透過 AWS APN 硬體合作夥伴的網絡，提供潛在 IoT 專案的合作夥伴裝置推薦與選購，以進行評估、原型設計或概念驗證，加速您 IoT 裝置的推廣。
* APN (AWS Partner Network- https://thinkwithwp.com/tw/partners/)
* AWS Partner Device Catalog (https://devices.amazonaws.com/)

利用 AWS MAP (Migration Acceleration Program)，加速您建置或移轉雲端資源，並降低遷移風險與初始成本。

* AWS MAP 提供您可降低成本、自動化和加速執行的工具、量身定製培訓方法和內容、利用合作夥伴的專業技術，以及 AWS 的投資，協助您進行三階段架構驗證 (評估、行動、遷移和現代化) 與實現遷移目標。
* AWS MAP (Migration Acceleration Program- https://thinkwithwp.com/tw/migration-acceleration-program/)

以上跟各位介紹了 AWS AIoT 平台概覽，以及提供了 AWS AIoT 該如何導入的入門方式。後續我們會基於大家的反饋，再針對 AWS AIoT 服務，或是相關情境，提供更多的 Blog 文章，讓大家可以更理解，該如何快速地透過 AWS AIoT 打造出屬於自己的物聯網應用。如果大家對於以上講述的任何部分，希望得到更多的細節，歡迎加 AWS 為 LINE 好友，並輸入關鍵字 “Aiot” 與我們聯繫，還有機會獲得價值 1500 美金的 AWS 抵用碼。