事件驅動與 Serverless 架構設計

事件驅動無伺服器架構是真正區分 Solutions Architect Professional 與 Associate 的設計典範。SAP-C02 任務說明 2.5（效能）和 2.4（可靠性）都指向同一個核心問題：你是否能將 Amazon EventBridge、AWS Step Functions、AWS Lambda、AWS AppSync、AWS IoT Core、Amazon SQS 與 Amazon SNS 組合成一套完整的事件驅動無伺服器架構，使其能擴展至百萬台裝置、遵守 Region 合規邊界、在 Region 故障時存活，並且保持可偵錯性。本章假設你已通過 SAA-C03 的深度要求——Lambda 逾時、Fargate 基礎、SQS fan-out——並直接跳入只有在 Professional 層級才會出現的事件驅動無伺服器架構決策。若對某些 Associate 概念尚不熟悉，請先複習 SAA-C03 的 serverless-and-containers 基礎；在本章中，事件驅動無伺服器架構被視為一項設計學科，而非服務目錄。

為什麼事件驅動無伺服器架構是 Pro 層級學科

SAP-C02 對事件驅動無伺服器架構的考法是一項設計學科，而非個別服務冷知識。考試假設你知道 Lambda 和 EventBridge 是什麼；它要求你為 custom bus 設計相對於 partner bus 的選擇提出理由，在 Standard 與 Express 之間做出選擇（其中有一個 Associate 層級不曾見過的微妙陷阱），判斷何時 EventBridge Pipes 能取代 Lambda transformer，推理 choreography 在 saga rollback 時的崩潰情境，以及在 DynamoDB Streams pipeline 中放置 outbox 以防止 dual-write 問題進入生產環境。這些決策正是事件驅動無伺服器架構成為 Pro 層級的理由。

本主題的每個情境都是一道組合題。SAP-C02 的事件驅動無伺服器架構情境通常呈現三到六項 AWS 服務，並詢問哪種串接策略能同時滿足 RTO、RPO、idempotency、ordering、跨帳號隔離與成本等要求。預期會有多重約束的問題，每個約束都能排除一個候選方案。

Associate 知識假設

Associate 層級的事件驅動無伺服器架構（SAA-C03）假設讀者已具備：

• AWS Lambda 封裝（zip、container image）、15 分鐘上限、10 GB 記憶體、10 GB /tmp、6 MB 同步與 256 KB 非同步 payload、預設每 Region 1000 concurrent executions。
• 基本 SQS fan-out（SNS topic 加兩個 SQS 訂閱者）、DLQ 作為舊版概念、at-least-once delivery。
• EventBridge default bus 接收 AWS 服務事件；簡單的 rule-target 對應；Lambda target。
• Step Functions 存在且有 Standard 與 Express；Express 更便宜且更快。
• API Gateway REST vs HTTP API 與 WebSocket API；Lambda 整合基礎。

SAP-C02 在 Associate 之上新增的內容

事件驅動無伺服器架構在 SAP-C02 層級新增：

• EventBridge 上的 custom、partner 與 global-endpoint bus 設計，含 schema registry、archive 與 replay。
• EventBridge Pipes，無需 Lambda 膠水程式碼即可完成 source-filter-enrich-target。
• 跨帳號與跨 Region 事件路由，以及各方案的 quota、IAM 與故障語義。
• Step Functions 模式：saga、callback task tokens、Map iteration（inline vs distributed）、Parallel、Choice、透過 Retry 加 Catch 加 DLQ 實現 circuit breaker。
• Lambda 大規模部署：reserved 加 provisioned 加 SnapStart 組合、帳號層級配額與每個函式配額、burst 與 sustained concurrency、cold-start 緩解決策樹。
• AppSync 作為事件驅動前端的即時 GraphQL subscriptions。
• IoT Core rules engine 作為裝置群的第一等事件源。
• Choreography vs orchestration 在規模下的取捨。
• 透過 DynamoDB Streams 實現 outbox pattern 以修復 dual-write 問題。
• DLQ 加 redrive 加 observability 作為第一等可靠性考量。

白話文解釋 Event-Driven Serverless Architecture

要在 Pro 層級真正內化事件驅動無伺服器架構，不能再只靠 SAA-C03 的廚房類比。以下三組不同類別的類比幫你在面對 SAP-C02 多約束情境時，迅速在腦中定位每個服務的責任邊界。

類比一：24 小時便利商店物流系統

把事件驅動無伺服器架構當成台灣遍布全島的 24 小時便利商店物流網。事件（event）就是訂貨單，EventBridge 是物流總調度中心，SQS 是各門市的訂貨收件箱，SNS 是批次廣播系統，Lambda 是配送員，Step Functions 是多站配送排班中心，AppSync 是即時門市庫存看板：

• EventBridge default bus 像是總公司固有的配送網：所有 AWS 公家機關（service events）的訂單自動進入。
• Custom bus 像是各品牌自有的門市物流線，只處理自己品牌的訂單，與總公司通路分開。
• Partner bus 像是外部供應商（統一、黑貓宅急便等第三方）的專屬窗口，只有那個供應商能放貨。
• Global endpoint 像是當台北總倉（primary Region）發生火災，訂單自動切到桃園備用倉（secondary Region）繼續出貨。
• Archive + replay 像是物流系統錄影：某批訂單兩週前因系統 bug 沒有正確出貨，直接從錄影重播那批訂單再配送一次。
• EventBridge Pipes 像是倉庫內的自動分揀輸送帶，直接把從供應商端（Kinesis/DynamoDB stream）進來的箱子，經過篩選、補充資料（enrichment），送往目的地，不需要派一個配送員（Lambda）當中間人。

在事件驅動無伺服器架構下，當你思考「誰負責送、誰負責收、誰負責路由」時，便利商店物流的分層能讓多約束情境變成直覺。

類比二：醫院急診與手術室流程

把事件驅動無伺服器架構當成醫院流程，最容易理解 choreography 與 orchestration 的差別：

• Choreography（各科自主）像急診室：每個科醫生（service）依照自己 SOP 回應病患狀態（event），沒有總指揮。擴展性好，但一旦病情複雜出錯，誰該負責回滾（rollback）就很難說清楚。
• Orchestration（主刀指揮）像手術室：Step Functions 是主刀醫師，明確呼叫麻醉、器械、護理的順序，錯誤時走 Catch 到清創處理。每一步可視、可重試。
• Saga pattern 像連續開刀失敗後的反向補償：第三步失敗時，倒回去把第二步的縫合線、第一步的麻醉劑都補償（compensating action）掉。
• Callback task token 像病人要等外部檢驗所結果才能決定下一步手術，主刀醫師給檢驗所一張紙條（token），等結果回來才繼續。
• Circuit breaker（Retry + Catch + DLQ）像急救流程重試三次 CPR，不行就送 ICU（DLQ）由另一組人處理。

事件驅動無伺服器架構的 reliability 設計在於：什麼流程該用急診室的鬆耦合、什麼流程必須用手術室的嚴格編排。

類比三：台北 MRT 供電與備用電力調度

把事件驅動無伺服器架構當成 MRT 的供電系統，最能理解 Lambda concurrency 與 throttling：

• Account concurrency quota（1000 預設） 像整條 MRT 路網的總變電容量。
• Reserved concurrency 像某個大型轉乘站（忠孝復興）的獨立供電線，不會被住宅區搶電，但超過容量就斷電（throttle）。
• Provisioned concurrency 像預先發動的備用柴油機，待命但要付燃料費（hourly charge）；尖峰時刻瞬間接手，沒有冷啟動時間。
• SnapStart 像預熱完成的月台照明系統：Java、.NET、Python 的應用程式啟動時間從冷機的數秒降到次秒級，不收額外費用。
• Burst concurrency 像變電站短時間允許超額，但只能撐幾分鐘（Regional burst：每分鐘 500 或 1000 或 3000 units，視 Region 而定），之後回到穩態。
• SQS buffering 像電池儲能：尖峰湧入時先進電池，再緩慢放電給消費端，避免下游過載。

三組類比交互使用，你就能在腦中同時維護「路由層、流程層、容量層」三個圖示，不再看到 EventBridge 就想 Lambda，看到 Step Functions 就想 orchestration。

事件驅動無伺服器架構的核心設計原則

SAP-C02 的事件驅動無伺服器架構由五項反覆出現的設計原則主導。每個情境至少測試其中兩項。

原則一：事件是事實，而非命令

事件記錄已發生的事情（OrderPlaced、PaymentFailed）且不可變。命令則告訴特定接收者做某件事（ChargeCard）。事件驅動無伺服器架構之所以能擴展，是因為任意數量的訂閱者都能回應同一個事實，而無需生產者知曉。SAP-C02 的問題用這個區別來篩選答案：若情境說某個發送者必須知道接收者成功執行，那就是命令模式，可能需要 Step Functions 或同步的 API Gateway 加 Lambda，而非 EventBridge fan-out。

原則二：假設 At-Least-Once Delivery，為 Idempotency 設計

事件驅動無伺服器架構中的每個 AWS 事件 broker（EventBridge、SQS Standard、SNS、Kinesis Data Streams、DynamoDB Streams）在故障情況下都是 at-least-once。SAP-C02 期望架構師使用儲存在 DynamoDB 中含 conditional writes 的 idempotency key、Powertools 風格的 idempotency decorator，或資料庫唯一約束來設計 idempotent consumers。只有 SQS FIFO 和 SNS FIFO 提供 exactly-once，但它們有吞吐量上限。

原則三：將生產者規模與消費者規模解耦

事件驅動無伺服器架構在生產者與消費者之間插入耐久緩衝（SQS、Kinesis、DynamoDB Streams），讓爆量不會壓垮下游。消費者上的 Lambda reserved concurrency 與 SQS 的 visibility timeout 共同塑造消費曲線。此原則在 dual-write 情境中強制使用 outbox pattern。

原則四：Observability 是架構的一部分

沒有追蹤的事件驅動無伺服器架構是無法維護的。AWS X-Ray 透過傳播 header 追蹤 API Gateway、Lambda、Step Functions、EventBridge 與 SQS 之間的請求；CloudWatch Embedded Metrics Format（EMF）寫入結構化指標；CloudWatch Logs Insights 跨所有函式 log group 查詢。SAP-C02 定期測試沒有追蹤就無法偵錯的故障情境。

原則五：Region 與帳號邊界是政策，而非技術

事件驅動無伺服器架構的情境常要求個人識別資訊（PII）必須留在某個 Region，或安全事件必須從工作負載帳號跨越到中央安全帳號。EventBridge 跨帳號 bus、resource-based policies 與 PrivateLink 的存在，正是為了將這些政策編碼為基礎設施。

Amazon EventBridge Bus 深度設計

EventBridge 是 AWS 上事件驅動無伺服器架構的核心 broker。SAP-C02 要求深入掌握 bus 類型、rule targets、schema 管理、archive and replay、Pipes 與 global endpoints。

Bus 類型：Default vs Custom vs Partner

EventBridge 有三類 bus，事件驅動無伺服器架構設計從正確選擇開始：

• Default event bus 在帳號建立時每個 Region 就會存在。它自動接收來自 AWS 服務的事件（EC2 狀態變更、啟用 EventBridge 通知時的 S3 物件事件、CodePipeline 狀態等）。你無法刪除它；你不應該在此發布自訂領域事件，因為將 AWS 來源與應用程式來源的事件混在同一個 bus 上，會在規模化時造成 rule 混亂。
• Custom event bus 依業務領域或 bounded context 建立。良好的事件驅動無伺服器架構做法是每個 bounded context（Orders、Payments、Inventory）使用一個 custom bus，使 rule 集合與保留政策能與領域所有權對齊。
• Partner event bus 接收來自 SaaS 合作夥伴（Auth0、Datadog、Zendesk、Shopify、PagerDuty、Stripe 等許多夥伴）的事件。你無法向 partner bus 發布事件；只有合作夥伴能發布。每個合作夥伴來源在你啟用整合時會自動佈建一個專屬的 partner bus。

EventBridge Rules、Targets 與 Content-Based Filtering

每個 bus 持有 rules，對進入的事件進行模式比對並路由至最多五個 targets per rule。Rule patterns 支援：

• 事件屬性的精確比對（"source": ["orders.service"]）。
• 前綴比對（"prefix": "ord"）。
• Anything-but 比對、數值比對、IP CIDR 比對、exists 檢查。
• 對 detail JSON 區塊內的巢狀屬性比對。

支援的 targets 包括 Lambda、Step Functions state machine、SQS、SNS、Kinesis Data Streams、Kinesis Firehose、ECS task、Batch job、API destination（對外 HTTPS）、另一個 EventBridge bus（包含跨帳號或跨 Region）、API Gateway 與 SageMaker pipeline。

Schema Registry 與 Schema Discovery

EventBridge Schema Registry 儲存描述 bus 上事件的 JSON 或 OpenAPI schema。你可以啟用 schema discovery，讓 EventBridge 從實際流過的事件推斷 schema；你可以為 Java、Python、TypeScript 產生程式碼綁定以獲得靜態型別事件物件。在 Professional 規模的事件驅動無伺服器架構中，schema registry 透過明確的 schema 版本控制，防止靜默的破壞性變更——生產者新增欄位而消費者的 parser 崩潰。

Archive and Replay

每個 custom bus 都可以附加一個保留期從一天到無限期的 archive。Archive 儲存符合條件的事件副本；replay 將 archived 事件重新處理到原始 bus，重新觸發所有 rules 和 targets，並可指定時間範圍與選用的 rule filter。Archive and replay 是 SAP-C02 對以下問題的標準答案：

• 「payment-completed handler 中的 bug 導致兩小時內的事件遺失；我們如何重新處理而不重播上游系統？」
• 「DR：Region failover 後，我們如何在 secondary Region 重新處理過去 24 小時的事件？」
• 「測試：我們如何將生產環境的真實事件負載注入暫存環境？」

EventBridge Pipes：無需 Lambda 的 Source 到 Target

EventBridge Pipes 是一種點對點整合，能取代膠水 Lambda 函式。一個 Pipe 有四個階段：Source（SQS、Kinesis、DynamoDB Streams、Kafka、MQ 等）、選用的 filter expression、選用的 enrichment（Lambda、Step Functions Express、API destination、API Gateway），以及 target（任何 EventBridge target）。Pipes 對事件驅動無伺服器架構很重要，因為它們：

• 消除樣板 Lambda 程式碼（其唯一工作是轉發、過濾或重塑事件）。
• 原生提供 batching、retries 與 DLQ。
• 按事件和 enrichment 呼叫計費，而非按 Lambda 毫秒計費。
• 為有序來源（Kinesis shard、DynamoDB Stream shard、SQS FIFO group）維護事件順序。

典型的 Pipes 使用案例：

• DynamoDB Streams 到 EventBridge bus，使用過濾器丟棄 eventName == REMOVE。
• Kinesis Data Stream 到 Step Functions Express，使用 enrichment Lambda 查詢客戶等級。
• SQS FIFO 到 ECS RunTask，target 執行有序批次處理。

跨帳號與跨 Region 事件路由

在多帳號事件驅動無伺服器架構中，EventBridge 支援：

• 跨帳號 targets：帳號 A 中的 rule，其 target 是帳號 B 中的 bus。帳號 B 的 bus 需要一個允許帳號 A 執行 events:PutEvents 的 resource-based policy。
• 組織全域政策：在 resource policy 中使用 aws:PrincipalOrgID 條件，授予組織中任何帳號的權限。
• 跨 Region targets：Region X 中的 rule，target bus 在 Region Y。適用於集中審計或配對 DR Region。跨 Region 會增加延遲，並在目的地 Region 收取 PutEvents 費用。

Global Endpoints 實現多 Region 韌性

EventBridge global endpoints 提供一個跨兩個 Region 的 active-passive 事件擷取 endpoint，並與 Route 53 health check 配對。生產者發布到單一 global endpoint URL；EventBridge 路由到健康的 primary Region，並在 health check 觸發時自動切換到 secondary Region。事件也會回聲到 secondary bus，使在那裡進行的 replay 能保持連續性。Global endpoints 是 SAP-C02 情境說「應用程式必須在 Region 中斷期間繼續發布事件，且不需要修改客戶端程式碼」時的標準答案。

AWS Step Functions 事件驅動無伺服器架構深度解析

Step Functions 是事件驅動無伺服器架構中的 orchestrator。在 Pro 深度，SAP-C02 測試 Standard 與 Express 的比較、workflow 模式目錄，以及組合成 circuit breaker 的錯誤處理。

Standard vs Express Workflows

選擇不僅僅是成本問題：

• Standard workflow 支援最長一年的執行時間、exactly-once state transitions、完整執行歷史保留 90 天、僅非同步呼叫、Activity task workers、callback task tokens。價格：每 1000 次 state transitions $0.025（美國東部）。最適合人工審批、長時間執行的 orchestration、需要合規審計的 workflows。
• Express workflow 支援最長五分鐘的執行時間、at-least-once state transitions、無執行歷史（改用 CloudWatch Logs）、同步或非同步呼叫。價格：按執行次數和每 GB-second 持續時間計費（大規模時便宜得多）。最適合高量事件處理、API 請求 orchestration、串流 pipeline。

Workflow 模式：Saga、Callback Task Token、Map、Parallel、Choice

Saga pattern 實現不需要兩階段提交的分散式交易。saga 中的每個步驟都有一個配對的補償步驟。若步驟 N 失敗，Step Functions 沿 catch chain 反向執行，為每個已完成的步驟呼叫補償動作。Saga 是 SAP-C02 對「訂單建立涉及庫存、付款和出貨服務——我們如何回滾部分成功」的答案。用 Task states、Catch 區塊和補償 Task states 實作；若步驟互相獨立，則使用 Parallel 或 Map。

Callback task token（.waitForTaskToken）讓 Task state 暫停，直到外部程序以 token 呼叫 SendTaskSuccess 或 SendTaskFailure。Token 嵌入在傳遞給 Task resource 的輸入中。這能實現：

• 人工審批 workflow（SQS 到電子郵件到網頁表單到 SendTaskSuccess）。
• 帶非同步回應的外部系統整合。
• 長時間執行的外部工作（人工資料審查、有 webhook callback 的第三方 API）。

最長等待時間：Standard 一年，Express 五分鐘。逾時以錯誤形式冒泡到 Catch chains。

Map state 對陣列進行迭代，並為每個項目執行子 workflow。兩種模式：

• Inline Map 將所有迭代保存在父執行歷史中。適合小陣列（最多 40 個並行迭代）。
• Distributed Map 啟動子執行，可處理最多 10000 個並行迭代，從 S3 讀取輸入，並具有每個項目的吞吐量隔離。這是對「並行處理百萬行資料」的 Professional 深度答案。

Parallel state 並行執行一組固定分支，並等待所有分支完成。適用於在設計時已知的獨立子任務（取客戶資料、取庫存、取定價）。

Choice state 根據 JSON 條件進行分支。用於 workflow 內的 content-based routing。

透過 Retry + Catch + DLQ 實現 Circuit Breaker

Step Functions 提供了一個無需專用服務的自然 circuit breaker 模式：

1. 每個 Task state 有一個 Retry 陣列，包含每種錯誤類型的指數退避、最大嘗試次數和 jitter。
2. 重試耗盡後，Catch 轉向到一個命名的錯誤處理 state。
3. 錯誤處理 state 將資料寫入 SQS DLQ 或 EventBridge failure bus，以供離線 replay。
4. ExecutionsFailed 超過閾值的 CloudWatch alarm 觸發一個 circuit-breaker Lambda，該 Lambda 翻轉 Parameter Store 旗標；上游生產者讀取旗標並停止入列。

Step Functions SDK 整合模式

呼叫 AWS SDK 操作的 Task states 有兩種類型：

• Optimized integrations：為熱路徑服務預先建置（Lambda、SQS、SNS、ECS RunTask、DynamoDB PutItem）。價格較低，具有內建功能如 .sync（等待被呼叫的 workflow 或 task）、.waitForTaskToken、.syncExecute（Express 子 sync）。
• Non-optimized SDK integrations：對 200 多個服務的原始 AWS SDK 呼叫。僅按 state transition 計費，無 .sync 變體。

當 Step Functions 應該阻塞直到子程序（ECS task、Glue job、Lambda）完成時，使用 .sync。沒有 .sync，Task 在啟動子程序後立即回傳。

AWS Lambda 大規模部署

Lambda 是事件驅動無伺服器架構中的短暫運算。Pro 深度的 Lambda 涵蓋 concurrency 控制、SnapStart、cold-start 緩解決策樹以及配額策略。

帳號層級與每個函式的配額

SAP-C02 重要的 Lambda 配額：

• 帳號 concurrent executions：每 Region 預設 1000（soft limit，透過 Service Quotas 提升）。
• Burst concurrency：依 Region 而定，每分鐘 500、1000 或 3000 units。burst 後，Lambda 每分鐘擴展 500 直到達到帳號配額。
• Unreserved concurrency 最低值：至少 100 units 必須保持 unreserved，供未提交的函式使用。
• 每 Region 的 Invocations：無硬性上限（受 concurrency 限制）。
• Async event age：在 async queue 中最長 6 小時才會丟棄。
• Async retry attempts：預設 2 次，可設定 0 到 2。
• Event source mapping SQS batch size：Standard 最多 10000，FIFO 最多 10。

Reserved vs Provisioned Concurrency vs SnapStart 組合

三種控制方式各有不同語義：

• Reserved concurrency 同時設定從帳號資源池中劃出的上限和保證下限。不能防止 cold starts。設為 0 可作為緊急 circuit breaker 停用函式。
• Provisioned concurrency 預先初始化 N 個保持暖機的執行環境；最多 N 次呼叫沒有 cold start。按佈建 unit 的每小時計費。可透過 Application Auto Scaling target tracking on ProvisionedConcurrencyUtilization 自動擴展。
• SnapStart 在 init 後為已初始化的執行環境建立快照，並在 cold start 時從快照還原。免費，支援 Java、Python 和 .NET managed runtimes（不支援 container images）。將 cold start 從數秒降到次秒級。

在 Pro 情境中，組合使用很常見。一個 fraud-check Lambda 可能同時有：reserved concurrency 200（限制對下游 RDS 的爆炸半徑）、provisioned concurrency 50（p99 基準線的零 cold start），以及在其 Java runtime 上啟用 SnapStart 作為額外保險。

Cold Start 緩解決策樹

在 SAP-C02 情境中，遇到需要降低 p99 延遲的問題時，使用此決策樹：

1. runtime 是 Java、.NET 或 Python 的 managed runtime 嗎？先啟用 SnapStart（免費）。
2. SnapStart 之後延遲仍超過 SLA，或是 container image runtime？增加 Provisioned Concurrency，大小設為 p95 流量。
3. 流量模式可預測（上班時段尖峰）？對 provisioned concurrency 使用 Application Auto Scaling 加排程動作。
4. 函式是否附加到 VPC？確認 Hyperplane ENI（現代 VPC-Lambda）；舊式 ENI 建立已停用。
5. 部署套件是否很大？將大型相依套件移到 Layer；移除未使用的程式碼。
6. handler 是否進行大量 init？移到 init 階段讓 SnapStart 在暖機時捕獲；對無法快照的項目使用懶惰初始化。
7. 記憶體是否適當調整？更高的記憶體意味著更快的 init（CPU 隨記憶體擴展）。
8. 呼叫者是否為同步且流量爆量？加入 SQS buffer 並轉換為 poll-based；爆量由佇列平滑化。

Event Source Mappings 大規模調整

Lambda event source mappings（ESM）適用於 SQS、Kinesis、DynamoDB Streams、Kafka 和 MQ，這些是 Lambda 管理的 pollers。Pro 深度的調整旋鈕：

• Batch size：每次呼叫的記錄數量。較大的 batch = 較少的呼叫 = 較低的每筆記錄成本，但部分失敗風險較高。
• Batch window（SQS、Kinesis、DDB）：SQS 最多 5 分鐘，streams 最多 5 分鐘。等待累積完整 batch。
• Parallelization factor（Kinesis、DDB Streams）：每個 shard 最多 10 個並行呼叫，在不需要重新分片的情況下倍增有效平行度。
• Filter criteria：伺服器端過濾器在收取 Lambda 費用之前丟棄不符合的事件；每個 ESM 最多 5 個過濾模式。
• Report batch item failures（SQS、Kinesis、DDB）：部分批次回應只回傳失敗的記錄 ID 以重新投遞，避免整個 batch 重新處理。
• Maximum concurrency（僅 SQS）：限制 Lambda pollers 的並行呼叫數，而不需要設定函式的 reserved concurrency——保護下游資源而不阻擋其他呼叫者。

AWS AppSync 在事件驅動無伺服器架構中的即時 GraphQL

AppSync 是 managed GraphQL endpoint，也是事件驅動無伺服器架構中的即時事件驅動前端。SAP-C02 在情境提到「即時」、「行動客戶端」或「GraphQL subscriptions」時會測試 AppSync。

AppSync 功能

• GraphQL API（queries、mutations、subscriptions），採 schema-first 開發。
• 以 JavaScript 或 VTL 撰寫的 resolvers，映射到資料來源：DynamoDB（直接）、透過 Data API 的 Aurora Serverless、Lambda、HTTP endpoints、OpenSearch、EventBridge。
• 透過 MQTT-over-WebSocket transport 的 Real-time subscriptions；客戶端依參數過濾訂閱 mutation 結果。
• 事件驅動 mutations：mutation 觸發 subscription fan-out 並同時寫入資料來源。
• resolver 或 query 層級的快取。
• 授權模式：API key、IAM、Cognito User Pools、OIDC、Lambda authorizer——可依類型組合。
• Merged APIs 將多個來源 GraphQL API 組合成一個 endpoint。

AppSync 適用於事件驅動無伺服器架構的場景

在以下情況使用 AppSync 而非 API Gateway 加 Lambda：

• 客戶端需要即時更新而不需輪詢（聊天、協作工具、儀表板）。
• 行動客戶端偏好單次請求組合而非多次 REST 呼叫。
• 需要 schema 驅動的合約，且團隊使用 GraphQL 工具。
• EventBridge 事件應透過 subscription 推送到連線的行動客戶端。

AppSync 與 EventBridge 整合，使到達 bus 的任何事件都能觸發 AppSync mutation，進而將 subscription 通知串聯到每個連線的客戶端。這是對「將即時 IoT 遙測推送到行動儀表板」的 Pro 深度答案。

AWS IoT Core 作為事件驅動無伺服器架構的事件源

IoT Core 是裝置群的 MQTT broker、裝置登錄與 rules engine。IoT Core 在事件驅動無伺服器架構中很重要，因為在許多企業架構中，裝置遙測是非同步事件的最大單一來源。

IoT Core 建構元件

• Device Gateway：使用互相 TLS 認證的 MQTT、MQTT over WebSocket 或 HTTPS 擷取。
• Registry：things、thing types、thing groups 的詮釋資料。
• Device Shadow：每個裝置耐久的 JSON 狀態（desired vs reported vs delta）。
• Rules engine：針對 MQTT topic streams 的 SQL 式陳述式，路由到 AWS 服務。
• IoT Core message broker 支援數百萬個並行裝置連線。

Rules Engine 作為 Event Router

Rules engine SQL 依 topic 和 payload 內容過濾 MQTT 訊息，然後路由到以下任何服務：Lambda、SQS、SNS、Kinesis Data Streams、Kinesis Firehose、DynamoDB、S3、Timestream、CloudWatch、Step Functions、EventBridge bus、重新發布到另一個 MQTT topic。多個 rules 可以對同一個 topic 觸發以實現 fan-out。

在 Pro 深度的事件驅動無伺服器架構中，當事件需要饋入更廣泛的企業 bus 時，將 IoT rules 路由到 EventBridge；當下游需要有序的每裝置分析時路由到 Kinesis Data Streams；當事件是時間序列遙測時路由到 Timestream。

驅動設計的 IoT Core 配額

• 每帳號每秒訊息數：預設 20000；透過配額增加可達每 Region 100000 到 1M。
• 每帳號裝置連線數：預設 500000；透過配額增加可達數千萬。
• 每個 rule 的 rules engine actions：最多 10 個。
• 訊息 payload：最大 128 KB。

對於每秒 5000 個事件的百萬裝置群（我們稍後建構的情境），預設配額無需增加即已足夠，但佈局（Region 選擇、跨 bus 分片）仍然關係到爆炸半徑。

事件驅動無伺服器架構中的 Choreography vs Orchestration

這個取捨在幾乎每道 SAP-C02 事件驅動無伺服器架構問題中都會被測試。

Choreography

服務將事件發布到 EventBridge，並獨立訂閱他們關心的事件。沒有中央協調者。OrderService 發布 OrderPlaced；PaymentService 訂閱並發布 PaymentCompleted 或 PaymentFailed；InventoryService 訂閱 PaymentCompleted 並保留庫存。

優點：

• 線性擴展；無單一 orchestrator 瓶頸。
• 無需修改生產者即可新增消費者。
• 天然的鬆耦合。

缺點：

• 沒有流程狀態的全域視圖；偵錯分散式失敗很困難。
• 回滾（saga）邏輯分散在各服務中。
• 湧現行為：新增訂閱者可能意外造成事件風暴。

Orchestration

Step Functions 持有流程。State machine 呼叫 OrderService、然後 PaymentService、然後 InventoryService，帶有明確的 retry 和 catch。Saga 補償集中在一處。

優點：

• 流程的全域視圖在 Step Functions 執行歷史中。
• 集中的錯誤處理和補償。
• 對新工程師更容易上手。

缺點：

• 在不當設計下，Orchestrator 可能成為規模或可靠性瓶頸（高量使用 Express，大 fan-out 使用 Distributed Map）。
• Orchestrator 與步驟實作之間的緊耦合。

如何選擇

在 SAP-C02 中，套用這些測試：

• 業務是否需要每次多步驟執行的稽核軌跡？使用 Orchestration。
• 流程是否需要長時間執行且有人工審批？使用 Orchestration（Standard）加 callback task tokens。
• 流程是否短暫、高量，且每個服務已擁有其邏輯？使用 EventBridge 上的 Choreography。
• 跨服務失敗是否需要補償動作？使用有 Saga state machine 的 Orchestration，或使用有專屬補償協調器服務的 Choreography（罕見）。

混合設計很常見：頂層用 choreography（OrderPlaced fan-out 到四個服務），每個服務內部用 orchestration（PaymentService 執行 Step Functions saga 處理扣款、回滾、退款）。

使用 DynamoDB Streams 的 Outbox Pattern

Dual-write 問題：服務必須原子性地更新其資料庫並發布事件。若資料庫寫入成功但事件發布失敗（或反之），狀態就會分歧。Outbox pattern 透過在同一個交易中將事件寫入資料庫本地的 outbox table 來修復此問題，並由獨立程序將 outbox 行轉發到 broker。

DynamoDB Streams 實作

在 AWS 上，事件驅動無伺服器架構的標準 outbox 使用 DynamoDB：

1. 應用程式在單一 DynamoDB transaction（TransactWriteItems）中同時寫入 aggregate item 和 outbox-row item。
2. DynamoDB Streams 將兩個 inserts 捕獲為 stream records。
3. 過濾器（EventBridge Pipe filter 或 Lambda ESM filter）只選取 outbox-row records。
4. EventBridge Pipe 轉發到 target bus 或直接到 EventBridge。
5. Outbox row 可選擇性地有一個 TTL 屬性，讓 DynamoDB 在消費後自動過期；或在確認投遞後由 cleanup Lambda 刪除。

為什麼這樣有效：DynamoDB Streams 在每個 partition key 上是有序的且 at-least-once，因此每個 outbox row 都能被投遞。單一交易寫入意味著 outbox row 存在當且僅當 aggregate 寫入已提交。消費者端的 idempotency（使用帶 conditional writes 的 DynamoDB idempotency table 儲存 event ID）處理重複投遞。

Dead-Letter Queues、Redrive 與 Observability

Dead-letter queues（DLQs）捕獲重試後仍處理失敗的訊息。在事件驅動無伺服器架構中，DLQs 出現在多個層：SQS 每個佇列、SNS 每個訂閱、Lambda 每個函式（舊版）、EventBridge 每個 rule、Step Functions 透過 Catch 到 SQS。

DLQ 設定層

• SQS redrive policy：在來源佇列上設定 maxReceiveCount；N 次接收未刪除後，SQS 將訊息移到 DLQ 佇列。
• SNS redrive policy：每個訂閱的 DLQ 捕獲重試後仍失敗的投遞（通常是到 HTTP endpoints 或跨帳號 targets）。
• Lambda destinations（on-failure）：以包含更豐富上下文 payload 的方式取代舊版 Lambda DLQ，路由到 SQS、SNS、EventBridge 或另一個 Lambda。
• EventBridge rule DLQ：rule 層級的 SQS DLQ 捕獲無法投遞到 target 的事件（target throttling、無效 payload、缺少權限）。
• Step Functions Catch 到 SQS：Catch 所有錯誤類型到一個將失敗執行輸入發布到 SQS DLQ 的 state，以供離線分類處理。

SQS Redrive 回來源

從 DLQ 回到來源佇列的 redrive 是 2022 年的功能，消除了對自訂腳本的需求。從 console 或 API，你可以在修復消費者 bug 後將訊息從 DLQ 移回原始佇列重新處理。Pro 深度的事件驅動無伺服器架構依賴此功能進行部署 bug 事件後的安全恢復。

事件驅動無伺服器架構的 Observability 技術堆疊

Pro 深度的事件驅動無伺服器架構需要：

• AWS X-Ray active tracing：在 Lambda、API Gateway、Step Functions、SNS 和 SQS 上進行端對端追蹤圖。X-Ray 透過非同步邊界（當來源服務啟用 active tracing 時）透過 trace headers 傳播。
• CloudWatch Embedded Metrics Format：高基數指標（每客戶、每裝置），無需 CloudWatch 自訂指標 API 呼叫成本。
• CloudWatch Logs Insights：跨多個 log groups 查詢。
• EventBridge Archive 兼作事件稽核記錄（加上 Firehose 到 S3 加 Athena 進行臨時查詢）。
• Step Functions execution history：workflow 層級稽核。
• AWS Lambda Powertools（Python、Java、TypeScript、.NET）：跨函式一致實作結構化日誌、追蹤和 idempotency 模式的函式庫。

情境：百萬裝置 IoT 群每秒 5000 個事件且有 Region 合規要求

這是標準的 SAP-C02 事件驅動無伺服器架構情境。需求：

• 裝置群：全球 100 萬台 IoT 裝置。
• 擷取：持續每秒 5000 個事件，韌體推出期間尖峰每秒 20000 個事件。
• 合規：EU 來源的裝置資料不得離開 eu-west-1；美國資料不得離開 us-east-1。
• 可靠性：目標 99.95% 擷取可用性；Region 控制平面受損時不得有資料遺失。
• 即時儀表板：裝置群操作員需要次秒級的裝置狀態變更更新。
• 批次分析：所有 Region 的每月匯總。
• 維運：小型團隊，偏好全受管服務。

架構演練

1. 裝置佈建：裝置依 Region 在 IoT Core 中登錄（eu-west-1 和 us-east-1）。基於憑證的 mTLS 認證。Device groups 按租戶和合規區域標記裝置。
2. 擷取：裝置將 MQTT 發布到其所在 Region 的 IoT Core endpoint。IoT rules engine 過濾並路由：
   • Telemetry rule：發布到同一 Region 的 Kinesis Data Streams，用於有序的每裝置分析。
   • State-change rule：發布到同一 Region 的 EventBridge custom bus device-events。
   • Alarm rule：直接發布到 SNS topic，有 SMS 和 Lambda 訂閱者用於值班升級。
3. 每 Region EventBridge bus：device-events bus 接收狀態變更。Rules 路由到：
   • Lambda handlers（device-state-update）以 UPSERT 方式更新啟用 DynamoDB Streams 的 DynamoDB device-state table。
   • 透過 EventBridge target 的 AppSync mutation，將 subscription 更新推送到行動和網頁儀表板。
   • Archive 保留 30 天，以便在下游 bug 時 replay。
4. 企業事件的 Outbox：device-state-update Lambda 在 DynamoDB transaction 中同時寫入 aggregate 和 outbox row。來自 DynamoDB Streams 的 EventBridge Pipe 過濾 type == outbox 並轉發到 device-events bus，確保耐久發布。
5. 韌體推出的 Orchestration：操作員觸發一個 Step Functions Standard workflow，對 100 萬台裝置進行 Distributed-Map，從 S3 讀取裝置列表，為每台裝置呼叫一個 Lambda 透過 IoT Jobs 發送韌體更新命令，以 callback task token 等待裝置的回報更新狀態。暫時性失敗時重試；每台裝置的 Catch 到 SQS DLQ 供後續分類處理。
6. 即時儀表板：AppSync subscriptions 透過 WebSocket 向連線的客戶端投遞裝置狀態變更。按租戶 ID 過濾 subscription。
7. 批次分析：各 Region 的 Kinesis Data Streams 饋入 Firehose 到同一 Region 的 S3。AWS Glue crawler 為分割區建立目錄；Athena 聯邦查詢透過 Lake Formation 跨帳號分享，在中央開發/分析帳號跨 Region 匯總。合規性得以保留，因為原始的每裝置資料留在 Region——只有匯總資料才會跨越。
8. 跨 Region 韌性：EventBridge global endpoint 設在兩個 Region 的 device-events bus 前，並在 primary bus 的 put-events health 上設定 Route 53 health check。若 eu-west-1 失敗，eu-west-3 接管成為 EU 流量的 secondary。IoT Core 本身需要每 Region 的客戶端設定，因此次要 IoT Core endpoint 和裝置端備援邏輯超出 AWS 單獨解決的範疇。
9. Observability：所有 Lambdas 使用 Powertools 進行結構化日誌和 X-Ray 追蹤；Step Functions execution history 保留 90 天；CloudWatch Synthetics 每分鐘探測 IoT endpoints；Security Hub 將 GuardDuty 和 Config 發現匯總到中央安全帳號；兩個 Region bus 上的 EventBridge Archive 保留 30 天，支援事件 replay。

使這個答案達到 Pro 層級的設計決策

• 每 Region 一個 custom bus，不共用全域：保留資料居住地並隔離爆炸半徑。全域 bus 會違反合規。
• EventBridge Pipes 優於 Lambda forwarder：對 DynamoDB Streams 到 device-events，Pipes 更便宜且從關鍵路徑中移除了一個 Lambda。
• Distributed Map 優於 inline Map：100 萬台裝置超過 inline Map 40 個並行迭代上限達四個數量級。
• 韌體更新上的 Callback task token：裝置更新是非同步的，可能需要幾分鐘；輪詢 DynamoDB 狀態會很浪費。Task token 讓 Step Function 暫停直到 IoT rules engine 呼叫 SendTaskSuccess。
• 由 EventBridge rule 觸發的 AppSync mutation：以 push 取代輪詢儀表板；從裝置事件到儀表板的延遲達到次秒級。
• Outbox pattern：消除必須可靠產生企業事件的裝置狀態更新上的 dual-write 風險。
• Global endpoint 只用於 bus，不用於 IoT Core：IoT Core endpoints 是每 Region 的；裝置韌體必須在傳輸層處理備援。

SAP-C02 事件驅動無伺服器架構的常見陷阱

陷阱模式在每次 SAP-C02 考試中反覆出現。熟記這些。

陷阱 1：在 Default Bus 上使用應用程式事件

Default bus 是給 AWS 服務事件用的。應用程式事件屬於 custom bus。暗示 DDD、microservices 或跨團隊所有權但將事件放在 default bus 上的情境是錯誤的。

陷阱 2：對高量事件使用 Standard Workflow

Standard 每秒 2000 次 StartExecution 且按 state transition 計費。每月執行 5000 萬次且在五分鐘內完成的 workflow 屬於 Express 的領域。不要因為可靠性原因而預設使用 Standard。

陷阱 3：將 Reserved Concurrency 作為 Cold-Start 修復方案

Reserved 是上限，不是暖機資源池。對於 cold starts，Provisioned Concurrency 或 SnapStart 才是正確答案。

陷阱 4：將 EventBridge 跨 Region 視為免費

跨 Region PutEvents 在目的地 Region 收費且增加延遲。在成本敏感的情境中不要輕率提議使用。

陷阱 5：SNS FIFO 與 SQS Standard 訂閱者配合

SNS FIFO 只能發布到 SQS FIFO 佇列。要求有 Standard SQS 訂閱者的有序情境是不匹配的。

陷阱 6：Lambda DLQ 與 Destinations 混淆

Lambda DLQ 是舊版且僅限非同步。Lambda Destinations 涵蓋成功和失敗，並支援更豐富的 targets。對於新的事件驅動無伺服器架構設計，Destinations 是首選。

陷阱 7：Inline Map 用於大 Fan-Out

Inline Map 上限為 40 個並行，並將歷史保存在父執行中。對超過 40 個並行或大於 S3 頁面的輸入，使用 Distributed Map。

陷阱 8：在需要補償的地方提議 Choreography

若情境需要跨多個服務在部分失敗時回滾，通常帶有 Saga state machine 的 orchestration 是正確的。純 choreography 使補償在規模化時難以偵錯。

陷阱 9：輪詢式儀表板取代 AppSync Subscriptions

提到數萬客戶端即時儀表板的 SAP-C02 情境應使用 AppSync subscriptions。在規模化時輪詢 API Gateway 加 Lambda 成本效率低落，且無法滿足即時需求。

陷阱 10：忽略 Archive and Replay 用於 Replay 需求

「重播過去 24 小時的事件」指向 EventBridge Archive and Replay。當來源是 EventBridge 時，自製的 Firehose 到 S3 加 Lambda replay 是反模式。

事件驅動無伺服器架構與相鄰 SAP-C02 主題的邊界

SAP-C02 將事件驅動無伺服器架構與相鄰主題分開。了解邊界。

• event-driven-serverless-architecture vs new-solutions-reliability：本主題擁有事件層和無伺服器運算；reliability 主題擁有多 AZ、多 Region、circuit breakers 以及跨所有運算的配額規劃。Lambda concurrency 細節兩者都有，但事件流設計在這裡。
• event-driven-serverless-architecture vs containerization-ecs-eks：container 主題擁有消費事件的長時間執行 worker pools。當 Fargate worker 從 Lambda 無法處理的 SQS 讀取（超過 15 分鐘），SQS 設計和事件路徑在這裡；ECS service 細節在容器主題中。
• event-driven-serverless-architecture vs data-analytics-at-scale：Kinesis Data Streams 是共用的。對於饋入 Glue 和 Athena 的有序遙測，analytics 主題擁有批次路徑；事件 broker 設計在這裡。
• event-driven-serverless-architecture vs new-solutions-performance：AppSync 即時 GraphQL 在這裡，因為其事件驅動的 mutation 模型；快取、DynamoDB DAX 和 CloudFront 在 performance 主題中。
• event-driven-serverless-architecture vs cicd-iac-deployment-strategy：Lambda alias 流量切換和 serverless 部署的 blue/green 屬於 CI/CD；workflow 和事件設計屬於這裡。

事件驅動無伺服器架構必記數字

• EventBridge PutEvents：每 Region 預設每秒 10000 次（soft limit）；事件大小最大 256 KB。
• EventBridge rule targets：每個 rule 最多 5 個。
• EventBridge Archive 保留期：1 天到無限期。
• EventBridge global endpoints：兩個 Region active-passive，附 Route 53 health check。
• Step Functions Standard：最長執行 1 年、每秒 2000 次 StartExecution、預設 25000 個開啟執行、90 天歷史保留。
• Step Functions Express：最長執行 5 分鐘、預設每秒 100000 次 state transitions。
• Step Functions Distributed Map：最多 10000 個並行子執行，從 S3 讀取輸入。
• Step Functions callback task token：Standard 最長等待 1 年，Express 5 分鐘。
• Lambda：最長逾時 15 分鐘、10 GB 記憶體、10 GB /tmp、每 Region 預設 1000 concurrent。
• Lambda Provisioned Concurrency：佈建期間按每 GB-second 計費，加上每次呼叫折扣。
• Lambda SnapStart：Java、Python、.NET managed runtimes（不支援 container images），免費。
• Lambda async：佇列中最長 6 小時，最多 2 次重試。
• SQS Standard：無限吞吐量，at-least-once；FIFO 300 TPS 或批次 3000 TPS。
• AppSync subscriptions：WebSocket 連線，次秒級推送。
• IoT Core：每帳號預設每秒 20000 訊息，可提升至 1M；預設 500000 裝置連線。
• DynamoDB Streams：24 小時保留，shard 層級有序，at-least-once。

FAQ — 事件驅動無伺服器架構常見問題

Q1. 在事件驅動無伺服器架構中，何時應該使用 EventBridge 而非 SNS 進行 fan-out？

當你需要 content-based routing、schema registry、archive and replay、跨帳號或跨 Region 路由、partner 事件源，或超過 SNS 每個 topic 允許的 1250 萬個訂閱的大型 fan-out 時，使用 EventBridge。當你需要對少量固定訂閱者的超低延遲 fan-out、SMS 或電子郵件投遞，或行動推送時，使用 SNS。EventBridge 按擷取的事件計費；SNS 按發布次數加每次投遞計費。對於五個以上具有不同過濾邏輯的 targets，EventBridge rules 比多個 SNS filter policies 更清晰。對於帶有 SQS FIFO 訂閱者的嚴格 FIFO，SNS FIFO 是唯一答案（EventBridge 不保證順序）。在 SAP-C02 的事件驅動無伺服器架構中，EventBridge 是預設 broker，SNS 是需要其特有功能時的專用 fan-out。

Q2. 在事件驅動無伺服器架構中，如何在 Step Functions Standard 和 Express 之間選擇？

Standard workflow 支援最長一年執行、exactly-once state transitions、90 天執行歷史保留、僅非同步呼叫、activity task workers，以及最長一年的 callback task tokens。Express workflow 支援最長五分鐘執行、at-least-once state transitions、無內建執行歷史（僅 CloudWatch Logs）、同步或非同步呼叫，以及每秒最多 100000 次 state transitions。選擇 Standard 用於長時間執行的 orchestration、超過五分鐘且有 callback task tokens 的人工審批 workflows、需要稽核補償的 saga patterns，以及任何需要執行歷史稽核的流程。選擇 Express 用於高量事件處理 workflows、API 請求 orchestration、串流 pipeline，以及任何在五分鐘內完成且需要較低每次執行成本的流程。你也可以使用 StepFunctions:StartExecution.sync 在 Standard workflows 中巢套 Express workflows，兼得兩者優點——帶有稽核的父執行與快速的子執行。

Q3. 什麼是 outbox pattern，以及如何在 AWS 的事件驅動無伺服器架構中實作？

Outbox pattern 消除 dual-write 問題，該問題是服務必須原子性地更新其資料庫並向 broker 發布事件。沒有 outbox，資料庫寫入可能成功而事件發布失敗（或反之），導致狀態分歧。在 AWS 上，標準實作是：在單一 DynamoDB TransactWriteItems 中，同時寫入 aggregate item 和代表事件的 outbox-row item。DynamoDB Streams 以每個 partition key 有序且 at-least-once 的方式捕獲兩個寫入。帶有過濾器只選取 outbox rows 的 EventBridge Pipe，以內建的 retries 和 DLQ 將它們轉發到 target EventBridge bus。Outbox row 可以有 TTL 供自動清理，或在確認投遞後明確刪除。消費者 idempotency（使用帶 conditional writes 的 DynamoDB idempotency table 儲存事件 ID）處理 at-least-once 的重複。此模式是 SAP-C02 對任何需要為每次狀態變更保證事件發布的情境的標準答案。

Q4. EventBridge Pipes 與 Lambda 膠水函式有何不同，在事件驅動無伺服器架構中應如何選擇？

EventBridge Pipes 是一種受管的點對點整合，有四個階段：source、filter、選用的 enrichment，以及 target。Pipes 支援 SQS、Kinesis、DynamoDB Streams、Kafka、MQ 作為 sources，以及任何 EventBridge target 作為目的地。當整合是直接轉發或簡單的過濾和重塑時選擇 Pipes，當你想取代樣板 Lambda 程式碼時，當每個事件的成本敏感時（Pipes 按事件計費而非按 Lambda 毫秒計費），以及當串流 sources 的順序必須保留時。當轉換複雜時選擇 Lambda 膠水函式，當 enrichment 需要帶有自訂邏輯的多個下游呼叫時，當你需要 SDK 層級控制時，或當現有架構有深度的 Lambda observability 儀器時。混合模式使用帶有 enrichment Lambda 的 Pipes：Pipes 處理 source polling、過濾、retries 和 DLQ，而小型 enrichment Lambda 只進行業務轉換，使 Lambda 比完整的膠水函式更簡單。

Q5. 在事件驅動無伺服器架構中，如何防止 Lambda 壓垮下游關聯式資料庫？

多種控制方式組合以保護下游 RDS 或 Aurora 資料庫免受 Lambda concurrency 尖峰衝擊。首先，在 Lambda 前使用 SQS 作為緩衝，配合 event source mapping，使 Lambda poll rate 由佇列塑型，而非直接同步壓力。其次，設定 SQS event source mapping 的 MaximumConcurrency 參數，限制來自特定佇列的並行 Lambda 呼叫數，讓 unreserved concurrency 可用於其他函式。第三，在 Lambda 函式本身使用 reserved concurrency 作為所有呼叫者的上限。第四，在資料庫前使用 Amazon RDS Proxy 來池化連線並承受 Lambda 的連線波動；RDS Proxy 在呼叫之間重用連線並透明地處理 failover。第五，設計 idempotency 使 RDS 暫時性失敗的重試不會破壞狀態。第六，若 Lambda 由 state machine 呼叫，實作 Step Functions retry 帶有指數退避和 jitter，範圍限定在特定錯誤類型（throttling、暫時性連線失敗）。這些控制方式共同將 Lambda 從資料庫的雷霆牛群變成行為良好的消費者。

Q6. Step Functions 中的 callback task token 模式是什麼，何時應在事件驅動無伺服器架構中使用？

Callback task token（.waitForTaskToken）是一種 Step Functions Task state 整合模式，state 無限期暫停（Standard 最長一年，Express 五分鐘），直到外部程序以 token 呼叫 SendTaskSuccess 或 SendTaskFailure API。當 Step Functions 以 .waitForTaskToken 啟動 Task 時，它產生一個唯一 token 並將其作為 payload 的一部分傳遞給 Task 的 resource（Lambda、SQS、SNS 等）。外部程序——點擊電子郵件連結的人工審批者、回報韌體更新完成的 IoT 裝置、有 webhook callback 的第三方 API——捕獲 token 並隨後以結果呼叫 SendTaskSuccess 或以錯誤呼叫 SendTaskFailure。當下一步依賴 workflow 外部的非同步事件時、當輪詢會很浪費時，或當等待時間不可忽視（分鐘到天）時，使用 callback task token。常見模式包括透過 SQS-電子郵件-網頁的人工審批 workflow、IoT 裝置命令確認、外部批次工作完成，以及帶有 webhook 回應的第三方 API 整合。沒有 task tokens，架構師只能求助於昂貴且脆弱的輪詢循環；task tokens 使等待明確且由 state machine 管理。

Q7. 如何設計符合資料居住要求的多 Region 事件驅動無伺服器架構？

資料居住要求事件中包含 Region 資料的必須留在該 Region。此架構使用每 Region 的 custom EventBridge buses、每 Region 的 Lambda consumers，以及每 Region 的 DynamoDB tables（若居住要求禁止複製則不使用 Global Tables）。裝置或使用者只向其所在 Region endpoint 發布；對原始資料不進行跨 Region PutEvents。允許跨越的匯總或匿名化事件可透過跨 Region EventBridge target 轉發到中央分析 Region。對於擷取路徑本身的多 Region 韌性，在 active-passive 模式下使用 EventBridge global endpoints，帶有 Route 53 health check；secondary Region 必須在同一個居住區域內（例如，EU 資料以 eu-west-1 為 primary，eu-west-3 為 secondary）。DR 測試必須包括從 archive replay、failover 演練，以及 IoT 或客戶端 SDK 對 secondary endpoint 的備援。合規工件包括 AWS Config rules 斷言受管理 table 上的跨 Region 複製已停用、SCP 拒絕來自工作負載帳號到非居住 Region 的 PutEvents，以及 AWS Audit Manager 證據收集。在 SAP-C02 的事件驅動無伺服器架構中，提到 GDPR、有 Region 限制的 HIPAA，或特定國家資料法律的情境，總是對應到此每 Region bus 模式。

總結 — 事件驅動無伺服器架構一覽

• SAP-C02 的事件驅動無伺服器架構是一項設計學科，組合 Amazon EventBridge、AWS Step Functions、AWS Lambda、AWS AppSync、AWS IoT Core、Amazon SQS 與 Amazon SNS。
• EventBridge bus 設計：default 用於 AWS 服務事件，custom 用於每個 bounded context，partner 用於每個 SaaS 來源，global endpoints 用於 active-passive DR。在 Pro 深度使用 schema registry、archive 和 replay；對 source-filter-enrich-target 整合優先選擇 Pipes 而非 Lambda 膠水。
• Step Functions Standard 用於帶有最長一年 callback task tokens 的長時間執行稽核 workflows；Express 用於高量五分鐘以內處理；Distributed Map 用於百萬規模 fan-out；Saga pattern 配合 Retry 加 Catch 加補償 states 用於分散式交易。
• Lambda concurrency 組合三種控制：reserved（上限和下限）、provisioned（帶每小時成本的暖機資源池）、SnapStart（Java、Python、.NET managed runtimes 的免費快照）。Cold-start 緩解從 SnapStart 開始的決策樹。
• AppSync 投遞即時 GraphQL subscriptions；與 EventBridge rules 配對，將事件驅動的推送到行動和網頁客戶端。
• IoT Core rules engine 將 MQTT 路由到 EventBridge、Kinesis、Step Functions 等；裝置群的第一等事件源。
• Choreography 以鬆耦合擴展；orchestration 集中補償和稽核。混合設計在不同層都使用兩者。
• 使用 DynamoDB Streams 加 EventBridge Pipes 的 Outbox pattern 消除 dual-write 問題。
• DLQ 加 redrive 加 X-Ray tracing 加 CloudWatch EMF 加 archive 是 observability 技術堆疊。
• 百萬裝置每秒 5000 個事件情境組合了每 Region buses、Distributed Map 韌體推出、裝置確認上的 callback task tokens、儀表板的 AppSync subscriptions，以及擷取韌性的 EventBridge global endpoints。
• SAP-C02 獎勵多重約束推理：同時考慮持續時間、居住地、順序、成本、observability。將事件驅動無伺服器架構作為組合遊戲而非服務目錄來掌握。

這個深度的事件驅動無伺服器架構，正是區分猜測服務的 SAP-C02 考生與在約束下為設計提出理由的架構師之間的差異。當你能解釋為什麼這個情境使用 EventBridge Pipes 而非 Lambda 膠水、Express 而非 Standard、Distributed Map 而非 inline Map，以及 AppSync 而非輪詢，事件驅動無伺服器架構就不再是考試主題，而成為生產直覺。