這些題目為學習目的而獨立製作，並非 AWS 官方考題、實際考題、外流題或考題庫。
SAA-047
需要從 IoT 裝置接收每秒數萬筆遙測資料,並在保持各裝置時間序列順序的前提下,同時平行進行即時異常偵測與蓄積至分析平台兩項處理。若其中一項處理出現缺陷,必須能夠讀回最近 24 小時的資料重新處理。下列哪項服務最為合適?
選項
解析與正確答案
閱讀解析與正確答案（劇透：建議先自行作答）
正確答案：B. Amazon Kinesis Data Streams
解析
Kinesis Data Streams 以分割索引鍵為單位(於分片內)保證順序,並在保留期間(預設 24 小時、最長 365 天)內將記錄保留於串流上。由於多個取用方可從各自獨立的位置讀取相同記錄,因此可同時滿足平行處理與重新處理兩項需求。
各選項解析
A. 在 Amazon SNS 的主題訂閱 2 個 Lambda 函式以進行扇出
SNS 雖可將相同訊息傳遞給多個訂閱者,但標準主題的傳遞僅有一次,既不具備保留與重新讀取的機制,也沒有順序保證。若要保證順序則需使用 FIFO 主題,而 FIFO 主題能夠傳遞的目標只有 SQS 佇列(FIFO 或標準)。無法直接訂閱 Lambda 函式,必須在中間放置 SQS 佇列;若放置的是 SQS 標準佇列,訊息群組 ID 不會被傳遞,順序保證仍然會失效。
B. Amazon Kinesis Data Streams
正解。分片內的順序保證、保留期間內的重新讀取、多個取用方的獨立讀取等 3 項特性皆與需求一致。
C. Amazon SQS 的 FIFO 佇列
FIFO 佇列雖以訊息群組為單位保證順序,但訊息於消費後即遭刪除,因此無法讀回過去的資料,也不滿足將相同訊息分送給 2 項獨立處理的需求。
D. Amazon SQS 的標準佇列
標準佇列不保證順序。此外,訊息以由單一取用方處理後刪除為前提,因此既無法將相同資料流向 2 項處理,也無法讀回已刪除的訊息。
實際使用情境
Amazon Kinesis Data Streams 為即時擷取大量記錄,並將其於一定期間內保留於串流上的分散式串流服務。串流分為分片(shard)這個單位,並由生產方指定的分割索引鍵雜湊決定記錄的配置分片。相同分割索引鍵的記錄必定進入相同分片,且分片內依投入順序讀出,因此可實現「以各裝置」「以各使用者」為單位的順序保證。容量模式有佈建型(自行管理分片數)與隨需型(依流量自動調整)兩種。 與佇列的決定性差異在於記錄「即使被消費也不會消失」。取用方持有自身的讀取位置(迭代器),在保留期間(預設 24 小時、最長 365 天)內隨時可讀回過去的記錄。憑藉此性質,可自然地組成多個取用方應用程式互不干擾地獨立讀取同一串流的扇出架構(若使用強化型扇出,更可為每個取用方確保專用輸送量)。另一方面,SQS 為由單一取用方處理後刪除訊息的工作佇列,刪除後無法讀回,標準佇列亦不保證順序。SNS 雖可進行推送型的扇出,但標準主題不具備保留與重新讀取的機制。若僅是單純流入 S3、Redshift、OpenSearch,則不需要分片管理的 Amazon Data Firehose 有時更為合適。 SAA-C03 中,若「希望保持順序」「希望將相同資料流向多項處理」「希望回溯一定期間重新處理」「每秒數萬筆的串流」等關鍵字齊備,Kinesis Data Streams 即為正解。反之,若為「希望避免重複且僅處理一次」「需要嚴格順序的作業佇列」則為 SQS FIFO,若為「鬆散耦合的任務分散」則為 SQS 標準佇列,如此判讀。