事件驅動攝取 — Lambda 與 EventBridge

事件驅動擷取 (Event-driven ingestion) 是一種資料流因應事件而觸發的架構風格 — 檔案落入 S3、資料列寫入 DynamoDB、記錄附加到 Kinesis 串流 — 下游流水線隨即自動做出反應。AWS Lambda 與 Amazon EventBridge 是 AWS 上支撐此類風格的兩大核心服務，它們正好對應 DEA-C01 領域 1 的任務 1.1（執行資料擷取）、1.3（編排資料流水線）以及 1.4（應用編程概念）。來自 Tutorials Dojo、Digital Cloud Training 和 ExamCert.App 的社群學習指南都指出了相同的痛點 — 考生容易為長時間運行的批次 ETL 選擇 Lambda（這是不行的）、混淆 EventBridge 規則 (Rules) 與 EventBridge 管道 (Pipes)、錯誤配置 Kinesis 觸發器的批次大小，以及忽略了 EventBridge 排程器 (Scheduler) 作為 CloudWatch Events 排程規則繼承者的地位。

本指南從資料工程師的角度出發，涵蓋了事件驅動擷取架構的樣貌、Lambda 執行模型及其硬性限制、與資料工程相關的每個 Lambda 事件來源、EventBridge 規則 vs 管道 vs 排程器、S3 事件通知、作為 CDC 來源的 DynamoDB Streams、包含批次大小和平行處理因素在內的 Lambda Kinesis 觸發器配置、Lambda vs Glue vs Step Functions 的決策矩陣，以及最常讓資料工程師失分的典型考試陷阱。讀完本指南後，配置事件驅動擷取應該會像為智慧家庭接線一樣自然，每個感測器都能準確觸發對應的家電。

什麼是事件驅動擷取？

事件驅動擷取是一種架構模式，其中生產者在事件發生時發送事件，事件匯流排或串流將這些事件路由給取用者，而取用者異步處理事件，無需與生產者進行協調。DEA-C01 考試會將其與排程批次擷取（例如午夜運行的 Glue 工作，抓取昨天的資料）以及請求-回應擷取（例如用戶端調用 API 並等待結果）進行對比。事件驅動擷取是 AWS 上近乎即時 (near-real-time) 資料流水線的動力來源 — 檔案落入 S3，事件觸發 Lambda 進行編目與路由；Kinesis 記錄到達，Lambda 取用者進行彙總並寫入 DynamoDB；資料庫行發生變化，DynamoDB Streams 觸發 Lambda 將變更傳播至資料湖。

核心構建區塊

事件驅動擷取流水線包含五個典型組成部分：生產者發送事件（S3、DynamoDB、應用程式程式碼、合作夥伴 SaaS）、事件代理程式路由或緩衝事件（EventBridge、Kinesis、MSK、SNS、SQS）、篩選器及早捨棄不相關的事件、取用者處理事件（Lambda、Glue、Step Functions、下游服務），以及目的地擷取結果或失敗（S3、Glue 目錄、DynamoDB、無寄件備份佇列）。DEA-C01 考試會根據容量、延遲、排序、持久性和成本要求，測試在每個層級選擇正確服務的能力。

推播 (Push) vs 提取 (Pull) 模型

推播模型擷取是在事件到達時由代理程式將事件推送到取用者 — 例如 S3 事件觸發 Lambda 調用、EventBridge 目標調用、SNS 到 Lambda。提取模型擷取則是由取用者從代理程式抓取事件 — 例如 Kinesis Data Streams 取用者輪詢分片、MSK 取用者輪詢 Kafka 主題。Lambda 事件來源映射 (event source mapping) 通過託管抽象隱藏了輪詢細節，使得資料工程師只需編寫取用邏輯。考試中常出現「Lambda 僅支持推播」的錯誤說法；實際上，對於串流來源，Lambda 在事件來源映射背後運行著一個託管輪詢器。

白話文解釋事件驅動擷取

事件驅動架構屬於那種光看名稱無法傳達其權衡取捨的系統。以下三個具體的類比可以幫助您牢記其結構。

類比 1 — 具有感測器與家電的智慧家庭

想像一個智慧家庭。門鈴感測器偵測到訪客並發送一個事件。智慧中控路由該事件 — 打開門廊燈、發送手機通知、開始錄影。每個家電都獨立做出反應，而門鈴並不需要知道下游發生了什麼。門鈴是事件生產者（如 S3 或 DynamoDB Streams）。智慧中控是事件代理程式（如 EventBridge）。中控中的規則（例如「如果門鈴在晚上 11 點到凌晨 6 點之間響起，同時喚醒安保系統」）就是具有模式匹配和目標路由功能的 EventBridge 規則。按需錄影的攝影機是 Lambda — 它僅在被調用時喚醒，運行幾秒鐘，然後恢復安靜。每個工作日早上 7 點煮咖啡的定時器是 EventBridge 排程器 — 一個與感測器事件解耦的循環排程。

當您裝修並添加安保攝影機時，門鈴不需要重新配置 — 您只需在中控中添加一條新規則，將門鈴事件路由到新攝影機即可。這種解耦正是事件驅動擷取的價值所在：生產者和取用者可以獨立演進。無寄件備份佇列 (DLQ) 是當中控發現家電離線時保留的錯誤日誌 — 您可以稍後重新播放事件。Lambda 的 15 分鐘逾時限制就像攝影機的電池壽命 — 它可以可靠地錄製短片，但您不能用它來進行長達兩小時的安保監視。

類比 2 — 具有記者、編輯與電訊稿的新聞室

想像一個新聞室。現場記者在事件發生時（重大新聞、體育比分、天氣警報）提交報導 — 他們是事件生產者。電訊服務根據主題和地區將提交的報導路由給感興趣的編輯 — 這就是具備模式匹配功能的 EventBridge 規則。編輯台接收電訊報導、進行編輯並發布 — 那位編輯就是 Lambda，針對每篇報導短暫活躍，然後進入閒置。重複檢查器將新報導與近期報導進行比較並捨棄重複內容，這就是 EventBridge 管道篩選 (filtering)。每天早上 6 點排定的晨間簡報是 EventBridge 排程器 — 它根據時鐘運行，獨立於突發新聞。

新聞室有其規則：編輯最多只能在單篇報導上花費 15 分鐘，否則編輯台會重新分配任務（Lambda 15 分鐘逾時）；編輯的草稿不能超過 6 MB（Lambda 有效載荷限制）；且同時工作的編輯人數不能超過十位（並行限制）。編輯無法及時完成的報導會進入重寫隊列（無寄件備份佇列）以便後續跟進。當發生大規模新聞（某個電訊源突然湧入大量事件）時，新聞室可以預留專門的編輯，永遠不會被轉派其他任務（預留並行），或者讓預熱的編輯始終處於待命狀態（佈建並行）。

類比 3 — 具有傳送帶的郵政分揀中心

想像一個郵政分揀中心。郵袋從各區域辦事處到達（來自 S3 或 DynamoDB 的事件）。中央傳送帶按目的地區域路由每個包裹（EventBridge 匯流排）。各分支機構的分揀機（Lambda 函數、Glue 工作、Step Functions）拾取包裹，執行任務並向下游傳遞。傳送帶速度限制器是批次大小 (batch size) — 分揀機每個週期最多處理 100 個包裹。每個分支機構的平行分揀員是 Lambda Kinesis 觸發器中的平行處理因素 (parallelization factor) — 對於單個分片，最多運行 10 個平行分揀機按順序處理具有相同分割區索引鍵的包裹。

分揀中心到處都有緩衝。Kinesis Data Streams 是緩衝傳送帶，可保留 1-365 天的包裹。SQS 是暫存箱，當分揀機忙碌時在此排隊。DynamoDB Streams 是分揀中心地址簿的變更日誌 — 每次更改都會發送一個事件。S3 事件通知是裝貨碼頭上的包裹到達公告。無寄件備份佇列是機器無法分揀包裹的失物招領處。如果批次大小配置錯誤，機器要麼會因每個週期包裹過多而崩潰，要麼會因等待下一個批次而閒置 — 這正是典型的 Lambda Kinesis 觸發器調優練習。

AWS Lambda — 事件處理器

Lambda 是事件驅動擷取的運算核心服務。

Lambda 執行模型

Lambda 會因應調用而運行您的程式碼，自動擴展到數千個並行執行，按毫秒計費，並在閒置時關閉。執行的單位是函數 (function) — 包含程式碼、執行環境 (Python, Node.js, Java, Go, Ruby, custom)、IAM 角色、環境變數以及記憶體與逾時等配置。每次調用都會獲得自己的執行環境，該環境可能會被重複使用以實現熱啟動，但不會被並行共享。

資料工程相關的硬性限制

Lambda 的限制是必考內容，因為它們直接決定了 Lambda 何時是錯誤的選擇。最大執行時間為 15 分鐘 — 任何超過此時間的任務都不適合 Lambda。最大記憶體為 10 GB，vCPU 隨記憶體成比例擴展。最大有效載荷同步調用為 6 MB，異步調用為 256 KB，通過 API Gateway 調用為 6 MB。/tmp 中的臨時存儲高達 10 GB。並行執行限制是按帳戶按區域計算的，預設為 1000，可申請調高。部署包最大為 250 MB（解壓後）或 50 MB（壓縮後），容器鏡像最高支援 10 GB。考試會設定「使用 Lambda 處理 50 GB 檔案」的情境 — 錯誤，超出了記憶體和逾時限制。「使用 Lambda 執行每日 500 GB 的 Parquet 彙總 ETL」 — 錯誤，應使用 Glue。

並行模型 — 預留與佈建

預留並行 (Reserved concurrency) 限制了函數的最大並行執行次數，並從帳戶池中預留該容量 — 保證了函數能獲得容量但也設定了上限。佈建並行 (Provisioned concurrency) 預熱執行環境，使調用跳過冷啟動 — 這會增加成本（無論是否被調用，按 GB-秒計費），但消除了延遲敏感型案例的冷啟動延遲。標準（未預留）並行則從共享帳戶池中提取，無保證。考試中「突發性事件的持續低延遲處理」通常指向佈建並行。

Lambda 目的地與 DLQ

目的地 (Destinations) 可將異步調用的結果路由到另一個服務 — 成功結果到一個目的地（SNS, SQS, EventBridge, Lambda），失敗結果到另一個。無寄件備份佇列 (Dead-letter queues, DLQ) 用於擷取在所有重試後仍然失敗的事件 — 通常是 SQS 佇列或 SNS 主題。目的地功能更豐富（包含更多中繼資料、路由更精細），是 DLQ 的現代替代方案，但為了向後相容仍支持 DLQ。

用於資料工程的 Lambda 事件來源

DEA-C01 考試要求您了解與資料擷取相關的每個事件來源。

S3 事件通知

S3 在物件建立 (s3:ObjectCreated:*)、刪除、還原、複寫和生命週期轉換時發布事件。事件通知可以發送到 Lambda、SQS、SNS 或 EventBridge（推薦的現代路徑）。對於落入 S3 的檔案，事件驅動流水線會配置 S3 通知 Lambda — 函數讀取新檔案、進行解析並將處理後的輸出寫入下游。使用 EventBridge 作為目標可以提供最強大的篩選和路由功能 — 多個規則可以訂閱同一個 S3 事件，而無需 S3 進行逐個目標的配置。

Amazon Kinesis Data Streams

Lambda 通過輪詢每個分片的事件來源映射與 Kinesis Data Streams 整合。記錄以批次方式遞送，批次大小可配置（預設 100，最高 10000）。函數處理批次，成功後映射會推進反覆運算子。分片內保證順序 — 具有相同分割區索引鍵的記錄始終進入同一個分片並按順序處理。考試非常喜歡 Kinesis-Lambda 的配置問題，因為在生產中調優批次大小或平行處理因素非常常見。

DynamoDB Streams

DynamoDB Streams 為資料表的每次插入、更新和刪除發送一條變更記錄。Lambda 通過類似 Kinesis 的事件來源映射取用這些記錄。其使用案例是變更資料擷取 (CDC) — 將 DynamoDB 的變更傳播到資料湖（S3 + Glue 目錄）、OpenSearch 用於搜尋索引，或另一個 DynamoDB 資料表用於跨區域複寫。串流檢視類型控制每條記錄中的資料：僅限索引鍵、新影像、舊影像，或新舊影像皆有。考試中「將 DynamoDB 資料表的所有變更流式傳輸到資料湖」對應的是 DynamoDB Streams + Lambda + S3。

Amazon SQS

Lambda 通過事件來源映射輪詢 SQS 佇列。標準佇列提供盡力而為的順序和至少一次遞送；FIFO 佇列提供嚴格順序和每個訊息群組正好一次處理。Lambda 映射支持可配置的批次大小（標準佇列 1-10000，FIFO 1-10）、批次視窗，並報告部分批次失敗，以便成功處理的訊息不會被重複遞送。常見模式：生產者寫入 SQS，Lambda 批次處理並寫入 S3 或 DynamoDB。

Amazon MSK 與自管 Kafka

Lambda 通過事件來源映射與 MSK 和自管 Kafka 整合。映射處理取用者群組管理、位移 (offset) 提交和分割區分配。使用案例與 Kinesis 類似，但適用於 Kafka 生態系統流水線。考試會設定「已有 MSK，希望實現事件驅動的 Lambda 處理」的情境 — 答案是 MSK 事件來源映射，而不是自定義的 Kafka 取用者。

Amazon SNS

Lambda 訂閱 SNS 主題以實現展開 (fan-out) 模式 — 一條發布的訊息會調用多個訂閱的函數。SNS 到 Lambda 是異步的（預設不批次處理，一次調用一條訊息） — 對於批次處理，建議使用 SNS 到 SQS 到 Lambda 的路徑，利用 SQS 的批次語義。

Amazon EventBridge — 事件匯流排

EventBridge 是 AWS 原生的無伺服器事件匯流排。

EventBridge 規則 — 模式匹配與路由

EventBridge 規則 (Rule) 將事件與 JSON 模式進行匹配，並將匹配的事件路由到一個或多個目標。模式可以基於事件來源、詳細資訊類型 (detail-type)、帳戶、區域或事件詳細物件中的任何欄位進行匹配。目標包括 Lambda、Step Functions、SQS、SNS、Kinesis、ECS 任務、API Gateway 等數十種服務。單個事件可以匹配多條規則並展開到多個目標 — 這就是 EventBridge 實現事件生產者與取用者鬆散耦合的方式。

EventBridge 匯流排 — 預設、自定義、合作夥伴

每個帳戶都有一個預設事件匯流排，用於接收 AWS 服務事件。自定義事件匯流排接收通過 PutEvents 從您自己的應用程式程式碼發布的事件。合作夥伴事件匯流排接收來自 SaaS 合作夥伴（如 Salesforce, Zendesk, Datadog）的事件，無需中間整合程式碼。DEA-C01 考試中「從 Salesforce 擷取事件」的答案是合作夥伴事件匯流排或 AppFlow，而不是自定義整合。

EventBridge 管道 (Pipes) — 點對點與篩選及增強

EventBridge 管道 (Pipes) 是一個點對點整合基元，它連接一個來源與一個目標，並可在兩者之間進行選用的篩選和增強。來源包括 DynamoDB Streams、Kinesis、SQS、MSK 和自管 Kafka。篩選發生在調用成本之前，因此您無需為不想處理的事件付費。增強階段會調用 Lambda 或 Step Functions 在事件到達目標前對其進行轉換。目標包括 Lambda、Step Functions、SNS、SQS、Kinesis、EventBridge 匯流排、API 目的地等。

管道 vs 規則 — 何時使用哪一個

當一個事件需要展開到多個目標、來源是 EventBridge 匯流排本身，或者您需要跨事件屬性的複雜模式匹配時，使用規則 (Rules)。當來源是串流或佇列且您需要點對點整合並帶有篩選和增強、希望避免運行單獨的 Lambda 僅用於篩選，或者來源未原生整合 EventBridge 匯流排時，使用管道 (Pipes)。考試中「在 Lambda 處理前篩選 Kinesis 事件」的答案是帶有篩選器的管道，而不是帶有提前返回邏輯的 Lambda。

EventBridge 排程器 — 一次性與重複性

EventBridge 排程器 (Scheduler) 是一項單獨的（較新的）服務，用於排程調用，取代了 CloudWatch Events 的排程規則。它支持未來時間戳的一次性排程、基於 cron 或 rate 表達式的循環排程，以及帶有靈活時間視窗的排程。它可以直接目標超過 270 種 AWS 服務。相比 CloudWatch Events 排程規則，它的優勢在於更高的擴展規模（數百萬個排程）、單個排程的自定義以及更簡潔的 API。DEA-C01 考試預期您知道排程器是在固定時間排程 Glue 工作、Lambda 或 Step Functions 執行的現代方法。

作為 CDC 的 DynamoDB Streams — 典型資料流水線

DynamoDB Streams 是 AWS 上典型的 CDC 模式。

什麼是 CDC

變更資料擷取 (Change Data Capture, CDC) 是指將來源資料存儲的每一次變更作為事件流式傳輸給下游取用者的實踐。插入、更新和刪除都會發送一個事件。下游流水線會重建來源狀態、為搜尋編製索引、為分析進行封存，或者複寫到其他區域或帳戶。

DynamoDB Streams 配置

在建立資料表時或通過更新啟用 Streams。選擇一個串流檢視類型：KEYS_ONLY（僅限變更的索引鍵）、NEW_IMAGE（變更後的項目）、OLD_IMAGE（變更前的項目）或 NEW_AND_OLD_IMAGES（兩者，適用於基於差異的下游處理）。檢視類型稍後無法更改，除非停用並重新啟用串流。

串流保留期

DynamoDB Streams 記錄保留 24 小時。取用者必須在此視窗內讀取，否則會丟失記錄。對於更長的保留期，請配置 Amazon Kinesis Data Streams for DynamoDB，它將變更事件匯出到 Kinesis Data Stream，保留期最高可達 365 天。

常見 CDC 流水線模式

標準模式：DynamoDB Streams → Lambda → S3 (Parquet) 用於資料湖擷取。對於即時搜尋：DynamoDB Streams → Lambda → OpenSearch。對於全域資料表以外的跨區域複寫：DynamoDB Streams → Lambda → 目標 DynamoDB 表。對於稽核日誌：DynamoDB Streams → EventBridge 管道 → S3。

S3 事件通知 — 檔案落地觸發器

S3 事件通知是資料湖擷取最常見的進入點。

通知目標

S3 向 Lambda、SQS、SNS 或 EventBridge 發布事件。EventBridge 是推薦的現代目標，因為它支持多個規則訂閱同一個事件而無需重新配置 S3。Lambda 直接而簡單；SQS 為較慢的取用者緩衝事件；SNS 則展開到多個訂閱者。

事件類型

最常見的事件類型是 s3:ObjectCreated:Put、s3:ObjectCreated:Post、s3:ObjectCreated:CompleteMultipartUpload、s3:ObjectRemoved:Delete 以及 s3:ObjectRestore:Completed（用於 Glacier 還原）。通過前綴 (prefix) 和後綴 (suffix) 進行篩選，以將通知限制在相關物件上 — 例如僅限 incoming/ 前綴和 .parquet 後綴。

S3 事件篩選的局限性

S3 事件通知篩選僅限於物件索引鍵的前綴和後綴。對於更豐富的篩選（物件大小、中繼資料、標籤），請路由到 EventBridge 並使用 EventBridge 規則模式，這可以匹配任何欄位。考試中「按物件大小篩選 S3 事件」的答案是 EventBridge 目標加規則模式，而非原生 S3 通知篩選。

常見模式 — 觸發 Glue、目錄更新

典型的資料湖模式：檔案落入 S3，S3 事件觸發 Lambda，Lambda 要麼在線執行輕量級處理，要麼為繁重工作調用 Glue ETL 工作。對於目錄維護，S3 事件觸發 Lambda，在出現新前綴時更新 Glue 分割區，從而避免完整的爬網程序運行。

Lambda vs Glue vs Step Functions — 服務選擇

DEA-C01 考試經常測試該選擇哪種運算服務。

Lambda — 短期、事件驅動的處理

當任務能在 15 分鐘、10 GB 記憶體和 6 MB 有效載荷內完成時，使用 Lambda。示例：將新的 S3 檔案路由到正確的 Glue 工作、轉換小型的 DynamoDB Streams 批次、在存儲前驗證 API webhook 有效載荷、在資料到達時發送指標。避免將 Lambda 用於批次 ETL、大檔案處理或長時間運行的彙總。

Glue — 大規模批次 ETL

對於超出 Lambda 限制的批次轉換，使用 Glue ETL。Glue 處理數十到數百 GB 甚至 TB 級的資料，運行 Spark 分散式運算，整合 Glue 資料目錄，並按 DPU-秒計費。Glue 不適用於極短的事件驅動任務（工作啟動開銷需要幾分鐘）。

Step Functions — 跨服務工作流程編排

當流水線需要協調多個服務時使用 Step Functions — 例如觸發 Glue 工作、等待完成、運行 Lambda 進行驗證、調用 Redshift COPY 並在成功後通知的工作流程。Step Functions 處理重試、錯誤擷取、平行分支以及人工介入步驟。當單個 Lambda 或單個 Glue 工作足夠時，請避免使用 Step Functions。

決策矩陣

考試會不斷設定服務選擇情境。套用矩陣：短期且事件驅動 → Lambda。長期批次 ETL → Glue。多步協調 → Step Functions。複雜流水線三者結合 → S3 事件 → Lambda 路由員 → Step Functions → Glue ETL（通過 Lambda 目的地發送成功/失敗通知）。熟記此矩陣可應對大多數領域 1 的服務選擇問題。

Lambda 與 EventBridge 的常見考試陷阱

DEA-C01 考試設定了一組一致的陷阱。請務必記住這七個陷阱。

陷阱 1 — 使用 Lambda 執行批次 ETL

引用最多的陷阱。Lambda 的 15 分鐘逾時使其不適合任何超過幾分鐘的批次處理。正確答案應是 Glue 或 Step Functions + Glue。

陷阱 2 — 混淆 EventBridge 規則與管道

規則通過強大的模式匹配將事件展開到多個目標。管道是帶有篩選和增強的點對點整合。考試中「在 Lambda 之前篩選 Kinesis 記錄」預期選管道；「將事件展開到五個不同的處理器」預期選規則。

陷阱 3 — S3 事件通知篩選器的局限性

S3 事件只能按前綴和後綴篩選。按物件大小、中繼資料或標籤篩選需要路由到 EventBridge 並使用規則模式。

陷阱 4 — Kinesis 觸發器的批次大小調優錯誤

批次大小設定太小會讓 Lambda 資源閒置並增加調用成本。設定太大則會導致單次調用 OOM 或逾時。CloudWatch 中的 IteratorAge 指標會告知何時需要調優批次大小或平行處理因素。

陷阱 5 — DynamoDB 串流檢視類型選擇錯誤

當取用者需要新項目的值時選擇了 KEYS_ONLY，會迫使每個事件額外執行一次 GetItem 調用，使讀取成本翻倍。對於大多數 CDC 案例，請選擇 NEW_IMAGE；當下游需要計算差異時，選擇 NEW_AND_OLD_IMAGES。

陷阱 6 — 低估了 DynamoDB Streams 的保留期

串流記錄僅保留 24 小時。如果您的取用者暫停或積壓時間過長，記錄將永久丟失。對於長達 365 天的保留，請使用 Kinesis Data Streams for DynamoDB。

陷阱 7 — 忘記使用 EventBridge 排程器進行定時任務

考生為新的排程工作提議 CloudWatch Events 排程規則。現代化的答案是 EventBridge 排程器 — 更高的擴展性、更好的整合以及更多的功能。

關鍵數據與必背 Lambda + EventBridge 事實

Lambda 硬性限制

• 最大執行時間：15 分鐘
• 最大記憶體：10 GB（vCPU 隨記憶體擴展）
• 最大同步有效載荷：6 MB
• 最大異步有效載荷：256 KB
• 臨時存儲：/tmp 中最高 10 GB
• 預設並行：每個區域每個帳戶 1000
• 部署包：解壓後 250 MB，壓縮後 50 MB
• 容器鏡像：最高 10 GB

Lambda Kinesis 觸發器

• 批次大小：預設 100，最高 10000 條記錄或 6 MB
• 批次視窗：預設 0，最高 300 秒
• 平行處理因素：每個分片 1-10
• 起始位置：TRIM_HORIZON, LATEST, AT_TIMESTAMP

DynamoDB Streams

• 保留期：24 小時
• 檢視類型：KEYS_ONLY, NEW_IMAGE, OLD_IMAGE, NEW_AND_OLD_IMAGES
• 對於更長保留期，請使用 Kinesis Data Streams for DynamoDB

EventBridge

• 規則 (Rules)：具有展開到多個目標的模式匹配
• 管道 (Pipes)：帶篩選和增強的點對點整合
• 排程器 (Scheduler)：一次性和循環排程
• 匯流排 (Buses)：預設、自定義、合作夥伴

S3 事件通知

• 目標：Lambda, SQS, SNS, EventBridge
• 篩選：僅限物件索引鍵的前綴和後綴
• 事件類型：ObjectCreated, ObjectRemoved, ObjectRestore 等

決策矩陣

• 短期事件處理 → Lambda
• 批次 ETL → Glue
• 多服務編排 → Step Functions
• Cron 風格排程 → EventBridge 排程器

常見問題 (FAQ) — Lambda 與 EventBridge 熱門問題

Q1 — 在資料處理中，我應該在什麼時候使用 Lambda 而非 Glue？

當工作負載是短期（低於 15 分鐘）、小負載（同步調用低於 6 MB）、事件驅動且無狀態時，請使用 Lambda。Lambda 擅長輕量級轉換、路由、驗證以及服務間的編排黏合。對於任何超出 Lambda 限制的批次 ETL — 數 GB 到 TB 級的處理、數小時的執行時間、分散式 Spark 運算、結構描述感知轉換以及與 Glue 資料目錄的整合 — 請使用 Glue。最清晰的規則是：如果任務是「對單個事件做出反應，執行微小轉換並寫入目的地」，選 Lambda。如果任務是「對昨天的資料執行每日 ETL」，選 Glue。混合模式也很常見：S3 事件觸發 Lambda，Lambda 驗證並調用 Glue 工作，Glue 處理沈重的 ETL，Step Functions 或目的地則路由成功或失敗。將 Lambda 誤用於批次 ETL 是 DEA-C01 領域 1 最常見的陷阱。

Q2 — EventBridge 規則 (Rules) 與 EventBridge 管道 (Pipes) 有什麼區別？

EventBridge 規則 將事件匯流排上的事件與 JSON 模式進行匹配，並將匹配的事件路由到一個或多個目標 — 「展開 (fan-out)」是其核心能力。當來源是匯流排本身（AWS 服務事件、通過 PutEvents 的自定義應用程式事件），且您需要靈活的模式匹配和多目標路由時，請使用規則。EventBridge 管道 是點對點的：將一個來源（Kinesis、DynamoDB Streams、SQS、MSK、自管 Kafka、Amazon MQ）連接到一個目標，並可在兩者之間進行選用的篩選和增強。當來源是串流或佇列，且您想要託管的點對點整合而不想專門為了篩選和轉發編寫 Lambda 時，請使用管道。決策依據是「形狀」：從匯流排展開 → 規則；一個串流/佇列到一個目標帶選用轉換 → 管道。在真實架構中它們相輔相成 — 管道可以將匯流排作為目標，隨後由規則進一步展開。

Q3 — 我該如何調優 Lambda Kinesis 觸發器以實現高吞吐量？

吞吐量由三個參數驅動。批次大小（預設 100，最高 10000）控制每次調用的記錄數 — 增加此值可減少每次調用的開銷；如果 Lambda 發生 OOM 或批次逾時則減小此值。批次視窗（預設 0，最高 300 秒）控制映射在調用前等待積累批次的時間 — 對於低流量分片增加此值以避免產生大量浪費的微小調用；對於高流量分片保留為 0。平行處理因素 (1-10) 控制每個分片的並行調用次數 — 當設定為 N 時，映射會按分割區索引鍵將記錄拆分為 N 個平行子流，在保持每個分割區索引鍵內有序的同時，平行處理不同的索引鍵。當分片處理受限於 CPU 且單個 Lambda 無法跟上分片 2 MB/s 的讀取預算時，請使用平行處理因素。監控 IteratorAge（待處理記錄）和 IncomingRecords/GetRecords.Bytes 以診斷落後原因。增加函數記憶體同時也會增加 vCPU，從而提高單條記錄的處理吞吐量。考試中「Lambda 在 Kinesis 上落後且 IteratorAge 很高」的典型修復方案就是增加平行處理因素。

Q4 — 我應該在什麼時候使用 EventBridge 排程器而非 CloudWatch Events 排程規則？

對於任何新的排程調用，請使用 EventBridge 排程器。它可以擴展到每個帳戶數百萬個排程、支持靈活的時間視窗、直接與 270 多個 AWS 服務整合而無需中間 Lambda、支持單個排程的重試和無寄件備份佇列配置，並提供更簡潔的未來時間點一次性排程。CloudWatch Events 排程規則是舊機制，具有硬性限制（每個區域每個帳戶 300 條規則）、目標整合較淺（主要是 Lambda 和 Step Functions），且無法針對每條規則自定義重試行為。DEA-C01 考試預期您將排程器視為「排程每日 ETL 工作」或「每 15 分鐘排程一次 Lambda」的現代答案。CloudWatch Events 排程規則仍受支持以相容現有架構，但不推薦用於新設計。

Q5 — 我該如何將 DynamoDB 資料表的每一次變更傳播到資料湖？

典型模式是 DynamoDB Streams + Lambda + S3。在資料表上啟用 Streams，檢視類型選擇 NEW_AND_OLD_IMAGES，以便取用者可以看到變更前和變更後的值（允許下游計算差異或正確處理刪除）。配置一個從串流讀取並將記錄按日期分割以 Parquet 格式寫入 S3 的 Lambda 事件來源映射。對於超過 24 小時的保留期或更高的吞吐量，請使用 Amazon Kinesis Data Streams for DynamoDB，它將變更事件導出到保留期高達 365 天的 Kinesis 流中，隨後使用 Kinesis Data Firehose 自動緩衝並以 Parquet 格式寫入 S3。對於零 ETL (zero-ETL)，針對搜尋案例可使用 DynamoDB 與 OpenSearch 的零 ETL 整合，或者等待直接的 DynamoDB 到 S3 零 ETL 功能。如果排程了爬網程序或在 Athena 中配置了分割區投影，Glue 資料目錄會自動獲取 S3 分割區。

Q6 — 我該如何在事件驅動流水線中處理 Lambda 失敗？

失敗處理包含三個層次。第一，自動重試 — 對於串流來源（Kinesis, DynamoDB Streams），映射會重試該批次直至成功或達到配置的最大重試次數（預設為無限直至記錄過期）。對於異步調用（S3 事件, EventBridge），Lambda 會自動重試兩次。對於 SQS，重試受佇列的重新導向政策控制。第二，針對 Kinesis 和 DynamoDB Streams 的函數錯誤時平分 (bisect on function error) — 重試時將失敗的批次平分為二並重試每一半，以此隔離「毒丸」記錄。第三，失敗時目的地 (on-failure destinations) 或無寄件備份佇列 (DLQ) — 當重試耗盡時，將失敗的事件發送到 SQS 佇列、SNS 主題、EventBridge 匯流排或 Lambda，以便稍後分析或重新播放。現代的目的地功能包含比舊版 DLQ 更多的中繼資料，是推薦選擇。務必為生產環境的事件驅動流水線配置目的地或 DLQ — 否則耗盡的重試會導致事件被靜默丟棄。

Q7 — 在 S3 事件到達我的 Lambda 之前，篩選它們的正確模式是什麼？

S3 事件通知的原生篩選僅限於物件索引鍵的前綴和後綴 — 如 incoming/ 前綴或 .parquet 後綴。對於更豐富的篩選（物件大小、內容類型、標籤、中繼資料），請通過 EventBridge 進行路由：配置 S3 發布到 EventBridge 而非直接到 Lambda，然後編寫一個 EventBridge 規則，其模式匹配所需的條件，並將 Lambda 作為規則目標。EventBridge 規則可以匹配事件詳細資訊中的任何欄位，包括物件大小、e-tag 以及 S3 事件中的任何其他中繼資料。這樣做的好處是顯著的：Lambda 僅因匹配完整篩選條件的事件而被調用，從而節省了調用成本並簡化了函數程式碼。DEA-C01 考試中「我們希望 Lambda 僅處理大於 100 MB 的 Parquet 檔案」的情境，EventBridge 規則模式是權威答案，而不是在 Lambda 內部進行篩選並提前返回。

延伸閱讀 — Lambda 與 EventBridge 官方文件

權威的 AWS 來源包括：Lambda 開發人員指南概述、涵蓋 Kinesis, DynamoDB Streams, SQS, MSK 與自管 Kafka 的事件來源映射文檔、涵蓋批次大小、平行處理因素與 IteratorAge 的 Lambda Kinesis 觸發器配置頁面、涵蓋規則、匯流排、合作夥伴事件與 API 的 EventBridge 使用者指南、涵蓋來源、篩選器、增強與目標的 EventBridge 管道 (Pipes) 文檔、涵蓋一次性和循環排程的 EventBridge 排程器使用者指南，以及涵蓋目標與篩選的 S3 事件通知頁面。

AWS 運算部落格有多篇關於 Lambda 效能調優、冷啟動緩解、佈建並行以及事件來源映射內部的深入探討。AWS 架構部落格涵蓋了事件驅動架構模式與參考設計。AWS 無伺服器應用程式模型 (SAM) 和 CDK 文檔展示了如何以宣告方式表達 Lambda + EventBridge 堆疊。最後，AWS Lambda Powertools 程式庫（Python, Java, TypeScript）提供了結構化日誌記錄、追蹤和指標實用程式，是生產級 Lambda 的事實標準 — 其文檔詳細介紹了 DEA-C01 預期您在架構層級了解的模式。