AWS Step Functions 與分散式錯誤處理

AWS Step Functions 是最直接對應 AWS Certified Developer Associate（DVA-C02）考試 Task Statement 4.3「利用 AWS 服務與功能優化應用程式」的編排服務，同時也是 Task 4.1 分散式錯誤處理情境的最佳解答。AWS Step Functions 將重試迴圈、逾時管理、巢狀 try/catch 異常處理以及輪詢程式碼從 AWS Lambda 函數中移除，改以 Amazon States Language（ASL）撰寫的 JSON 狀態機取代。在 DVA-C02 中，只要題目提到「編排多個 Lambda 函數」、「管理長時間執行的工作流程」、「實作 saga 模式」、「以指數退避重試」、「對數千個 S3 物件迭代」或「暫停工作流程等待人工審核」，AWS Step Functions 幾乎必然是正確答案。本章訓練你識別 DVA-C02 考試可能出現的每一個 AWS Step Functions 概念——Standard vs Express 工作流程、所有 ASL 狀態類型、內建函數、Retry 與 Catch 語意、以 task token 進行非同步回呼、最佳化服務整合、巢狀工作流程、saga 補償模式，以及 Choice 驅動的斷路器。掌握 AWS Step Functions，就等於一口氣解答了 DVA-C02 Domain 4 約 15% 的題目。

AWS Step Functions 是什麼？

AWS Step Functions 是一個全託管的無伺服器分散式應用程式編排器。使用 AWS Step Functions，你只需以 Amazon States Language（ASL）的 JSON 文件撰寫一個狀態機——一張由具名狀態組成的有向圖，每個狀態都有明確的輸入、明確的輸出以及明確的下一個狀態。AWS Step Functions 透過呼叫 AWS 服務（AWS Lambda、Amazon DynamoDB、Amazon SQS、Amazon SNS、Amazon ECS、AWS Glue、Amazon SageMaker 等等）來執行狀態機，並負責管理重試、追蹤執行歷程，按工作流程類型以狀態轉換次數或執行持續時間計費。

AWS Step Functions 直接解決了 DVA-C02 喜歡考的痛點：AWS Lambda 900 秒逾時限制、透過 SDK 呼叫鏈接時的 AWS Lambda 重試風暴、散落在三個函數中難以追蹤的 try/catch 層層巢狀，以及當請求扇出至五個服務時的可觀測性黑洞。AWS Step Functions 以宣告式狀態機定義、主控台視覺化執行檢視、每個狀態的 CloudWatch 指標，以及集中式的 Retry 和 Catch 語意，取代了上述所有痛點。

AWS Step Functions 在 DVA-C02 考試地圖中的位置

在 DVA-C02 中，AWS Step Functions 主要出現在 Domain 4（疑難排解與優化，18%），但也與 Domain 1 和 Domain 2 有所交疊：

• Domain 1（開發，32%）：AWS Step Functions 作為 AWS Lambda 函數、Amazon DynamoDB 交易、Amazon SQS 扇出以及事件驅動鏈的編排工具。
• Domain 2（安全性，26%）：AWS Step Functions 執行角色呼叫下游服務 API；跨帳號觸發工作流程時的資源型政策。
• Domain 4（疑難排解，18%）：AWS Step Functions 的 Retry 與 Catch 用於分散式錯誤處理、透過編排繞過 AWS Lambda 15 分鐘逾時、saga 補償，以及斷路器。

只要 DVA-C02 題幹提到「編排」、「長時間執行的工作流程」、「視覺化執行」、「跨服務指數退避重試」或「以交易方式協調多個 AWS 服務」，AWS Step Functions 幾乎都是正確答案。

AWS Step Functions 執行模型概覽

每次 AWS Step Functions 執行都遵循相同模式：（1）一次 StartExecution API 呼叫（來自 AWS SDK、EventBridge、API Gateway、Lambda 或另一個狀態機）傳入輸入 JSON；（2）狀態機依序執行每個狀態，沿著 Next 或 Choice 轉換前進；（3）每個 Task 狀態呼叫下游 AWS 服務，等待或輪詢其結果，並套用選擇性的 Retry 和 Catch 邏輯；（4）最終狀態回傳輸出 JSON（Standard）或寫入 CloudWatch Logs（Express）；（5）AWS Step Functions 按狀態轉換次數計費（Standard）或按執行持續時間與記憶體計費（Express）。

白話文解釋

理解 AWS Step Functions 最好的方式是透過生活中已解決相同問題的場景：協調多位專業人員、在某個步驟失敗時優雅恢復，並保留清晰的操作記錄。以下三個類比各自點出 AWS Step Functions 的不同面向——狀態機編排本身、平滑暫時性故障的 Retry 邏輯，以及重試耗盡後導向備援的 Catch 區塊。讀完三個類比，ASL 的詞彙（Task、Choice、Retry、Catch、ResultPath、task token）應該會讓你感覺理所當然，而不是艱澀的術語。

類比一——便當工廠的流水線排程表

把 AWS Step Functions 想像成便當工廠的排程表。排程表就是狀態機定義：第一站是飯鍋（Task 狀態呼叫 Lambda 煮飯），第二站是 Choice 根據當天訂單選擇炒菜或燉肉，第三站是 Parallel 同時進行配菜、裝盒與貼標，最後一站是 Succeed 狀態完成出貨。如果飯鍋壞了，不是讓廚師自行決定，而是排程表指示：先重試三次、再換備用鍋、最後通知主管——這就是 AWS Step Functions 的 Retry 與 Catch。每道步驟都有記錄，品管人員隨時能查閱——這就是 AWS Step Functions 的執行歷程。

類比二——高鐵班次的備援計畫

AWS Step Functions 的 Retry 邏輯就像高鐵排班時已預先規劃的備援方案。當班次出發前，調度系統就已記載：若某區間訊號異常，等待 2 分鐘再試；若連續三次失敗，改走替代路線；若延誤超過上限，通知旅客並啟動補償程序。對應到 Retry 的 IntervalSeconds、BackoffRate、MaxAttempts、MaxDelaySeconds 與 JitterStrategy。列車長不需要在駕駛艙裡臨時起意決策，你的 Lambda 函數也不應該自己寫重試迴圈。AWS Step Functions 用宣告式方式掌管整套復原政策，讓暫時性的下游故障變成例行的備援切換，而非崩潰的工作流程。

類比三——晶圓廠的品管退件機制

AWS Step Functions 的 Catch 區塊就像晶圓廠的品管退件機制。晶片在生產線上逐站加工；若某站發現缺陷無法透過重試修復，品管系統就把這片晶圓送往返工站，而不是讓整條產線停擺。Catch 的 ResultPath 就是貼在晶圓上的追蹤標籤，記載了原始工單與具體缺陷——少了這張標籤，返工站就找不到晶圓的前置資訊。Saga 模式更進一步：若後段製程失敗，系統會倒回每一站的加工，直到產線恢復乾淨狀態。

三個類比合起來，涵蓋了 AWS Step Functions 最擅長的三件事：用單一腳本編排眾多角色、透過宣告式重試政策平滑暫時性故障，以及在重試耗盡時優雅導向補償邏輯。

Standard vs Express 工作流程

AWS Step Functions 提供兩種工作流程類型，在定價、持久性與吞吐量上有根本性的差異。在 DVA-C02 中，Standard 與 Express 的選擇是 AWS Step Functions 最常被考的決策，請冷背以下對照表。

Standard 工作流程

Standard AWS Step Functions 工作流程是原始類型，為長時間執行、可稽核、恰好一次的編排場景而優化。

• 最長執行時間：每次執行 1 年。
• 執行歷程保留：在 Step Functions 服務本身保留 90 天；完整歷程可直接在主控台檢視，不需額外設定。
• 吞吐量：每秒最多 2,000 次 StartExecution API 呼叫，每帳號每 Region 每秒最多 4,000 次狀態轉換（軟性限制）。
• 執行語意：每個工作流程步驟恰好執行一次（exactly-once）。
• 定價：按狀態轉換次數計費（約每次 0.000025 USD）。
• 適用場景：訂單履行、ETL 管線、人工審核流程、SageMaker 訓練管線、基礎設施佈建。

當 DVA-C02 題幹提到「可稽核」、「長時間執行」、「人工審核」、「以小時或天計算」或「恰好一次」時，Standard 是預設答案。

Express 工作流程

Express AWS Step Functions 工作流程是為高量、短暫的事件處理而新增的——本質上是 AWS Step Functions 的「Lambda 速度」版本。

• 最長執行時間：每次執行 5 分鐘。
• 執行歷程保留：AWS Step Functions 服務本身不保留任何歷程；你必須設定 CloudWatch Logs 來捕捉歷程，否則事後除錯無從下手。
• 吞吐量：每帳號每 Region 每秒超過 100,000 次執行。
• 執行語意：兩種子類型——Synchronous Express（呼叫者等待結果，at-most-once）與 Asynchronous Express（fire-and-forget，at-least-once）。
• 定價：按執行次數加上每 GB-秒記憶體使用量計費（類似 AWS Lambda 計費方式），對高量短流程通常比 Standard 便宜。
• 適用場景：串流資料處理、IoT 擷取、行動後端請求驗證、高 TPS API 編排。

當 DVA-C02 題幹提到「高量」、「短暫執行」、「每秒數千次」、「每次執行低成本」或「IoT／串流」時，Express 是預設答案。

巢狀工作流程：Standard 呼叫 Express

一個經典的 AWS Step Functions 模式是：Standard 工作流程編排長時間執行的步驟，並透過 arn:aws:states:::states:startExecution.sync 最佳化整合呼叫 Express 子工作流程來處理高吞吐量子任務。Standard 父工作流程等待 Express 子工作流程完成，如此既能在父層取得 exactly-once 稽核，又能在子層享有 100,000 TPS 的吞吐量。當 DVA-C02 情境混合了含有審核步驟的業務流程與大量處理子程序時，這個模式就是考點。

Amazon States Language（ASL）狀態類型

每個 AWS Step Functions 狀態機都是一份 JSON 文件，其頂層的 States 物件將狀態名稱映射至八種狀態類型之一。DVA-C02 考試要求你熟練掌握全部八種。

Task 狀態

Task 狀態代表由下游 AWS 服務或 Activity worker 執行的一個工作單元。Task 狀態有一個 Resource 欄位，可以是 Lambda ARN、服務整合 ARN（arn:aws:states:::sqs:sendMessage）或 Activity ARN。

"ValidateOrder": {
  "Type": "Task",
  "Resource": "arn:aws:lambda:us-east-1:111122223333:function:ValidateOrder",
  "Next": "ChargeCustomer",
  "TimeoutSeconds": 30,
  "HeartbeatSeconds": 10,
  "Retry": [ { "ErrorEquals": ["States.TaskFailed"], "MaxAttempts": 3, "IntervalSeconds": 2, "BackoffRate": 2.0 } ],
  "Catch": [ { "ErrorEquals": ["States.ALL"], "Next": "RefundAndFail", "ResultPath": "$.error" } ]
}

Task 是最核心的狀態類型。DVA-C02 的大多數情境題都圍繞著在 Task 狀態上設定 Retry 和 Catch。

Choice 狀態

Choice 狀態根據輸入資料進行分支。

"IsBigOrder": {
  "Type": "Choice",
  "Choices": [
    { "Variable": "$.total", "NumericGreaterThan": 1000, "Next": "FraudCheck" },
    { "Variable": "$.country", "StringEquals": "US", "Next": "USFulfillment" }
  ],
  "Default": "StandardFulfillment"
}

Choice 狀態沒有 Retry 或 Catch——它純粹用於路由。若沒有任何 Choice 分支匹配，Default 欄位是必填的；省略它會引發 States.NoChoiceMatched 錯誤。

Parallel 狀態

Parallel 狀態將執行分叉為 N 個獨立分支，並將結果合併為一個陣列。

"FraudAndInventory": {
  "Type": "Parallel",
  "Branches": [
    { "StartAt": "FraudCheck", "States": { "FraudCheck": { "Type": "Task", "Resource": "...", "End": true } } },
    { "StartAt": "InventoryReserve", "States": { "InventoryReserve": { "Type": "Task", "Resource": "...", "End": true } } }
  ],
  "Next": "ChargeCustomer"
}

所有分支都必須成功；任何一個分支的錯誤都會傳遞至 Parallel 狀態本身的 Retry/Catch。

Map 狀態

Map 狀態對陣列進行迭代，對每個元素執行相同的子工作流程。有兩種模式：inline（舊版，最多 40 個並發迭代，在父執行實例中運行）與 distributed（2022 年新增，最多 10,000 個並發子執行，可對 S3 前綴或 S3 物件中的 CSV/JSON 列進行迭代）。

"ProcessItems": {
  "Type": "Map",
  "ItemsPath": "$.items",
  "MaxConcurrency": 10,
  "ItemProcessor": {
    "ProcessorConfig": { "Mode": "INLINE" },
    "StartAt": "ProcessOne",
    "States": { "ProcessOne": { "Type": "Task", "Resource": "...", "End": true } }
  },
  "Next": "Summarize"
}

舊版的 Iterator 關鍵字已廢棄；ASL 2022 改用 ItemProcessor。distributed Map 是 AWS Step Functions 對「迭代一百萬個 S3 物件」情境的答案——將 ProcessorConfig.Mode 設為 DISTRIBUTED，並讓 ItemReader 指向 S3 bucket 前綴或 CSV/JSON 檔案。

Pass 狀態

Pass 是無操作狀態（no-op）。它可以透過 Result、ResultPath、InputPath 和 OutputPath 轉換輸入/輸出，而不呼叫任何服務。用 Pass 來注入常數、重塑 payload 或新增除錯檢查點。

Wait 狀態

Wait 暫停工作流程。可以等待固定時間長度（Seconds）或等到絕對時間戳（TimestampPath）。

"WaitAnHour": { "Type": "Wait", "Seconds": 3600, "Next": "SendReminder" }

AWS Step Functions Standard 的 Wait 狀態是免費的——等待期間沒有任何運算資源在運行。這比起用 Lambda setTimeout 佔用並發配額並燃燒 Lambda 秒數，是巨大的優勢。

Succeed 狀態

Succeed 是終止狀態，以成功結束執行。沒有 Next 欄位。

Fail 狀態

Fail 是終止狀態，以錯誤名稱與原因結束執行。用於在補償邏輯執行完成後的 Catch 區塊內，或用來短路某個 Choice 分支。

AWS Step Functions 內建函數

內建函數（Intrinsic Functions）讓你在 ASL 中轉換資料，而不需要呼叫 Lambda 函數，省去一次函數呼叫的開銷與費用。它們可用於任何接受 .$ 後綴 JSONPath 參考的欄位。

核心內建函數

• States.Format(template, args...) — 類似 sprintf 的字串模板。例如：States.Format('訂單 {} 總金額 ${}', $.orderId, $.total)。
• States.StringSplit(string, separator) — 將字串拆分為陣列。適用於解析 CSV 標頭或 CloudWatch 日誌行。
• States.JsonMerge(obj1, obj2, deepMerge) — 合併兩個 JSON 物件。deepMerge=true（布林值）會遞迴合併巢狀物件。
• States.Array(values...) — 從任意值建構陣列。
• States.ArrayContains(array, value) — 在 Choice 中進行布林成員測試。
• States.ArrayGetItem(array, index) — 零索引元素存取。
• States.ArrayLength(array) — 陣列大小。
• States.ArrayPartition(array, chunkSize) — 拆分為區塊；在 Map 狀態前進行批次處理時不可或缺。
• States.ArrayRange(start, end, step) — 產生數字陣列（類似 Python 的 range）。
• States.ArrayUnique(array) — 去重複。
• States.Base64Encode(string) / States.Base64Decode(base64String) — 常用於 S3 物件鍵與 Cognito claim。
• States.Hash(string, algorithm) — SHA-256 等，用於冪等性金鑰。
• States.JsonToString(obj) / States.StringToJson(string) — 序列化/解析。
• States.MathAdd(a, b) / States.MathRandom(start, end) — 算術輔助函數。
• States.UUID() — 產生唯一 ID 作為冪等性 token。

在 Payload 中使用內建函數

"BuildMessage": {
  "Type": "Pass",
  "Parameters": {
    "greeting.$": "States.Format('您好 {}，訂單 {} 狀態為 {}', $.user, $.orderId, $.status)",
    "combined.$": "States.JsonMerge($.base, $.overrides, false)",
    "idempotencyKey.$": "States.UUID()"
  },
  "Next": "Notify"
}

在 DVA-C02 中，考試很少逐一考每個內建函數的名稱，但 States.Format、States.StringSplit、States.JsonMerge 和 States.UUID 確實會出現在「哪個 AWS Step Functions 功能可以取代這個 Lambda？」的情境題中。

錯誤處理深度剖析：Retry 與 Catch

錯誤處理是 AWS Step Functions 考試範圍中最豐富的礦脈。每個 Task、Parallel 和 Map 狀態都支援 Retry 陣列和 Catch 陣列。掌握本節，Domain 4 就會變得可預測。

內建錯誤名稱

AWS Step Functions 將下游錯誤正規化為具名字串，供 ErrorEquals 匹配：

• States.ALL — 萬用字元，匹配所有錯誤（除了少數終止類錯誤）。永遠放在 Retry/Catch 規則的最後。
• States.Timeout — 狀態超過了 TimeoutSeconds 或 HeartbeatSeconds。
• States.TaskFailed — 下游服務或 Lambda 回傳了錯誤。
• States.Permissions — AWS Step Functions 執行角色缺乏呼叫目標所需的權限。
• States.ResultPathMatchFailure — 輸出無法在 ResultPath 合併。
• States.ParameterPathFailure — Parameters 中的 JSONPath 無法解析。
• States.BranchFailed — Parallel 的某個分支失敗。
• States.NoChoiceMatched — Choice 沒有匹配的規則且沒有 Default。
• States.IntrinsicFailure — 內建函數拋出例外（例如 States.JsonToString 對無效 UTF-8 字串操作）。
• States.ExceedToleratedFailureThreshold — distributed Map 超過其失敗容忍度。

Lambda 函數也可以拋出自訂錯誤名稱，方法是讓函數拋出以類別/名稱作為錯誤名稱的例外（Python：class OrderNotFoundError(Exception)；Node.js：throw { name: 'OrderNotFoundError', message: '...' }）。自訂名稱在 ErrorEquals 中的匹配優先於 States.ALL。

Retry 欄位

Retry 是一個按順序評估的規則清單。每條規則指定：

• ErrorEquals — 此規則匹配的錯誤名稱清單。
• IntervalSeconds — 第一次重試前的等待時間（預設值為 1）。
• MaxAttempts — 最大重試次數（預設值為 3；設為 0 表示停用重試）。
• BackoffRate — 每次重試後套用於 IntervalSeconds 的乘數（預設值為 2.0）。
• MaxDelaySeconds（2023 年新增）— 指數退避的上限。
• JitterStrategy（2023 年新增）— FULL 或 NONE，分散重試時機以避免驚群效應。

"Retry": [
  { "ErrorEquals": ["OrderNotFoundError"], "MaxAttempts": 0 },
  { "ErrorEquals": ["Lambda.TooManyRequestsException", "Lambda.ServiceException"],
    "IntervalSeconds": 2, "MaxAttempts": 6, "BackoffRate": 2.0, "MaxDelaySeconds": 60, "JitterStrategy": "FULL" },
  { "ErrorEquals": ["States.ALL"], "IntervalSeconds": 1, "MaxAttempts": 2, "BackoffRate": 2.0 }
]

規則在每次失敗時由上到下評估；使用第一條匹配的規則。MaxAttempts: 0 表示「此錯誤為終止性錯誤，不重試」——這是業務錯誤（如「找不到訂單」）的常見模式，因為重試毫無意義。

Catch 欄位

Catch 在所有 Retry 嘗試耗盡後執行。每條 Catch 規則指定：

• ErrorEquals — 錯誤名稱清單。
• Next — 要轉換到的備援狀態。
• ResultPath — 將錯誤物件注入到狀態輸入的位置。

"Catch": [
  { "ErrorEquals": ["States.Timeout"], "Next": "NotifyOpsAndFail", "ResultPath": "$.timeoutError" },
  { "ErrorEquals": ["States.ALL"], "Next": "CompensateAndFail", "ResultPath": "$.error" }
]

ResultPath：在錯誤時保留原始輸入

ResultPath 是大多數考生最容易忽略的關鍵細節。預設情況下，Catch 區塊會用錯誤物件取代狀態輸入，摧毀下游補償邏輯所需的業務 payload（orderId、customerId 等）。將 ResultPath 設為子節點（例如 $.error），AWS Step Functions 就會將錯誤附加在原始輸入旁邊，讓 Catch 目標狀態收到 { "orderId": "O-123", "customerId": "C-1", "error": { "Error": "States.Timeout", "Cause": "..." } }。

"ChargeCustomer": {
  "Type": "Task",
  "Resource": "arn:aws:lambda:...:ChargeCustomer",
  "Retry": [{ "ErrorEquals": ["States.ALL"], "MaxAttempts": 3, "BackoffRate": 2, "IntervalSeconds": 2, "JitterStrategy": "FULL" }],
  "Catch": [{ "ErrorEquals": ["States.ALL"], "ResultPath": "$.chargeError", "Next": "RefundAndNotify" }],
  "End": true
}

逾時與心跳

每個 Task 狀態都支援 TimeoutSeconds（允許的總時間）與 HeartbeatSeconds（Activity worker 或 waitForTaskToken 回呼的最大靜默時間）。若任一觸發，AWS Step Functions 就會引發 States.Timeout，由你的 Retry/Catch 攔截處理。若未設定 TimeoutSeconds，卡住的任務會永遠等待（Standard 最長等到 1 年）。每個 Task 都應設定合理的逾時——這是 AWS Well-Architected 最佳實踐，也是 DVA-C02 的愛考點。

服務整合模式

AWS Step Functions 提供三種呼叫下游 AWS 服務的方式。了解哪種模式適用於哪種情境，是 DVA-C02 的必備知識。

Request-Response（直接）整合

Resource ARN 格式：arn:aws:states:::<service>:<action>。AWS Step Functions 呼叫服務 API，接收同步回應，然後繼續執行。例如：arn:aws:states:::sqs:sendMessage。不等待下游工作「完成」——只等待 API 呼叫回傳。

Run-a-Job（.sync）整合

Resource ARN 格式：arn:aws:states:::<service>:<action>.sync。AWS Step Functions 呼叫服務 API，然後輪詢或訂閱服務的完成事件，讓 Task 狀態保持開啟直到下游任務真正完成。支援長時間執行的服務，如 AWS Batch、Amazon ECS RunTask、AWS Glue StartJobRun、Amazon EMR、Amazon SageMaker 訓練任務、Amazon Step Functions 子執行，以及 AWS CodeBuild 專案。這就是 Standard 狀態機在不撰寫任何輪詢 Lambda 的情況下「等待一個 45 分鐘 ECS 任務完成」的方式。

Wait-for-Callback（.waitForTaskToken）整合

Resource ARN 格式：arn:aws:states:::<service>:<action>.waitForTaskToken。AWS Step Functions 呼叫服務 API，將 task token 注入 payload，然後無限期暫停 Task 狀態（Standard 最長 1 年）。某個場外 worker——點擊電子郵件連結的人類、內部部署流程或等待 SQS 的 Lambda——最終呼叫 SendTaskSuccess(taskToken, output) 或 SendTaskFailure(taskToken, error, cause) 來恢復工作流程。

這是 AWS Step Functions 對以下情境的標準答案：

• 人工審核流程（帶有「核准/拒絕」連結的電子郵件，連結打到 API Gateway → Lambda → SendTaskSuccess）。
• 第三方整合（第三方以非同步方式回呼）。
• 透過 Activity API 拉取任務的內部部署 worker。

對於長時間執行的回呼，worker 定期呼叫 SendTaskHeartbeat(taskToken)；若 Task 狀態的 HeartbeatSeconds 在沒有心跳的情況下到期，AWS Step Functions 就會引發 States.Timeout。

"WaitForApproval": {
  "Type": "Task",
  "Resource": "arn:aws:states:::sns:publish.waitForTaskToken",
  "Parameters": {
    "TopicArn": "arn:aws:sns:us-east-1:111122223333:ApprovalTopic",
    "Message": {
      "orderId.$": "$.orderId",
      "taskToken.$": "$$.Task.Token"
    }
  },
  "TimeoutSeconds": 86400,
  "HeartbeatSeconds": 3600,
  "Next": "Fulfill"
}

$$.Task.Token 是產生當前 task token 的 context object 路徑。

AWS 服務的最佳化整合

AWS Step Functions 為高使用率服務提供一流的最佳化整合。DVA-C02 的關鍵整合：

• AWS Lambda（lambda:invoke、lambda:invoke.waitForTaskToken）— 同步或以回呼方式呼叫函數。
• Amazon DynamoDB（dynamodb:putItem、dynamodb:getItem、dynamodb:updateItem、dynamodb:deleteItem）— 直接從 Task 狀態進行 DynamoDB CRUD，不需要 Lambda。
• Amazon SQS（sqs:sendMessage、sqs:sendMessage.waitForTaskToken）— 有或沒有回呼的訊息入列。
• Amazon SNS（sns:publish、sns:publish.waitForTaskToken）— 發布至主題，可選用 task token 進行審核流程。
• Amazon ECS / AWS Fargate（ecs:runTask、ecs:runTask.sync、ecs:runTask.waitForTaskToken）— 啟動任務，可選擇性地阻塞直到完成。
• AWS Glue（glue:startJobRun、glue:startJobRun.sync）— 啟動 ETL 任務並等待完成。
• Amazon SageMaker（sagemaker:createTrainingJob.sync、sagemaker:createEndpoint.sync 等）— 編排 ML 訓練/部署，不需要 Lambda 輪詢迴圈。
• AWS Batch（batch:submitJob.sync）— 執行容器化運算任務。
• Amazon EventBridge（events:putEvents）— 發布事件至 event bus。
• AWS Step Functions（states:startExecution、states:startExecution.sync）— 巢狀工作流程。

每個最佳化整合都省去了一個包裝 Lambda，並消除了相關的冷啟動、IAM 角色和計費項目。

以 Task Token 進行非同步回呼

Task token 值得獨立一節說明，因為它是人機協作工作流程的基礎，也是 DVA-C02「暫停工作流程直到外部事件發生」情境最優雅的答案。

回呼生命週期

1. AWS Step Functions 進入帶有 Resource: ...:.waitForTaskToken 的 Task 狀態。
2. AWS Step Functions 產生唯一的 task token，並透過 $$.Task.Token 將其注入下游 payload。
3. 下游目標（SNS 主題、SQS 佇列、Lambda 函數、ECS 任務、HTTP webhook）連同業務情境一起收到 token。
4. AWS Step Functions 暫停 Task 狀態——Standard 在等待期間不計費。
5. 一個場外 worker 完成其實際工作後，呼叫以下三個 API 之一：
   • SendTaskSuccess(taskToken, output) — Task 以 output 作為狀態結果繼續執行。
   • SendTaskFailure(taskToken, error, cause) — Task 以指定錯誤失敗，觸發 Retry/Catch。
   • SendTaskHeartbeat(taskToken) — 重置 HeartbeatSeconds 計時器而不完成任務。
6. AWS Step Functions 從 Task 恢復狀態機執行。

長時間執行 Worker 的心跳

若 worker 需要一小時，但希望在 worker 崩潰時能快速感知失敗，可設定 HeartbeatSeconds: 300，並讓 worker 每 60 秒呼叫一次 SendTaskHeartbeat。若連續三次心跳未到，AWS Step Functions 就引發 States.Timeout，Retry/Catch 隨即生效。這就是在不等待整整一小時的情況下偵測內部部署 worker 當機的方法。

Activity Worker（舊版模式）

AWS Step Functions 也支援 Activities——長時間存活的 worker 池，透過 GetActivityTask 輪詢並以 SendTaskSuccess/SendTaskFailure 回報。Activities 早於 .waitForTaskToken 存在，對內部部署或非 AWS worker 仍有用。現代程式碼通常偏好以 SNS/SQS 扇出搭配 .waitForTaskToken。

Distributed Map 用於大規模迭代

distributed Map 狀態於 2022 年 12 月推出，是 AWS Step Functions 對「不撰寫 Lambda 協調器就迭代數百萬個 S3 物件」情境的答案。

核心能力

• ItemReader：項目來源。可以是來自狀態輸入的 JSON 陣列、S3 中的 CSV 檔、S3 中的 JSON 陣列檔，或 S3 前綴下的物件清單。
• ItemSelector 與 ItemBatcher：在每個項目傳入 ItemProcessor 前對其整形；可選擇將項目批次分組為 N 個一組以降低開銷。
• MaxConcurrency：最多 10,000 個並發子執行（每個子執行是一個子狀態機執行實例）。
• ToleratedFailurePercentage / ToleratedFailureCount：定義失敗容忍度。超過閾值會在父執行上引發 States.ExceedToleratedFailureThreshold。
• ResultWriter：可選擇將每個子執行的輸出寫入 S3 以供後續聚合，避開 256 KB 狀態輸出大小限制。

大規模 S3 迭代模式

"ProcessAllFiles": {
  "Type": "Map",
  "ItemReader": {
    "Resource": "arn:aws:states:::s3:listObjectsV2",
    "Parameters": { "Bucket": "my-data-bucket", "Prefix": "incoming/" }
  },
  "MaxConcurrency": 1000,
  "ToleratedFailurePercentage": 2,
  "ItemProcessor": {
    "ProcessorConfig": { "Mode": "DISTRIBUTED", "ExecutionType": "EXPRESS" },
    "StartAt": "ProcessOne",
    "States": { "ProcessOne": { "Type": "Task", "Resource": "arn:aws:lambda:...:ProcessFile", "End": true } }
  },
  "ResultWriter": { "Resource": "arn:aws:states:::s3:putObject", "Parameters": { "Bucket": "results-bucket", "Prefix": "run-output/" } },
  "End": true
}

每個子執行本身可以是 Express 類型以獲得最大吞吐量，而父執行維持 Standard 以保留可稽核性。這是 DVA-C02 的標準「Standard 父 + Express 子」模式。

Saga 模式：補償交易

Saga 模式是分散式系統在缺少共享交易管理器的情況下（例如 DynamoDB + Stripe + SNS），實現「最終原子性」的方法。每個步驟都有一個對應的補償動作來撤銷它。AWS Step Functions 是 AWS 上 saga 模式的標準實作方式。

Saga 狀態機骨架

"StartAt": "ReserveInventory",
"States": {
  "ReserveInventory": {
    "Type": "Task", "Resource": "arn:aws:lambda:...:ReserveInventory",
    "Catch": [{ "ErrorEquals": ["States.ALL"], "ResultPath": "$.error", "Next": "FailAndReportNoCompensation" }],
    "Next": "ChargeCustomer"
  },
  "ChargeCustomer": {
    "Type": "Task", "Resource": "arn:aws:lambda:...:ChargeCustomer",
    "Retry": [{ "ErrorEquals": ["States.ALL"], "MaxAttempts": 3, "BackoffRate": 2, "IntervalSeconds": 2 }],
    "Catch": [{ "ErrorEquals": ["States.ALL"], "ResultPath": "$.error", "Next": "ReleaseInventory" }],
    "Next": "ShipOrder"
  },
  "ShipOrder": {
    "Type": "Task", "Resource": "arn:aws:lambda:...:ShipOrder",
    "Retry": [{ "ErrorEquals": ["States.ALL"], "MaxAttempts": 3, "BackoffRate": 2, "IntervalSeconds": 2 }],
    "Catch": [{ "ErrorEquals": ["States.ALL"], "ResultPath": "$.error", "Next": "RefundCustomer" }],
    "End": true
  },
  "RefundCustomer": { "Type": "Task", "Resource": "arn:aws:lambda:...:RefundCustomer", "Next": "ReleaseInventory" },
  "ReleaseInventory": { "Type": "Task", "Resource": "arn:aws:lambda:...:ReleaseInventory", "Next": "FailAndReport" },
  "FailAndReport": { "Type": "Fail", "Error": "SagaFailed", "Cause": "Compensation executed" },
  "FailAndReportNoCompensation": { "Type": "Fail", "Error": "SagaAborted", "Cause": "Failed before any commit" }
}

每個正向 Task 都有一個 Catch，路由至其補償 Task，補償 Task 接著串接至上一個補償。若出貨失敗，就退款給客戶並釋放庫存。若扣款失敗，就只釋放庫存（沒有任何款項被扣，不需退款）。狀態機定義本身就是 saga——不需要外部協調器、不需要分散式鎖、也不需要 Kafka 日誌。

AWS 發布了一個官方 saga 範例專案，以 DynamoDB 訂房為情境（CreateOrder、ReserveFlight、ReserveCar、ReserveHotel，各有對應的 Cancel 補償）。預期 DVA-C02 會出現完全一致的情境題。

以 Choice + CloudWatch 實作斷路器

斷路器防止工作流程對故障中的下游服務持續發起請求。AWS Step Functions 的實作模式是：使用一個 Choice 狀態，透過一個小型 Lambda 探針讀取 CloudWatch 指標警報狀態。

斷路器骨架

"CheckBreaker": {
  "Type": "Task", "Resource": "arn:aws:lambda:...:ReadCircuitBreakerAlarm",
  "ResultPath": "$.breakerState", "Next": "RouteOnBreaker"
},
"RouteOnBreaker": {
  "Type": "Choice",
  "Choices": [
    { "Variable": "$.breakerState.state", "StringEquals": "OPEN", "Next": "FailFast" },
    { "Variable": "$.breakerState.state", "StringEquals": "HALF_OPEN", "Next": "ProbeCall" }
  ],
  "Default": "NormalCall"
}

斷路器 Lambda 呼叫 DescribeAlarms 查看監控下游服務錯誤率的 CloudWatch 警報。若警報為 ALARM（狀態 = OPEN），工作流程快速失敗。若為 INSUFFICIENT_DATA（狀態 = HALF_OPEN），發送一次探針呼叫。若為 OK（狀態 = CLOSED/Default），正常呼叫。此模式防止一個行為異常的服務讓整個系統發生級聯故障——這是 Domain 4 的經典優化技術。

執行歷程與可觀測性

Standard 工作流程執行歷程

Standard AWS Step Functions 工作流程在服務本身保留 90 天的執行歷程，並透過以下方式公開：

• AWS Step Functions 主控台的視覺化執行檢視（點擊任一狀態可查看輸入/輸出/錯誤）。
• GetExecutionHistory API（每頁最多 1,000 個事件）。
• CloudWatch Logs（如有設定）。
• EventBridge 執行狀態變更事件。

每次狀態轉換都會發出 CloudWatch 指標（ExecutionsStarted、ExecutionsSucceeded、ExecutionsFailed、ExecutionsTimedOut、ExecutionsAborted），每個 Task 狀態也會發出每資源指標（LambdaFunctionsTimedOut 等）。

Express 工作流程可觀測性

Express 工作流程在服務中不保留任何歷程。建立狀態機時必須啟用 CloudWatch Logs 記錄。三種日誌層級：

• ALL — 每個歷程事件，成本最高。
• ERROR — 僅記錄失敗事件。
• FATAL — 僅記錄終止性失敗。
• OFF — 不記錄任何內容；讓除錯完全無從下手。

INCLUDE_EXECUTION_DATA 控制是否將輸入/輸出 payload 記錄至日誌（設為 true 時，機密資訊可能出現在日誌中）。對大多數開發工作負載，選擇 ERROR + 執行資料即可。

X-Ray 追蹤

在狀態機上啟用 X-Ray 追蹤，每個 Task 的下游呼叫就會在 X-Ray 服務地圖中被追蹤。用於跨巢狀工作流程和服務整合的深度延遲取證分析。

Step Functions vs Lambda 鏈接 vs EventBridge vs SQS

在 DVA-C02 中，最常見的情境題類型之一是「選擇正確的編排器」。以下是決策矩陣：

選擇 AWS Step Functions 的時機

• 需要明確的、可視覺化的、可重試的、可稽核的流程控制。
• 工作流程有分支（Choice）、扇出（Parallel/Map）或補償（saga）。
• 單一流程超過 AWS Lambda 的 15 分鐘逾時限制。
• 流程中包含人工審核或外部回呼。
• 需要跨多服務交易的 exactly-once 稽核。

選擇直接 AWS Lambda 鏈接（Lambda 呼叫 Lambda 或 SDK）的時機

• 流程只有一個步驟加上最多一個後續動作。
• 不需要超出 AWS Lambda 內建非同步重試的重試編排。
• 從不需要視覺化狀態或逐步驟稽核結果。

選擇 Amazon EventBridge 的時機

• 架構是編舞（choreography）而非編排（orchestration）——生產者發布事件，消費者各自獨立回應。
• 需要以模式為基礎的扇出至多個目標，並支援跨帳號路由。
• 沒有單一參與者擁有「流程」；每個服務自主地回應事件。

選擇 Amazon SQS 的時機

• 模式是生產者-消費者解耦，需要 at-least-once 傳遞和可見性逾時。
• 需要緩衝，而不是工作流程語意。
• 消費者是拉取式的（Lambda event source mapping、ECS 輪詢）。

AWS Step Functions 與 EventBridge 有所重疊，但解決的是不同問題：AWS Step Functions = 編排，EventBridge = 編舞。若 DVA-C02 題目說「一個中央定義控制步驟順序和重試」，答案是 AWS Step Functions；若說「多個服務獨立地對事件做出回應」，答案是 EventBridge。

AWS Step Functions 常見考試陷阱

陷阱一：Express 歷程保留

Express 工作流程在 AWS Step Functions 中不保留任何執行歷程。必須啟用 CloudWatch Logs。Standard 在服務中保留 90 天（行銷文件有時說「1 年」，指的是最長執行持續時間而非歷程保留——不要混淆這兩者）。

陷阱二：At-Most-Once vs At-Least-Once

Express Sync = at-most-once（呼叫者取得結果；若 AWS Step Functions 在完成前崩潰，不會重試）。Express Async = at-least-once（若崩潰發生在執行中途，AWS Step Functions 可能傳遞重複訊息）。Standard = exactly-once。若情境說「恰好一次」，只有 Standard 符合。

陷阱三：Inline vs Distributed Map 並發數

Inline Map 最多 40 個並發迭代；distributed Map 最多 10,000 個。「迭代一百萬個物件」= distributed Map，永遠如此。

陷阱四：Catch 中缺少 ResultPath

沒有 ResultPath，錯誤物件會取代狀態輸入，摧毀補償所需的業務情境。務必設定 ResultPath。

陷阱五：Choice 沒有 Retry

Choice 狀態無法重試——它只做路由。將任何探針邏輯包裝在前一個可重試的 Task 中，然後用 Choice 對其結果進行分支。

陷阱六：Default 在 Choice 中是必填的

在 Choice 中省略 Default，若沒有規則匹配，AWS Step Functions 就會引發 States.NoChoiceMatched。永遠包含 Default。

陷阱七：Task Token vs Activity ARN

.waitForTaskToken 是現代回呼模式。Activities 是舊版輪詢模式。兩者都能用，但 DVA-C02 的題幹通常暗示 .waitForTaskToken，除非情境明確說「內部部署 worker 輪詢工作」。

AWS Step Functions 定價摘要

• Standard：每次狀態轉換約 0.000025 USD（us-east-1）。每月前 4,000 次轉換免費。無每次執行或每持續時間費用。
• Express：按執行次數加上每 GB-秒記憶體使用量再加一小筆每請求費用計費。記憶體依工作負載自動分配（以 64 MB 為增量）。對短時間流程，在超過約每秒 1,000 次執行時，通常比 Standard 便宜。
• CloudWatch Logs（Express）另行收費。
• X-Ray 追蹤另行收費。

對於 DVA-C02，你很少需要確切的價格數字，但你需要知道：Standard 按轉換次數計費，Express 按執行次數加記憶體計費。這個區別驅動了「哪種工作流程類型在高量情境下更便宜？」的情境題。

AWS Step Functions 必背限制

• 最長執行時間：1 年（Standard）、5 分鐘（Express）。
• 狀態機定義最大大小：1 MB。
• 最大執行歷程事件數：25,000（Standard；超過後執行只能 redrive）。
• 狀態輸入/輸出最大大小：256 KB。
• 最大 StartExecution 速率：2,000/s（Standard）、100,000+/s（Express），軟性限制。
• 最大並發執行數：無每狀態機的硬性上限，但帳號層級配額適用。
• Distributed Map 最大子執行並發數：10,000。
• Inline Map 最大並發數：40。
• Task token 回呼最長等待時間：1 年（Standard）。

常見問題——AWS Step Functions

Q1. DVA-C02 中 AWS Step Functions 的一句話定義？

AWS Step Functions 是一個無伺服器編排器，執行以 Amazon States Language 撰寫的 JSON 狀態機，來協調 AWS Lambda 函數和其他 AWS 服務，並內建 Retry、Catch、Parallel、Map、Choice、逾時、透過 task token 的非同步回呼、視覺化執行歷程，以及按轉換次數或按執行計費。在 DVA-C02 中，只要題目提到「編排」、「長時間執行的工作流程」、「視覺化執行」、「分散式錯誤處理」、「saga」或「人工審核」，AWS Step Functions 就是預設答案。

Q2. AWS Step Functions Standard 和 Express 工作流程有什麼差異？

AWS Step Functions Standard 工作流程可執行最長 1 年，在服務中保留 90 天歷程，每秒上限 2,000 次執行，提供 exactly-once 執行語意，並按狀態轉換次數計費——適用於可稽核、長時間執行、人工審核和 ETL 流程。Express 工作流程可執行最長 5 分鐘，在服務中不保留歷程（需要 CloudWatch Logs），每秒可擴展到 100,000+ 次執行，分為 Synchronous（at-most-once）或 Asynchronous（at-least-once），並按執行次數加每 GB-秒計費——適用於高量、短暫的事件處理、IoT 擷取和串流。常見的巢狀模式是 Standard 父 + Express 子（透過 .sync 最佳化整合），以結合稽核性與吞吐量。

Q3. Retry 和 Catch 如何與 AWS Step Functions 中的 ResultPath 互動？

Retry 先執行——AWS Step Functions 依 IntervalSeconds 乘以 BackoffRate（可選擇以 MaxDelaySeconds 設上限，並以 JitterStrategy: FULL 分散）重試 Task 最多 MaxAttempts 次。若所有重試都耗盡，Catch 執行：它在 ErrorEquals 中匹配錯誤名稱，轉換至 Next 狀態，並——關鍵地——將錯誤物件寫入 ResultPath。省略 ResultPath 會以錯誤物件取代整個狀態輸入，摧毀補償邏輯所需的業務 payload。務必將 ResultPath 設為有範圍的鍵（如 $.error），讓備援狀態同時擁有原始輸入和錯誤資訊。

Q4. task token 與 .waitForTaskToken 如何用於人工審核流程？

.waitForTaskToken 是非同步回呼服務整合模式。AWS Step Functions 產生一個 task token，透過 $$.Task.Token 將其注入下游 payload，暫停 Task 狀態，並等待 worker 呼叫 SendTaskSuccess(token, output)、SendTaskFailure(token, error, cause) 或 SendTaskHeartbeat(token)。對人工審核，結合 .waitForTaskToken 與 SNS——審核者點擊電子郵件連結，連結呼叫 API Gateway → Lambda → SendTaskSuccess。設定 TimeoutSeconds 以限制等待時間（Standard 最長 1 年），設定 HeartbeatSeconds 以偵測無回應的 worker。

Q5. .sync 與 .waitForTaskToken 服務整合有什麼差異？

.sync（Run-a-Job）阻塞 Task 直到服務完成事件到達——AWS Step Functions 知道如何輪詢或訂閱 AWS Batch、Amazon ECS、AWS Glue、Amazon SageMaker、AWS CodeBuild 和巢狀 Step Functions 的「任務完成」訊號。你不需要撰寫任何回呼程式碼。.waitForTaskToken 阻塞 Task 直到你自己的 worker 呼叫 SendTaskSuccess/SendTaskFailure——你注入一個 token，任何外部系統都能完成它。經驗法則：若 AWS 已知道服務何時完成，用 .sync；若由人類或第三方系統控制完成，用 .waitForTaskToken。

Q6. 何時應使用 distributed Map vs inline Map vs Lambda 協調器？

Inline Map 是在一個父執行中簡單的扇出，上限為 40 個並發迭代——適用於小型集合。Distributed Map 可擴展到 10,000 個並發子執行，透過 ItemReader 接受 S3 前綴或 CSV/JSON 檔作為輸入來源，支援批次和失敗容忍度（ToleratedFailurePercentage），並可為最大吞吐量生成 Express 子執行——這是 DVA-C02「處理一百萬個 S3 物件」的正確答案。手寫的 Lambda 協調器沒有內建重試、沒有可視性、沒有失敗容忍度設定，並且有 Lambda 逾時的風險——幾乎從來不是考試的正確答案。

Q7. AWS Step Functions 如何實作 saga 模式？

Saga 模式表達「本地交易 + 明確補償」——每個正向 Task 都有一個 Catch 區塊，路由至補償 Task，補償 Task 接著向上串接補償。例如：若出貨失敗，路由至退款客戶 → 釋放庫存 → 失敗。若扣款失敗，路由至釋放庫存 → 失敗（不需退款，沒有任何款項被扣）。補償必須是冪等的，因為執行可能被重試——使用 DynamoDB 條件寫入（attribute_not_exists）或 States.UUID() 冪等性 token。AWS 發布了一個以 DynamoDB 訂房為情境的官方 saga 範例專案作為標準參考。

Q8. 何時應使用 AWS Step Functions vs 直接 AWS Lambda 鏈接 vs EventBridge？

使用 AWS Step Functions 進行編排——一個中央狀態機定義順序、重試、補償和可視性。當流程只有一兩個步驟且不需要明確重試或稽核時，使用直接 AWS Lambda 鏈接（注意這是 AWS Lambda + destinations 解決的模式）。使用 Amazon EventBridge 進行編舞——多個生產者和消費者獨立地對事件做出回應，沒有中央流程擁有者。DVA-C02 的判斷線索：題幹提到「控制步驟順序」、「失敗時補償」、「視覺化執行歷程」或「人工審核」→ AWS Step Functions；題幹提到「多個服務獨立回應」、「模式匹配」或「跨帳號事件路由」→ EventBridge。

Q9. AWS Step Functions 發出哪些 CloudWatch 指標與日誌？

Standard AWS Step Functions 發出每狀態機指標（ExecutionsStarted、ExecutionsSucceeded、ExecutionsFailed、ExecutionsTimedOut、ExecutionsAborted、ExecutionThrottled）以及每 Activity 指標（ActivityRunTime、ActivityScheduleTime、ActivitiesSucceeded 等）。在狀態機層級啟用 CloudWatch Logs 以捕捉完整執行歷程。Express 工作流程在服務中不保留歷程，因此 CloudWatch Logs 是必須的——將日誌層級設為 ALL 或 ERROR 並設定 INCLUDE_EXECUTION_DATA=true 以捕捉輸入/輸出 payload。在狀態機上啟用 X-Ray 追蹤以進行跨服務延遲取證分析。

Q10. DVA-C02 必背的 AWS Step Functions 限制有哪些？

必背：Standard 最長執行 1 年、Express 最長執行 5 分鐘、狀態機定義 1 MB、狀態輸入/輸出 256 KB、Standard 執行歷程事件 25,000、Standard 2,000 exec/s、Express 100,000+ exec/s、distributed Map 10,000 個並發子執行、inline Map 40 個並發、Retry 預設 MaxAttempts 為 3、預設 BackoffRate 為 2.0、預設 IntervalSeconds 為 1 秒、Standard 服務內歷程保留 90 天，以及三種服務整合模式（直接 / .sync / .waitForTaskToken）。這些數字和名稱回答了 AWS Step Functions 上大多數的記憶性題目。

摘要——AWS Step Functions 與分散式錯誤處理一覽

• AWS Step Functions 是 DVA-C02 Domain 4 的無伺服器編排器；它以 Amazon States Language（ASL）撰寫的宣告式 JSON 狀態機取代 Lambda 對 Lambda 的鏈接。
• Standard vs Express：Standard = 1 年、2,000 exec/s、exactly-once、服務內 90 天歷程、按轉換次數計費。Express = 5 分鐘、100,000+ exec/s、需要 CloudWatch Logs、at-most-once（Sync）或 at-least-once（Async）、按執行次數加記憶體計費。
• 八種 ASL 狀態類型：Task、Choice、Parallel、Map（inline 或 distributed）、Pass、Wait、Succeed、Fail。背下每種的功能。
• 內建函數（States.Format、States.StringSplit、States.JsonMerge、States.UUID，以及陣列/數學/雜湊/base64 輔助函數）消滅膠水 Lambda。
• Retry：ErrorEquals、MaxAttempts、IntervalSeconds、BackoffRate、MaxDelaySeconds、JitterStrategy。內建錯誤名稱包含 States.ALL、States.Timeout、States.TaskFailed、States.Permissions、States.NoChoiceMatched。
• Catch：ErrorEquals、Next、ResultPath。務必設定 ResultPath，否則錯誤時業務 payload 會遺失。
• 三種服務整合模式：直接（arn:aws:states:::svc:action）、Run-a-Job（.sync）、Wait-for-Callback（.waitForTaskToken 搭配 SendTaskSuccess/SendTaskFailure/SendTaskHeartbeat）。
• Lambda、DynamoDB、SQS、SNS、ECS、Glue、SageMaker、Batch、EventBridge 和巢狀 Step Functions 的最佳化整合消除了包裝 Lambda。
• Distributed Map 對 S3 前綴或 CSV/JSON 檔最多迭代 10,000 個並發子執行；搭配 Standard 父與 Express 子以兼顧稽核性與吞吐量。
• Saga 模式：正向 Task + 透過 Catch 的補償 Task；補償必須是冪等的。
• 斷路器：透過探針 Task 讀取 CloudWatch 警報狀態的 Choice 狀態。
• Standard 工作流程在主控台公開視覺化執行歷程；Express 工作流程任何事後除錯都需要 CloudWatch Logs。
• 編排（Step Functions）vs 編舞（EventBridge）vs 解耦（SQS）——各自解決不同類型的問題。
• 掌握這些，DVA-C02 Domain 4 的編排情境題就會變得可預測，Task 4.3 的優化答案也會變得顯而易見。