用於將物聯網設備收集的數據（Telemetry），做下一步的處理，提供強大的服務鏈幫助我們「用數據」，這邊先列出幾個Telemetry best practice:
- 每五秒讀一次（既能了解變化，又能不讓資料量那麼大）bandwith of data storage
- 資料時間用UTC time，就不用考慮時區
- 收集所有sensor的監測數據，全部打包成一包string給AWS IOT （effective of getting time series data to the AWS cloud)
— 以下進入正文
當你有監測需求，有了sensor後就會希望有個地方能幫你處理好收到數據後的事情，此時就可利用AWS IOT這個強大的生態系，我們一起來看他能為我們做什麼吧。
假設我們是一個國小中央廚房，為了避免受到食安檢舉，我們可能需要追蹤以下數據：
冷藏/冷凍庫的溫度、炒菜時間、炒菜火侯..
在安裝感測器監測這些數據之後，我們將sensor和aws連線（ Connecting to AWS IoT Core.），這個連線會是安全的：
將感測器在aws上註冊，這種虛擬的代表就稱為thing，而實體的感測器稱為device。
Device Advisor(在發布前使用，確保沒問題才發布）
想要檢查／了解設定的thing是否正確，像是看TLS連線,確定policy,mqtt動作等等就可以使用Device advisor (Device Advisor test cases)
確認連線都沒問題後，我們來看看有哪些東西能為我們所用吧。
device shadow & thing type
AWS 提供device shadow記載裝置的資訊，像是版本，thing本身可以放三個屬性，若有指定thing的thingType則可以多至多50個屬性，每一個thingType都是我們自己定義的，像是溫度、開關等等，我們把一些有共通屬性的sensor提出來統一放在type當中，舉例來說，溫度的屬性會有大卡、最低溫度、最高溫度等屬性。
將這些thing設定好了之後，如果我希望在溫度超過40度的時候發警報通知給廠長並且將這個異常記錄到dynomodb，我們可以仰賴Message Broker, engine rules,加上lambda function。
thing group (進階使用)
分為靜態群組跟動態群組，靜態群組是我們自己手動拉的，哪些thing組合再一起叫什麼，而動態群組有點像我們設定一些群組成員的樣貌，由aws自動幫我們維護每個群組的成員列表(sensor member list)有誰。
動態群組的案例可以是跨thing的：
將溫度高於40的感測器加入到這個異常溫度群組，並且將冷氣打開。
Message Broker
sensor收集到的資訊會利用Message Broker將收集到的數據發布給訂閱者，訂閱者可能是某一個aws服務(ex: rules)，或是其他sensor。
AWS有提供一些預設的topic提供我們使用，像是config/update或是斷線。
rules
監聽某一個message topic，將訊息用sql like的方式做操作，rules的組成為：
name: 規則的名稱
query: sql like搜尋語法，像是SELECT * FROM 某個topic。
action: 要把資料路由到哪裡 (ex: 轉換資料後發到其他topic, 將資料pass給lambda function做其他處理)
Lambda function
就是一個無伺服器的雲端function，我們只需要寫好Function要做什麼就好了，aws會為我們處理底層的一些東西，不過我們也是需要設定一些基本的，像是記憶體等等。
我們可以把rules傳來的資料，做進一步複雜的處理後寫入dynomodb，詳細怎麼使用，可以去閱讀官方文件或之後有空會獨立在寫一篇。
