管線編排 — Step Functions、MWAA 與 EventBridge

流水線編排是每個生產級資料工程平台的支柱。在 DEA-C01 考試中，選擇正確的編排器 — Step Functions、MWAA 或 EventBridge 排程器 — 是領域 1 和領域 3 中最常被提及的陷阱之一。陷阱很少在於「是否要進行編排」（替代方案是手寫的 cron 任務，這在大規模情況下極易出錯），而是在於「成本形態」和「使用案例的契合度」。如果團隊為了一個簡單的線性五步流水線選擇 MWAA，即便沒有任務運行，每月也要為持續運行的 Airflow 環境支付 300 多美元，而使用 Step Functions 可能只需幾美元；相反，如果一個擁有 Airflow 專業知識的團隊為一個複雜的、包含 50 個 DAG 的分析平台選擇 Step Functions，則可能會錯失開發效率。

本指南從資料工程師 / MLOps 的視角介紹 AWS 上的編排 — 涵蓋何時使用 Step Functions 標準工作流程 (Standard) 與高速工作流程 (Express)、MWAA 的持續成本模型與 Step Functions 的按轉換次數計費有何不同、EventBridge 排程器如何簡化 cron 類觸發器、用於平行處理的 Map 狀態模式、使用重試 (Retry) 與擷取 (Catch) 進行錯誤處理、將編排器連接至 Glue/EMR/Redshift 的整合模式，以及圍繞成本比較、MWAA 與 Step Functions 選擇、以及編排與事件路由區別設定的典型考試陷阱。

為什麼編排很重要 — 手寫 Cron 的反模式

在討論具體的編排器之前，請先了解它們要解決的問題。

手動 Cron 無法做到的事

一個每天 02:00 運行 glue start-job-run 的 cron 任務看起來沒問題，直到 Glue 工作失敗 — cron 本身沒有重試邏輯，沒有下游通知，也沒有意識到因為上游失敗而「不應」運行下一步（如 Redshift COPY）。手動 cron 也無法表達條件分支（「如果記錄數低於閾值，則發送警報；否則繼續」）、平行展開或跨服務協調。

編排器提供什麼

狀態管理（追蹤哪個步驟已運行、哪個失敗）、重試政策（按步驟配置帶有抖動的指數退避）、錯誤處理（擷取特定錯誤代碼並路由至補償邏輯）、條件分支、平行執行、人工介入步驟、可觀察性（工作流視覺化、按步驟記錄日誌）以及版本控制（以程式碼形式存儲的工作流定義）。

三個 AWS 選項

Step Functions 用於託管狀態機，MWAA 用於託管 Apache Airflow，EventBridge 用於事件路由與排程。DEA-C01 考試會測試哪種工具適合哪種工作負載。

AWS Step Functions — 流水線的狀態機

Step Functions 是 AWS 原生的無伺服器工作流程編排器。

狀態機模型

Step Functions 工作流程是一個狀態機，使用 Amazon States Language (ASL) 定義，這是一種列出狀態（步驟）及其轉換關係的 JSON 方言。每個狀態都有類型 — 任務 (Task，執行工作)、選擇 (Choice，分支)、等待 (Wait，暫停)、平行 (Parallel，同時運行狀態)、映射 (Map，遍歷陣列)、通過 (Pass，轉換資料)、失敗 (Fail，帶錯終止)、成功 (Succeed，成功終止)。

標準 vs 高速工作流程 (Standard vs Express)

Step Functions 提供兩種定價與運行模型：

標準工作流程 (Standard workflows)：提供「最多一次」執行與「正好一次」傳遞語義，狀態最長可保留一年，控制台中可見完整的執行歷史，每百萬次狀態轉換收費 25 美元。適用於：長時間運行的流水線（分鐘到天）、需要可視歷史記錄的工作流、具有稽核需求的多步 ETL。

高速工作流程 (Express workflows)：提供「至少一次」執行語義，每次執行最長 5 分鐘，歷史記錄受限（僅 CloudWatch Logs），按執行次數和 GB-秒計費（類似 Lambda），在大交易量下便宜得多。適用於：高交易量、短持續時間的工作流（IoT 事件處理、API 請求編排）、5 分鐘內的微批次處理。

DEA-C01 陷阱：考生常預設為所有任務選用標準模式；對於高交易量、短持續時間的處理，正確答案是高速模式。

直接服務整合

Step Functions 具有 200 多個直接服務整合 — 無需編寫 Lambda 黏合程式碼即可調用 Glue、EMR、Athena、Redshift Data API、Lambda、SNS、SQS、DynamoDB、EventBridge 等。整合在 ASL 狀態定義中宣告；AWS 負責處理 API 調用、回應解析與錯誤傳播。

用於展開的 Map 狀態

Map 狀態針對輸入陣列中的每個項目平行運行同一組步驟。使用案例：通過傳遞 S3 索引鍵陣列作為輸入，讓 Map 為每個索引鍵調用一個 Glue 工作，從而平行處理 100 個 S3 檔案。Map 狀態具有 MaxConcurrency 參數（預設為 0 = 無限制，生產環境應顯式設定）。

用於大規模平行的分散式 Map (Distributed Map)

分散式 Map 是高擴展變體，支援多達 10,000 個並行子執行，並能從 S3（CSV、JSON、清單檔案）讀取輸入。使用案例：在不觸及標準 Map 並行限制的情況下，平行處理數百萬條記錄。

錯誤處理 — 重試 (Retry) 與擷取 (Catch)

每個任務 (Task) 狀態都可以宣告 Retry 規則（定義哪些錯誤代碼觸發重試、退避間隔與最大嘗試次數）和 Catch 規則（定義哪些錯誤代碼路由到回退狀態）。重試處理瞬時失敗；擷取則通過路由到補償、警報或降級邏輯來處理永久性失敗。DEA-C01 考試會設定能從 API 限流或 Glue 失敗中恢復的具備彈性流水線情境來考查此點。

活動 (Activity) 與回呼 (Callback) 模式

Step Functions 可以暫停並等待外部系統完成任務。兩種模式：活動 (Activity) 工作者主動輪詢任務並報告結果；帶有任務權杖的 回呼 (Callback) 則允許任何 AWS 服務或外部 API 在工作完成時發回權杖。使用案例：資料流水線中的人工審核步驟、與非 AWS 系統整合、長時間運行的 EMR Steps API 調用。

Amazon MWAA — 託管 Apache Airflow

MWAA 是 AWS 提供的託管 Apache Airflow 服務，是資料工程團隊中流行的開源編排器。

MWAA 提供什麼

一個在 AWS 託管基礎設施上運行的 Airflow 環境，包含排程器 (scheduler)、網頁伺服器 (webserver) 和工作者 (workers)。您將 DAG 檔案（定義工作流的 Python 程式碼）上傳到 S3 儲存桶，MWAA 會拾取並排程它們。該環境負責處理 Airflow 升級、安全修補和工作者自動擴展。

為什麼團隊選擇 Airflow

Airflow 擁有龐大的運算子 (operators) 生態系統（資料庫連接、S3 感測器、Spark 提交、自定義 Python 任務）、成熟的社群以及廣泛的可移植性 — DAG 可以運行在託管 Airflow、自建 Airflow、Cloud Composer (GCP) 或 Astronomer（第三方）上。擁有現成 Airflow 經驗或 DAG 的團隊會選擇 MWAA 進行遷移。

MWAA 定價 — 持續成本模型

MWAA 按環境小時為排程器/網頁伺服器基準計費，外加按工作者小時為工作者池計費。一個小型環境（mw1.small, 2 個工作者）起價約每小時 0.49 美元，即每月約 360 美元 — 無論是否有 DAG 執行，這筆費用都會產生。較大環境可擴展至 mw1.xlarge，工作者可根據配置的最大值自動擴展。

Step Functions vs MWAA — 成本曲線對比

Step Functions 標準模式：基準成本約為 0 美元，每百萬次轉換 25 美元。一個每天 1000 次轉換的流水線每月花費約 0.75 美元。MWAA：基準成本每月 360 美元以上，不論使用量。平衡點大約在每月 1400 萬次轉換左右 — 低於此數值，Step Functions 在成本上勝出；高於此數值，MWAA 勝出，因為每轉換成本會趨於平緩。

何時選用 MWAA

當團隊具備現成的 Airflow 專業知識或需要從他處移植 DAG 時，當工作負載涉及數十個每個都包含許多任務的複雜 DAG 時，當團隊需要 Airflow 特有功能（XCom 資料傳遞、具有複雜輪詢邏輯的感測器、龐大的社群運算子生態系統）時，或當跨雲端供應商的可移植性具有戰略意義時。

何時不選 MWAA

對於只有少量步驟的簡單線性工作流，對於基準成本顯得浪費的臨機編排，以及對於在 AWS 上全新開始且沒有 Airflow 經驗的團隊 — Step Functions 要簡單得多。

Amazon EventBridge — 規則、管道與排程器

EventBridge 是事件路由服務，它與編排器互補，而非競爭關係。

EventBridge 規則 (Rules)

EventBridge 規則匹配進入事件匯流排的事件並將其路由至目標 — 目標包括 Lambda、Step Functions、Glue、SNS、SQS、Kinesis。使用案例：對 S3 物件建立、DynamoDB Streams 事件或自定義應用程式事件做出反應。規則基於模式匹配（例如 {"source": ["aws.s3"], "detail-type": ["Object Created"]}）並可路由至多個目標。

EventBridge 管道 (Pipes)

管道是點對點的事件整合，連線一個來源（DynamoDB Stream, Kinesis Stream, MSK, SQS）與一個目標（Step Functions, Lambda, Firehose, SNS），中間帶有選用的篩選和增強。管道簡化了以前需要 Lambda 黏合程式碼的常見模式。

EventBridge 排程器 (Scheduler)

EventBridge 排程器是 cron 的替代服務，用於按排程調用 AWS API。定義一個排程（cron 表達式或速率表達式），選擇一個目標（Step Functions 執行、Lambda、Glue 工作、EMR Step），排程器就會可靠地調用該目標。它取代了帶有 cron 排程的舊版 CloudWatch Events 規則，並增加了：每個排程的 IAM 角色、時區支援、一次性和重複性排程、以及失敗調用的無寄件備份佇列。

排程器 vs 規則 — 何時使用哪一個

使用規則對進入事件匯流排的事件做出反應（事件驅動）。使用排程器根據時間排程調用目標（時間驅動）。兩者都可以觸發 Step Functions，但對於「每天 02:00 觸發此流水線」，排程器是正確答案。

作為編排黏合劑的 EventBridge

典型模式：EventBridge 排程器每晚觸發一個 Step Functions 工作流；Step Functions 工作流運行一個 Glue ETL 工作，等待其完成，然後運行 Redshift COPY，執行驗證並發送通知。每個工具各司其職 — 排程器發起，Step Functions 編排，Glue 和 Redshift 執行。

Step Functions 與資料服務的整合

DEA-C01 考試測試 Step Functions 如何將 Glue、EMR、Redshift、Athena 和 Lambda 串聯起來構建 ETL 流水線。

Glue ETL 工作

直接整合：具有 glue:startJobRun.sync 資源的 Step Functions 任務狀態會啟動一個 Glue 工作，並等待其完成後再轉換。將工作執行詳情返回給下一個狀態。.sync 後綴表示同步（等待完成）變體。

EMR 叢集與步驟 (Steps)

EMR 的直接整合 — emr:createCluster.sync, emr:addStep.sync, emr:terminateCluster.sync。Step Functions 工作流可以啟動一個 EMR 叢集、提交 Spark 步驟、等待完成並終止叢集 — 取代了數十行 Python 編排程式碼。

Redshift Data API

通過 aws-sdk:redshiftdata:executeStatement.sync 進行直接整合。Redshift Data API 是異步的（無需 JDBC 連接），使其成為不想維護資料庫連接之編排器的正確模式。

Athena 查詢

通過 athena:startQueryExecution.sync 直接整合，等待 Athena 查詢完成並返回結果位置。

Lambda

通過 lambda:invoke 直接整合，運行 Lambda 函數並將回應傳遞給下一個狀態。這是最簡單的整合方式；適用於直接整合無法涵蓋的自定義邏輯。

Glue 工作流程 vs Step Functions — 微型編排器

Glue 工作流程是內建於 AWS Glue 本身的輕量級編排器。

Glue 工作流程的作用

在單個 Glue 工作流程中協調 Glue 工作、爬網程序和觸發器。具備視覺化編輯器、基於工作狀態的條件分支，無需外部編排器。使用案例：簡單的、僅包含 Glue 的多步流水線（爬取 → ETL → 爬取）。

何時 Glue 工作流程勝出

對於 100% 屬於 Glue 的流水線（無 EMR、無 Redshift COPY、無 Lambda），Glue 工作流程比 Step Functions 更簡單，且除了 Glue 工作本身外不產生額外成本。

何時 Step Functions 勝出

對於跨越多個 AWS 服務（Glue + Redshift + Lambda + EMR）的流水線，Step Functions 是正確答案 — 其直接整合涵蓋了所有這些服務，且編排邏輯是集中化的。

DEA-C01 決策建議

考試會通過情境細節來考查： 「具有兩個爬網程序和三個工作的純 Glue 流水線」 => Glue 工作流程；「跨越 Glue, EMR, Redshift COPY 和 Lambda 驗證的 ETL」 => Step Functions。

編排的常見考試陷阱

請務必記住這五個陷阱。

陷阱 1 — 為簡單線性流水線選用 MWAA

情境描述五個每日 ETL 步驟，並詢問最具成本效益的編排器。錯誤答案：MWAA（因為 Airflow 是「行業標準」）。正確答案：Step Functions 標準模式 — 零基準成本，簡單狀態機。

陷阱 2 — 為 1000 萬次短執行選用 Step Functions 標準模式

情境描述每月 1000 萬次用於 IoT 事件處理的短持續時間工作流。錯誤答案：Step Functions 標準模式。正確答案：Step Functions 高速模式 — 在高 TPS 下對 5 分鐘內的執行便宜 100 倍。

陷阱 3 — 使用 Lambda 輪詢 Glue 工作狀態

情境描述編排一個 30 分鐘的 Glue 工作。錯誤答案：輪詢 getJobRun 直至完成的 Lambda 函數（Lambda 有 15 分鐘逾時）。正確答案：使用 glue:startJobRun.sync 的 Step Functions 直接整合。

陷阱 4 — 使用 EventBridge 規則進行基於時間的排程

情境描述「每天在東京時間 02:00 觸發此流水線」。錯誤答案：帶有 cron 表達式的 EventBridge 規則。正確答案：EventBridge 排程器 — 支援時區、無寄件備份佇列以及按排程配置的 IAM 角色。

陷阱 5 — 在不具備 Airflow 專業知識的情況下選用 MWAA

情境描述一個沒有 Airflow 經驗的小型資料團隊在 AWS 上全新開始。錯誤答案：MWAA（理由是「DAG 功能強大」）。正確答案：Step Functions — 團隊只需學習一種 AWS 原生工具，而非 Airflow 加 AWS。

Step Functions 工作流程示例

範例 1 — 每日 ETL 流水線 (標準模式)

EventBridge 排程器 (cron: 0 2 * * *) →
  Step Functions 標準模式:
    任務: Glue 爬網程序 (原始區域)
    選擇: 爬網程序是否成功？
      是 → 任務: Glue ETL (原始 → 精選)
      否 → 任務: SNS 通知值班人員, 失敗
    任務: 從精選 S3 到暫存表的 Redshift COPY
    任務: Redshift 預存程序 (合併到事實表)
    任務: Athena CTAS 以重新整理儀表板區域
    成功

範例 2 — IoT 事件處理 (高速模式)

IoT 規則 → EventBridge → Step Functions 高速模式:
    任務: 驗證事件結構描述 (Lambda)
    選擇: 是否有效？
      是 → 任務: 使用參考資料進行增強 (DynamoDB GetItem)
              任務: 將增強後的事件寫入 Firehose
              成功
      否 → 任務: 路由至無寄件備份 SQS
              失敗

範例 3 — Map 狀態展開

Step Functions 標準模式:
    任務: 列出 S3 前綴 (Lambda 返回陣列)
    Map (MaxConcurrency 10):
      項目處理器:
        任務: 針對此前綴的 Glue ETL (.sync)
        任務: 將完成標記寫入 DynamoDB
    任務: 彙總結果
    成功

白話文解釋流水線編排

三個具體的類比讓編排器選擇變得直觀。

類比 1 — 不同協調模式的餐廳廚房

Step Functions 就像一位主廚，他一次喊出一個訂單，並觀察每個工站完成後再喊下一個： 「做沙拉，好了就做主菜，好了就裝盤出餐」。簡單、精簡，在沒有訂單時廚房零開銷。每次喊話就是一次轉換，按次計費。高速變體則是同一位主廚在一家高交易量的速食店工作，那裡的訂單簡單且快速 — 漢堡、薯條、汽水 — 帳單改為按訂單計費而非按步驟計費，因為步驟太快了，數不過來。MWAA 則是聘請了一整個行政副主廚團隊，他們有自己的管理階層（Airflow 排程器、網頁伺服器、工作者） — 無論有沒有訂單，他們整天都坐在廚房裡，但他們能處理複雜的多道菜套餐，同時應對 50 張訂單，協調整個廚房和多餐廳物流，這是主廚一人無法勝任的。EventBridge 排程器是每日備料鬧鐘：06:00 響起，告訴廚房「開始晨間備料」，本身不帶任何邏輯。EventBridge 規則則是門鈴，每當送貨卡車到達時就會響起，將警報路由到相應的工站。DEA-C01 陷阱在於為一個五張桌子的家庭餐廳聘請行政副主廚團隊（簡單線性流水線選 MWAA），或要求主廚單槍匹馬協調一場 200 人的外燴活動（對擁有 Airflow 專家且任務極其複雜的工作負載選 Step Functions）。

類比 2 — 圖書館採購工作流

Step Functions 是圖書館的任務清單 App： 「第一步，接收捐贈者的新書；第二步，逐一編目；第三步，貼標籤並上架；第四步，更新線上目錄」。每一步都記錄了時間戳，重試由 App 處理，平行任務（同時為多本書編目）通過 Map 產生。標準模式是具有多日歷史記錄的耐用清單；高速模式是輕量級版本，用於「掃描條碼並添加到庫存」等高交易量的一次性任務。MWAA 是圖書館完整的圖書館管理系統 (LMS) — 一個持續運行的企業平台，具有流通、採購、編目、館際互借和報告模組，需要一位受過 LMS 培訓的管理員。LMS 處理整個圖書館複雜的多部門工作流，但無論是否有新書到達，其成本都是持續產生的。EventBridge 排程器是每天 09:00 檢查捐贈箱的提醒；EventBridge 規則是書籍逾時歸還時的警報。正確選擇取決於圖書館的規模和複雜度：五個人的社區圖書館使用任務清單 App (Step Functions)；擁有 50 名管理員的大學研究圖書館使用 LMS (MWAA)。

類比 3 — 手動路由 vs 工業自動化的郵政分揀設施

Step Functions 就像手動分揀員，遵循書面程序： 「打開郵袋，掃描第一封信，路由到相應的箱子，重複直到袋子清空」。程序簡潔，分揀員按分揀信件量計費，沒有郵件時設施不產生費用。標準模式是白班分揀員，處理帶有多小時稽核日誌的全量隔夜袋；高速模式是高速分揀員，應對活動後的郵件高峰，在更簡單的路由規則下每分鐘處理數千封信。MWAA 是工業級郵政自動化大廳 — 傳送帶、OCR 閱讀器、機器手臂、主管工作站 — 每小時處理十萬件包裹，並在姐妹設施之間進行複雜路由，但設備持續運轉，即使在安靜的週末每月也要花費 360 美元以上。EventBridge 排程器是 06:00 開放接收碼頭的定時器；EventBridge 規則是在包裹標記為「易碎，轉向特殊處理」時觸發的通知。DEA-C01 陷阱是為一個每天處理 200 件包裹的鄉村郵局購買工業自動化大廳（簡單工作流選 MWAA），或要求手動分揀員在聖誕高峰期處理區域分揀中心（真正的 50-DAG 企業級工作負載選 Step Functions）。

關鍵數據與必背事實

Step Functions 標準模式

• 每百萬次狀態轉換 25 美元
• 執行持續時間最長可達 1 年
• 完整的執行歷史保留 90 天
• 提供「最多一次」執行語義
• 支援 .sync 的直接服務整合

Step Functions 高速模式

• 每百萬次執行約 1 美元 + 按 GB-秒計費
• 每次執行最長持續時間 5 分鐘
• 歷史記錄僅發送至 CloudWatch Logs
• 提供「至少一次」執行語義
• 最適合高 TPS 的短工作流

MWAA

• 持續環境成本：最低每月 360 美元以上 (mw1.small)
• 更大規格：mw1.medium 約每月 700 美元，mw1.large 約每月 1300 美元
• 工作者在配置的最小/最大值內自動擴展
• 支援 Apache Airflow 2.x 版本
• DAG 上傳至 S3 儲存桶

EventBridge

• 規則：免費，遞送每百萬次匹配事件 1 美元
• 管道：按事件計費，成本與規則類似
• 排程器：每月前 1400 萬次調用免費，之後每百萬次 1 美元
• 自定義事件匯流排保留：最長 1 年

Step Functions Map 狀態

• 標準 Map：最多 40 個並行內聯執行
• 分散式 Map：最多 10,000 個並行子執行
• 分散式 Map 可以從 S3 讀取輸入

常見問題 (FAQ) — Step Functions、MWAA 與 EventBridge 熱門問題

Q1 — 對於新的資料流水線，我該如何在 Step Functions 和 MWAA 之間做選擇？

當流水線複雜度適中（20 步以內）、團隊沒有現成的 Airflow 專業知識、工作負載是突發性的而非持續性的，且比起持續基準成本更偏好按轉換次數計費時，請選擇 Step Functions。當團隊擁有現成的 Airflow DAG 且需要移植、工作負載涉及數十個具有 Python 邏輯和 Airflow 特有功能（XCom, 感測器, 龐大的運算子生態系統）的複雜 DAG，且工作負載量足以支撐每月基準成本時，請選擇 MWAA。成本平衡點大約在每月 1400 萬次轉換 — 低於此數值，Step Functions 在成本上勝出；高於此數值，MWAA 的固定費率更具經濟效益。DEA-C01 考試會通過顯式的成本問題來考查： 「小型團隊、簡單線性工作流、成本敏感」=> Step Functions； 「擁有 50 多個 DAG、現有 Airflow 程式碼、Python 密集邏輯的資料工程平台」=> MWAA。在需要簡單性和低基準成本的情境中避免選用 MWAA；在面對真正複雜的 Airflow 工作負載時避免選用 Step Functions。

Q2 — Step Functions 的標準工作流程與高速工作流程有什麼區別？

標準工作流程是「最多一次」執行，狀態可保留長達一年，控制台中可見 90 天的完整執行歷史，按轉換次數計費（每百萬次 25 美元）。高速工作流程是「至少一次」執行，最長持續 5 分鐘，歷史記錄僅寫入 CloudWatch Logs，按執行次數計費（類似 Lambda）。將標準模式用於 ETL 流水線、多步業務流程以及任何需要稽核歷史或運行超過 5 分鐘的工作流。將高速模式用於 IoT 事件處理、API 請求編排以及高 TPS 的 5 分鐘內微批次 — 在高交易量下，高速模式比標準模式便宜約 100 倍。DEA-C01 考試將此作為成本計算題來考： 「每月 1000 萬次短執行」=> 高速。 「每日 4 小時帶有稽核日誌的多步 ETL」=> 標準。在 1000 萬次的情境中選擇標準模式會浪費大量資金；在 4 小時的情境中選擇高速模式則不可行，因為高速模式在 5 分鐘時會終止。

Q3 — Step Functions 直接服務整合如何取代 Lambda 黏合程式碼？

Step Functions 具有 200 多個與 AWS 服務（Glue, EMR, Athena, Redshift Data API, DynamoDB, S3, SNS, SQS, EventBridge 等）的直接整合，讓您可以從任務 (Task) 狀態原生地調用服務 API，而無需編寫 Lambda 函數。帶有 .sync 後綴的變體會阻塞工作流直至調用的服務完成 — 非常適合編排超過 Lambda 15 分鐘逾時限制的長時間運行的 Glue 或 EMR 工作。直接整合成本更低（無 Lambda 調用費）、運行更快（無 Lambda 冷啟動），並減少了操作介面（無需維護 Lambda 程式碼）。DEA-C01 考試將「Lambda 作為黏合劑」作為錯誤答案模式；正確答案是針對任何 Step Functions 原生支持的 AWS 服務使用帶有 .sync 的直接整合。Lambda 應是處理自定義轉換邏輯的正確工具，而不是用於編排其他 AWS 服務。

Q4 — 我應該在什麼時候使用 EventBridge 排程器而非帶有 cron 表達式的 EventBridge 規則？

EventBridge 排程器是現代的專用排程服務，具備 EventBridge 規則（帶 cron）所缺失的功能：時區支援（任何時區的 cron，而不僅僅是 UTC）、按排程配置的 IAM 角色（每個排程可以取用不同角色）、除了重複性排程外還支援一次性排程、失敗調用的無寄件備份佇列，以及更高的擴展規模（每個區域數百萬個排程）。對於任何新的基於時間的排程需求，請使用排程器。使用帶有事件模式的 EventBridge 規則進行事件驅動路由 — 如對 S3 物件建立、DynamoDB Streams 事件、自定義應用程式事件做出反應。兩者不可互換：排程器是時間驅動的，規則是事件驅動的。DEA-C01 考試將排程器作為「東京時間每天 02:00 觸發流水線」或「特定時間戳的一次性調用」的正確答案。規則則是「對 S3 檔案落地做出反應」的正確答案。

Q5 — 我如何在 Step Functions 工作流中處理錯誤與重試？

每個任務 (Task) 狀態都可以宣告 Retry 和 Catch 區塊。重試指定哪些錯誤代碼觸發重試、間隔時間及指數退避： Retry: [{ErrorEquals: ["States.TaskFailed"], IntervalSeconds: 2, MaxAttempts: 3, BackoffRate: 2.0}] 會在等待 2s, 4s, 8s 後最多重試三次。擷取指定哪些錯誤代碼路由到回退狀態： Catch: [{ErrorEquals: ["States.ALL"], Next: "NotifyOpsTeam", ResultPath: "$.error"}] 將任何未捕獲的錯誤路由到通知狀態並保留錯誤詳情。結合使用它們 — 先重試處理瞬時失敗，若耗盡重試則由擷取處理永久失敗。使用特定的錯誤代碼（如 Glue.AWSGlueException, States.Timeout）而非 States.ALL 以實現細粒度處理。DEA-C01 考試會設定彈性情境題 — 正確答案始終顯示瞬時錯誤用重試，永久錯誤用擷取。

Q6 — Step Functions 的 Map 狀態如何進行平行處理？

Map 狀態針對輸入陣列中的每個項目平行運行同一組狀態。標準 Map 在每個工作流中最多運行 40 個並發內聯執行。分散式 Map (Distributed Map，較新變體) 支持多達 10,000 個並發子執行，可以從 S3（CSV 或 JSON 檔案）讀取輸入，是超大規模平行的正確答案。模式：將 S3 索引鍵陣列作為 Map 狀態的輸入傳遞，Map 對每個索引鍵平行運行一個 Glue ETL 工作，並將結果彙總到一個輸出陣列中。 MaxConcurrency 參數可限制平行度（預設為 0 = 無限制；生產環境應顯式設定以避免壓垮下游服務）。DEA-C01 考試將 Map 作為「在不編寫自定義編排循環的情況下平行處理 1000 個檔案」的正確答案。

Q7 — 對於 ETL 流水線，我可以使用 Glue 工作流程取代 Step Functions 嗎？

Glue 工作流程是內建於 AWS Glue 的輕量級編排器，用於協調 Glue 工作、爬網程序和觸發器。對於 100% 屬於 Glue 的流水線（多個爬網程序、多個 ETL 工作、基於工作狀態的條件分支），請使用 Glue 工作流程。它比 Step Functions 更簡單，且除了 Glue 工作本身外不產生額外費用。對於跨越多個服務（Glue + Redshift + Lambda + EMR + Athena）的流水線，請使用 Step Functions — 其 200 多個直接整合涵蓋了所有這些服務，編排邏輯集中在一個工作流中。決策依據：100% Glue => Glue 工作流程；多服務 => Step Functions。DEA-C01 考試通過情境細節來考查此點。對於大多數生產級資料工程團隊，Step Functions 是適用範圍更廣的選擇；Glue 工作流程則是僅限 Glue 流水線的專用工具。

延伸閱讀 — AWS 官方文件

權威的 AWS 來源包括《AWS Step Functions 開發人員指南》（狀態類型、錯誤處理、直接整合、標準 vs 高速）、《Amazon MWAA 使用者指南》（環境配置、DAG 管理、工作者擴展）、《Amazon EventBridge 使用者指南》（規則、管道、排程器），以及關於 FINRA、Capital One 和 Amazon Music 等公司編排模式的 AWS 大數據部落格系列。AWS Samples GitHub 存儲庫包含將 Step Functions 與 Glue、EMR、Redshift 和 Athena 結合使用的端對端範例工作流。Skill Builder 的 DEA-C01 考試準備標準課程中有專門針對領域 1 任務 1.3 流水線編排的模組。若需更深入的 Airflow 內容，開源的 Apache Airflow 文件以及 AWS MWAA 部落格系列涵蓋了從自建 Airflow 到 MWAA 的遷移模式。AWS Well-Architected 資料分析視角文檔則將編排作為分析階段的一部分，提供了明確的成本與複雜度平衡指導。