AWS IoT Core規則引擎實戰：感測器資料自動路由到Lambda與S3
工廠IT技術人員專用AWS IoT Core規則引擎S3資料湖ATLANTIS 自有品牌
AWS IoT Core規則引擎實戰：感測器資料自動路由到Lambda與S3
「Re-Atlantis」的品牌精神，強調秩序與精密——規則引擎正是雲端架構中「秩序」的具體展現：一份原始資料，依照明確的規則，同時流向該去的每一個地方，不需要工程師手動搬運或重複發送。詳見 ATLANTIS 品牌故事。
一、為什麼一條規則需要多個動作？
在第三篇與第六篇中，我們示範的規則都只設定了單一動作（觸發Lambda，或寫入DynamoDB）。但實務上的工廠監控系統，往往需要同一筆資料同時做好幾件事：即時判斷異常（Lambda）、寫入結構化歷史記錄（DynamoDB）、同時保留完整原始封包供未來稽核或重新分析（S3）。
多個並行動作
不額外收費
長期資料湖儲存
路由至備援目的地
為什麼原始資料要存進S3，而不是只存DynamoDB？
DynamoDB適合儲存結構化、需要快速查詢的近期數據；但S3的儲存成本更低，且能保留完整未經處理的原始封包（例如本系列第四篇提到的原始16進位暫存器資料）。當未來發現某個解析邏輯有誤，或需要用新的演算法重新分析歷史資料時，S3裡的原始資料就是你唯一能「重新來過」的依據——這也是資料工程領域常說的「資料湖（Data Lake）」概念。
二、架構總覽：一條規則、三個並行動作
這張架構圖的重點是：三個動作①②③是平行執行的，彼此互不依賴、互不影響。即使Lambda執行時發生異常，DynamoDB與S3的寫入動作仍會照常進行；反之亦然。這種「平行扇出」的設計，正是IoT Core規則引擎的核心價值。
三、規則引擎SQL語句進階：常用內建函式一覽
前面幾篇文章用到的規則SQL都相對單純，這裡整理更完整的內建函式清單，讓你能撰寫更精細的篩選與資料轉換邏輯。
| 函式 | 功能說明 | 使用範例 |
|---|---|---|
| topic() | 取得完整MQTT主題路徑 | topic() as source_topic |
| topic(n) | 取得主題路徑中第n段（以斜線分隔，從0開始） | topic(3) as device_id |
| timestamp() | 取得規則引擎處理當下的時間戳記（毫秒） | timestamp() as processed_at |
| cast(value AS type) | 將欄位轉換為指定資料型態 | cast(temperature AS DECIMAL) |
| get_thing_shadow() | 讀取指定裝置的Thing Shadow狀態 | 用於比對裝置上次回報的組態設定 |
| encode(data, 'base64') | 將二進位資料編碼為Base64字串 | 適合傳遞原始封包位元組資料 |
其中topic(n)特別實用：若你依照本系列建議的主題命名規則factory/廠區/產線/temperature/裝置ID，就可以用topic(1)取得廠區代號、topic(4)取得裝置ID，不需要在訊息內容中重複帶入這些資訊，直接從主題路徑萃取即可，減少發布端的資料負擔。
進階規則SQL範例
temperature,
topic(1) as plant_code,
topic(2) as line_code,
topic(4) as device_id,
timestamp() as processed_at
FROM 'factory/+/+/temperature/#'
WHERE temperature > 0
四、設定S3動作：讓原始資料自動依日期與裝置分區儲存
在規則的「動作」設定中新增「儲存訊息至S3儲存貯體」，除了指定Bucket名稱外，最關鍵的設定是「金鑰（Key）」的命名規則——這決定了資料在S3裡如何被組織，也直接影響未來用Athena等工具查詢的效率。
建議的S3 Key命名規則（適合Athena分區查詢）
這種以plant=、year=等鍵值對命名的資料夾結構，稱為「Hive風格分區（Hive-style Partitioning）」，是Amazon Athena等查詢引擎能有效率掃描資料的關鍵設計——未來若只需要查詢「某廠區某個月份」的資料，Athena可以直接跳過不相關的資料夾，大幅降低查詢成本與時間。
S3動作需要的IAM角色
與Lambda函式不同，IoT Core規則本身也需要一個「規則角色（Rule Role）」，授權規則引擎代表你執行S3寫入、DynamoDB寫入等動作。這個角色的信任關係需要允許iot.amazonaws.com服務擔任（AssumeRole），並附加對應資源的操作權限。
規則角色的信任政策（Trust Policy）範例
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {"Service": "iot.amazonaws.com"},
"Action": "sts:AssumeRole"
}
]
}
許多工廠IT技術人員第一次設定規則動作失敗時，都是卡在這個角色信任關係設定不完整，導致規則引擎本身沒有權限把資料寫入S3或DynamoDB——這與Lambda函式的執行角色是兩個完全獨立的權限體系，務必分開檢查。
五、動作目的地完整比較：該把資料送去哪裡？
| 動作目的地 | 適合場景 | 延遲特性 | 費用驅動因素 |
|---|---|---|---|
| Lambda函式 | 即時運算、封包解析、異常判斷 | 毫秒級 | 執行次數與運算時間 |
| DynamoDB | 結構化歷史記錄、快速鍵值查詢 | 毫秒級 | 讀寫請求次數與儲存容量 |
| S3 | 原始資料長期歸檔、資料湖分析 | 近乎即時寫入 | 儲存容量與請求次數，儲存單價低 |
| SNS | 即時通知（簡訊/Email/其他系統） | 秒級 | 發布訊息數與通知管道類型 |
| SQS | 需要緩衝、批次處理的下游系統 | 依佇列輪詢頻率 | 訊息請求次數 |
| Republish（重新發布） | 轉發至另一個MQTT主題，串接其他訂閱系統 | 毫秒級 | 訊息傳遞費用 |
對於一套完整的工廠監控系統，Lambda負責「現在」、DynamoDB負責「近期」、S3負責「永遠」——這三層搭配使用，兼顧即時反應、快速查詢與長期資料完整性，是本系列文章建議的標準架構組合。
錯誤動作（Error Action）：當某個動作失敗時該怎麼辦？
規則引擎允許為整條規則設定一個「錯誤動作」，當任何一個主要動作因權限錯誤、目的地服務異常或格式問題而失敗時，錯誤訊息會被路由到這個備援目的地（例如另一個S3儲存貯體或CloudWatch Logs），方便工程師事後追蹤是哪個環節出了問題，而不是讓失敗的訊息無聲無息地消失。
六、用AWS CLI建立包含多個動作的規則（進階，選讀）
若你的團隊習慣用基礎架構即程式碼（Infrastructure as Code）管理AWS資源，也可以用AWS CLI或CloudFormation定義規則，而不需要每次都在主控台手動點擊設定。以下是一個包含Lambda與S3兩個動作的規則定義範例（JSON格式）。
多動作規則定義範例（供aws iot create-topic-rule使用）
"sql": "SELECT *, topic(4) as device_id, timestamp() as processed_at FROM 'factory/+/+/temperature/#'",
"actions": [
{
"lambda": {
"functionArn": "arn:aws:lambda:ap-northeast-1:123456789012:function:temperature-alert-handler"
}
},
{
"s3": {
"roleArn": "arn:aws:iam::123456789012:role/iot-rule-s3-writer",
"bucketName": "atlantis-factory-raw-data",
"key": "raw-data/plant=${topic(1)}/line=${topic(2)}/${newuuid()}.json"
}
}
],
"errorAction": {
"cloudwatchLogs": {
"roleArn": "arn:aws:iam::123456789012:role/iot-rule-error-logger",
"logGroupName": "/aws/iot/rule-errors"
}
}
}
這份JSON定義涵蓋了本篇的三個核心概念：actions陣列裡同時包含Lambda與S3兩個並行動作，errorAction則設定當任一動作失敗時，錯誤訊息會被記錄到指定的CloudWatch日誌群組。
七、ATLANTIS 適合建立完整資料湖架構的多樣化量測產品
AT-PT186 智慧型壓力傳送器 —— 低功耗微處理器搭配高精度A/D及D/A處理，4-20mA標準輸出，適合作為資料湖中長期穩定的壓力數據來源
DPG-X002 高精度數位壓力錶 —— 主副屏分屏顯示，內建高精度ADC與高速微處理器，同時輸出即時壓力值與溫度等多維度數據，適合豐富資料湖內容
SPT-X 工業型數顯壓力傳送器 —— 進口擴散矽傳感器芯體搭配儀錶級放大電路，長期穩定性佳，適合作為S3長期歸檔資料的可信賴來源
ATT-110 溫度感測器 —— 高性能高可靠性RTD Pt100，快速響應環境溫度變化，適合搭配規則引擎多動作架構同時滿足即時監控與歷史歸檔需求
完整規格請參考 ATLANTIS 產品型錄與工業4.0壓力感測器整合指南。
八、案例分享：某台中汽車零件廠的資料湖架構導入
以下案例經匿名化處理，客戶為台中一家汽車零件製造廠，因應客戶端（國際車廠）的品質稽核要求，需要保留完整的製程壓力數據供未來任意時間點的回溯分析。
| 需求 | 採用的規則動作組合 | 導入前 | 導入後 |
|---|---|---|---|
| 即時異常告警 | Lambda + SNS（第五篇架構） | 依賴人工巡檢，反應時間約1～2小時 | 異常發生後數秒內通知值班人員 |
| 近期趨勢查詢 | DynamoDB（第六篇架構） | 無法快速查詢特定時間範圍數據 | 可即時查詢任意裝置過去30天數據 |
| 長期稽核歸檔 | S3（本篇架構）+ Hive風格分區 | 原始數據僅保留在本地SCADA，容量有限僅存3個月 | 完整原始封包永久保存於S3，並可用Athena依廠區/月份快速查詢 |
資深工程師賴祥德分享：「很多工廠在導入雲端監控時，只想到『即時告警』這個最直觀的需求，卻忽略了『資料完整保存』的長期價值。等到客戶稽核單位要求提供兩年前某個批次的完整壓力記錄時，才發現當初的架構根本沒有保留原始數據。這也是為什麼我們建議一開始就把S3資料湖納入規劃，而不是等到出問題才補救。」
資料來源與延伸閱讀
本文技術架構參考 AWS IoT Core 規則引擎官方文件（docs.aws.amazon.com/iot）、Amazon S3與Amazon Athena官方文件中關於Hive風格分區的說明。IAM角色信任政策設定方式請以AWS官方IAM文件為準。ATLANTIS產品技術規格引用自內部產品規格書。
十、20 大常見問題 FAQ（IoT Core規則引擎與S3資料湖）
1. 一條規則最多可以設定幾個動作？
2. 多個動作是依序執行還是同時執行？
3. 為什麼我的S3動作一直失敗，Lambda卻正常運作？
iot.amazonaws.com擔任該角色，這與Lambda函式本身的執行角色是完全獨立的權限設定，需分別檢查。4. Hive風格分區具體能節省多少查詢成本？
5. topic(n)裡的n是從0還是從1開始算？
factory/taipei-plant1/line1/temperature/ATL-STT-001中，topic(0)為factory，topic(1)為taipei-plant1，依此類推。6. 錯誤動作（Error Action）會不會也失敗？
7. newuuid()函式的用途是什麼？
8. 我可以只用S3不用DynamoDB嗎？
9. 規則引擎的SQL語句可以做數學運算嗎？
10. S3儲存的原始資料，格式一定要是JSON嗎？
encode()函式編碼後儲存，依實際需求選擇合適格式。11. 我想同時把資料送到SNS做告警，也送到S3歸檔，這樣需要幾條規則？
12. 規則SQL的WHERE條件會不會影響S3與DynamoDB動作的資料完整性？
13. Athena查詢S3裡的IoT資料，需要另外設定什麼嗎？
14. 規則角色和Lambda執行角色可以共用同一個IAM角色嗎？
iot.amazonaws.com與lambda.amazonaws.com兩種服務擔任角色，但基於最小權限與職責分離原則，建議分別建立獨立角色，降低單一角色權限過廣的風險。15. 我可以用Republish動作把資料轉發到另一個MQTT主題嗎？
16. 規則引擎本身的費用怎麼計算？
17. cast()函式在什麼情況下特別有用？
cast(temperature AS DECIMAL)確保後續動作（如DynamoDB寫入）收到的是正確的數字型態，避免因型態不符導致寫入失敗。18. 我可以用一條規則同時處理溫度和壓力兩種訊息嗎？
FROM子句涵蓋兩種主題路徑（例如使用萬用字元或列出多個主題），並在動作設定中依需求決定是否要區分處理邏輯，但若解析邏輯差異很大，建議拆成兩條獨立規則以保持清晰度。19. 修改規則的SQL語句或動作設定，會影響歷史已寫入的資料嗎？
20. 學會規則引擎進階應用後，下一步該學什麼？
十一、下一步：讓 ATLANTIS 協助你規劃完整的資料湖與即時監控雙軌架構
31年工業儀錶製造經驗 × 完整數位化資料架構規劃
從變送器選型、規則引擎多動作設計，到符合客戶稽核要求的長期資料湖規劃，我們可以陪工廠IT團隊打造兼具即時性與完整性的雲端監控架構。
📞 02-2820-3405 免費選型諮詢 📧 線上快速詢價
業務一部 Ian：ian@atlantis.com.tw ｜ 業務二部 Nori：nori@atlantis.com.tw
文章更新時間：2026年7月｜作者：ATLANTIS 應用工程團隊｜本文為系列教學文章第七篇，下一篇將深入「Lambda + CloudWatch：監控你的工業感測器數據管線健康度」。