以 Amazon Kinesis 串流資料擷取

串流資料 Kinesis 工作負載是 SAA-C03 的核心考題，因為即時架構出現在每一種現代應用場景之中——IoT 遙測、點擊流分析、日誌匯聚、詐欺偵測，以及變更資料擷取（CDC）管線。AWS 考試測試的是解決方案架構師能否在嚴格的延遲、耐久性、排序與成本限制下，選出正確的串流資料 Kinesis 服務（Amazon Kinesis Data Streams、Amazon Data Firehose、Amazon Managed Service for Apache Flink，或 Amazon MSK）。混淆 Kinesis Data Streams 與 Amazon Data Firehose，每次考試就會錯掉兩到四題。

本篇串流資料 Kinesis 學習筆記完整解析 SAA-C03 考試相關的所有行為——shard 機制、partition key、hot shard、on-demand 與 provisioned 容量模式、一至 365 天的保留視窗、Kinesis Client Library（KCL）、enhanced fan-out、跨帳號串流共享、Firehose 目的地（Amazon S3、Amazon Redshift、Amazon OpenSearch Service、Splunk、通用 HTTP）、Lambda 轉換、dynamic partitioning、Apache Flink 串流處理，以及 Amazon MSK（含 MSK Serverless 與 MSK Connect）。每個段落末尾皆附上考試要求你一眼就能套用的決策規則。

什麼是 AWS 上的串流資料？

串流資料是由多個來源（裝置、應用程式、資料庫、點擊流）持續產生的無邊界記錄序列，並由一個或多個下游系統以近即時的方式消費。與批次資料不同，串流資料永遠不會結束，記錄必須按順序處理（至少在同一個 key 的範圍內），而且系統必須在 producer 增加時水平擴展。在 AWS 上，串流資料 Kinesis 家族加上 Amazon MSK，是取代自行架設的 Apache Kafka、Apache Flink 或 Apache Storm 叢集的受管建構模塊。

串流資料 Kinesis 產品組合有四大支柱：

1. Amazon Kinesis Data Streams（KDS） — 耐久、可重播、有序的日誌。你自己撰寫 producer，自己撰寫 consumer，自己控制 shard 數量。
2. Amazon Data Firehose（前身為 Kinesis Data Firehose）— 完全受管的交付管線，自動批次、轉換、壓縮，並將串流資料送到 Amazon S3、Amazon Redshift、Amazon OpenSearch Service、Splunk、HTTP endpoint 或合作夥伴 SaaS。
3. Amazon Managed Service for Apache Flink（前身為 Kinesis Data Analytics）— 無伺服器 Apache Flink 執行環境，支援以 Java、Scala、Python 或透過 Zeppelin notebook 的 SQL 進行有狀態串流處理。
4. Amazon MSK — 完全受管的 Apache Kafka，提供 provisioned 叢集或 MSK Serverless 兩種模式，並透過 MSK Connect 支援 Kafka Connect 連接器。

串流資料 Kinesis 出現在 SAA-C03 考試指南的第一領域（設計安全架構）、第二領域（彈性架構）、第三領域（高效能架構）以及第四領域（成本最佳化架構）中，平均每個領域約有一道串流資料 Kinesis 題目。

為什麼串流資料 Kinesis 對 SAA-C03 如此重要

SAA-C03 第三領域（高效能架構）明確列出「判斷高效能且／或可擴展的儲存解決方案」以及「設計高效能且具彈性的運算解決方案」——兩者都是串流資料 Kinesis 家族所解決的問題。第四領域（成本最佳化架構）考察 Kinesis Data Streams on-demand 與 provisioned 模式的取捨，以及 Amazon Data Firehose 完全受管零營運的成本優勢。第二領域（彈性架構）考察串流資料 Kinesis 的保留視窗（一至 365 天）作為重播安全機制。第一領域（安全架構）考察 KMS 加密、VPC endpoint、IAM 資源政策，以及跨帳號串流資料 Kinesis 存取。

白話文解釋 Streaming Data Kinesis

串流資料 Kinesis 家族聽起來很抽象，但只要對應到日常生活情境就會豁然開朗。以下三個類比能讓你瞬間理解。

類比一 — 夜市攤位的訂單傳票系統（夜市廚房）

想像一個人聲鼎沸的台灣夜市，後廚同時處理數十桌訂單。

• Amazon Kinesis Data Streams 是貫穿廚房中央的傳票軌道。每張訂單（記錄）依照桌號（partition key）分配到不同的出餐道（shard），訂單紙票預設保留一天，最長可保留 365 天，讓多位師傅（consumer）事後都能翻查。
• Amazon Data Firehose 是外送平台的配送員——你不用盯著每張訂單，配送員等到裝滿一箱（5 MiB）或等了五分鐘（300 秒），就直接送到你事先指定的地址（Amazon S3 倉庫、Amazon Redshift 存檔、Amazon OpenSearch Service 索引、Splunk 端，或第三方 HTTP endpoint）。
• Amazon Managed Service for Apache Flink 是站在傳票軌道旁邊的結帳師傅，即時掃描每張票，計算「過去一分鐘每個攤位賣出幾份」，並把彙總數字推送到看板——有狀態串流處理，完全不批次。
• Amazon MSK 是同樣的傳票軌道，只不過老闆堅持用 Apache Kafka 規格的票夾，讓原本熟悉 Kafka 的員工可以直接沿用既有工具。

考題說「只要把串流資料寫入 S3 並轉為 Parquet 加上 KMS 加密」，答案就是配送員（Amazon Data Firehose）。考題說「多個 consumer 必須各自讀取每一筆記錄，並可回溯七天前的資料」，答案就是有保留功能的傳票軌道（Amazon Kinesis Data Streams）。

類比二 — 捷運路線圖（交通號誌）

把串流資料 Kinesis 想像成一座大都市的捷運系統。

• shard 是一條路線。增加 shard 就是增加平行路線，讓每分鐘能通過更多列車。有四個 shard 的串流，吞吐量是單 shard 串流的四倍。
• partition key 是車票上的區間戳章。持有相同戳章的旅客永遠搭同一條路線，因此同一個 key 的排序得以保留。設計不良的戳章（所有人都蓋「VIP」）會讓一條路線壅塞——這就是 hot shard。
• On-demand 模式是能依人潮自動加開班次的捷運；provisioned 模式是你必須事先預訂車廂數量、空車也照樣付費的通勤鐵路。
• Enhanced fan-out 是獨立配發給某位 VIP 乘客的專屬快線——每個 shard 每個 consumer 各自享有 2 MB/s 的專屬吞吐量，不與其他乘客共用。
• KCL（Kinesis Client Library）是協調哪位 consumer 負責哪節車廂、並記錄閱讀進度的站務長。

類比三 — 廚房工作站（廚房）

或者把它想成餐廳廚房出餐的高峰時段。

• Amazon Kinesis Data Streams 是出餐口——訂單飛速通過，每位煮場師傅（consumer）各自取用一份，紙票釘著保留一天，讓主廚事後核對。
• Amazon Data Firehose 是洗碗機輸送帶——盤子進去髒的，出來就是洗好、烘乾、整齊疊好送到後門（Amazon S3），完全不需要人工調整。
• Amazon Managed Service for Apache Flink 是大聲報數的副主廚：「五號桌已點三份主菜、兩份甜點，累計消費 84 元」——即時有狀態統計，不批次。
• Amazon MSK 是同樣的出餐口，只是主廚堅持用 Apache Kafka 的義式廚房規則，而不是 Kinesis Data Streams 的法式規則。

記住這三個畫面，每一道串流資料 Kinesis 考題都會變成一道路由分流題。

核心運作原則 — 串流資料 Kinesis 基礎

每個串流資料 Kinesis 服務都建立在四個共同原則之上。

1. 分區有序日誌。 記錄落在 shard（KDS）或 partition（MSK）中。順序保證是 per shard，而非跨 shard。partition key 由客戶自行負責設計。
2. 拉取式或推送式消費。 KDS 與 MSK 是拉取式——consumer 主動輪詢。Amazon Data Firehose 是推送式——服務依照緩衝排程主動推送到你的目的地。
3. 保留視窗將 producer 與 consumer 解耦。 記錄在串流資料 Kinesis 緩衝區中存活於可設定的視窗內（KDS：預設 24 小時，標準延伸 7 天，延長保留 365 天；MSK：直到磁碟滿或設定的保留時數為止；Firehose：只保留到批次抵達目的地為止）。
4. 吞吐量水平擴展。 為 KDS 新增 shard，為 MSK 新增 broker，或讓 MSK Serverless 與 Firehose 自動為你擴展。

Amazon Kinesis Data Streams — 耐久的串流日誌

Amazon Kinesis Data Streams（KDS）是最基礎的串流資料 Kinesis 服務。它將記錄儲存在 shard 中、依 partition key 維護順序、預設保留 24 小時（可延長至 365 天），並提供兩種 consumer 模式：傳統共享吞吐量模式，以及 enhanced fan-out 模式。

Shard、吞吐量與記錄大小

每個 KDS shard 可持續承受：

• 寫入：1 MiB/s 或 1,000 筆記錄/秒，以先觸及者為準。
• 傳統讀取：2 MiB/s 或每秒 5 次 GetRecords 呼叫，由所有傳統 consumer 共享。
• Enhanced fan-out 讀取：每個已註冊的 consumer 每個 shard 各自獨享 2 MiB/s（HTTP/2 推送）。

一筆記錄上限為 1 MiB（payload 加上 partition key）。考試很愛問 producer 寫入一筆 2 MiB 記錄會發生什麼事——答案是 ProvisionedThroughputExceededException，無論 shard 數量為何。

Partition key 與 hot shard

partition key 是決定平行度的設計旋鈕。分佈良好的 key（user_id、device_id、session_id）能均勻散布記錄。偏斜的 key（常數字串、只有少數國家主導的國家代碼，或低基數屬性）會將記錄集中在同一個 shard 上——這就是 hot shard——整條串流的吞吐量便被鎖死在 1 MiB/s，無論 shard 數量多少。

On-demand 模式與 provisioned 模式

Amazon Kinesis Data Streams 提供兩種容量模式：

• Provisioned 模式：你指定 shard 數量，按 shard-hour 加上 PUT payload 單位計費。適合穩定可預測的工作負載，可精確調整大小。你需要自行負責 resharding（SplitShard、MergeShards）以因應流量增長。
• On-demand 模式：AWS 自動擴展 shard 數量，預設每條串流最高支援 200 MiB/s 寫入與 400 MiB/s 讀取。按擷取的 GB 數與讀取的 GB 數計費，無需計算 shard。最適合流量不規律、未知或全新的工作負載。

保留視窗：1 天、7 天、365 天

預設保留期間為 24 小時。延伸保留至 7 天只需切換開關，無需額外的 per-GB 費用（僅需支付 per-shard-hour 的溢價）。從 7 天到 365 天的長期保留則按每 GB-month 儲存量以及超過七天後的 GetRecords 每 GB 讀取量計費。每當考題詢問「回放一年前的事件而無需先移至 Amazon S3」，長期保留就是串流資料 Kinesis 的答案。

KCL — Kinesis Client Library

Kinesis Client Library（KCL）是 AWS 提供的 consumer 框架（支援 Java、Python、Node.js、.NET、Ruby），功能包含：

• 探索 shard 並將其分配給 worker 實例。
• 在 Amazon DynamoDB 資料表中記錄進度（每個 application name 對應一個資料表）。
• 處理 shard 分割、合併與 worker 故障。
• 保證每筆記錄對每個應用程式至少傳遞一次（at-least-once）。

多個應用程式可以各自使用唯一的 application name（因此擁有各自的 checkpoint 資料表）來共享同一條串流。這就是傳統模式下對多個獨立 consumer 進行 fan-out 的方式。

Enhanced fan-out

Enhanced fan-out（EFO）是串流資料 Kinesis 在多個 consumer 需要低延遲、專屬讀取吞吐量時的答案。每個已註冊的 consumer 各自獲得：

• 每個 shard 專屬 2 MiB/s（不與其他 EFO consumer 共享）。
• HTTP/2 推送交付，端對端延遲低於 200 ms。
• 每條串流最多可有 20 個 consumer。

EFO 每個 consumer-shard-hour 及每 GB 讀取量都需額外付費，因此請保留給真正需要隔離的 consumer 使用。在傳統模式下，一個 shard 上的第五個 consumer 必須與其他四個搶用同樣的 2 MiB/s；使用 EFO 後，每個 consumer 各自擁有獨立的 2 MiB/s 管道。

跨帳號串流共享

Kinesis Data Stream 可透過附加在串流上的資源型 IAM 政策（2023 年起支援），或傳統的跨帳號 IAM 角色假設方式，從其他 AWS 帳號進行讀取或寫入。考試的常見情境是：帳號 A 擁有串流，帳號 B 執行 consumer；在串流上附加資源政策，允許帳號 B 的角色呼叫 SubscribeToShard、GetRecords 與 DescribeStream。用於串流加密的 AWS KMS key 也必須授予 consumer 帳號 Decrypt 權限。

Producer：SDK、KPL、Kinesis Agent、Firehose 作為 producer

• AWS SDK PutRecord / PutRecords — 最底層，彈性最高。
• Kinesis Producer Library（KPL） — 非同步、批次、聚合（將多筆邏輯記錄聚合成一筆 Kinesis 記錄）、自動重試。搭配 KCL 使用以自動解聚合。
• Amazon Kinesis Agent — 安裝在 EC2 上的 Java 日誌追蹤程式，將日誌檔案推送到 KDS 或 Firehose。
• Amazon Data Firehose 本身可作為 KDS 的 consumer，讀取 KDS 的記錄後直接送至 S3/Redshift/OpenSearch，無需撰寫任何程式碼。

Amazon Data Firehose — 零營運交付管線

Amazon Data Firehose（2024 年從 Kinesis Data Firehose 更名）是完全受管的串流資料 Kinesis 服務，負責擷取記錄並透過批次、壓縮、加密、格式轉換以及可選的 Lambda 轉換，將資料交付至預設目的地。無需調整 shard 大小、無需執行 consumer、無需管理 checkpoint。

Firehose 目的地

Amazon Data Firehose 支援以下目的地：

• Amazon S3 — 最常用的目的地；支援 GZIP、Snappy、ZIP、Parquet 和 ORC 格式轉換。
• Amazon Redshift — Firehose 先將批次資料落地到 S3，再發出 COPY 指令載入 Redshift。
• Amazon OpenSearch Service（及 Amazon OpenSearch Serverless）— 直接寫入索引，可選配 S3 備份。
• Splunk — 透過 HTTPS 事件收集器（HEC）。
• 通用 HTTP endpoint — 任何 HTTPS endpoint，支援可設定退避的重試機制。
• 合作夥伴目的地 — Datadog、MongoDB Atlas、New Relic、Coralogix、Logz.io、Dynatrace、Honeycomb、Sumo Logic、Elastic Cloud。
• Apache Iceberg 資料表（在 S3 中透過 Glue Data Catalog）。

考試一定會考 S3、Redshift、OpenSearch 和 Splunk 這四個目的地。

緩衝：大小與時間

Firehose 依兩個緩衝提示批次記錄，以先觸及者為準：

• 緩衝大小：1 MiB 至 128 MiB（S3 預設 5 MiB，OpenSearch 預設 1 MiB）。
• 緩衝時間：0 至 900 秒（預設 300 秒）。

緩衝越小，資料越即時，但代價是更多、更小的目的地檔案——進而產生更多 Amazon S3 PUT 請求以及後續更昂貴的 Athena 掃描費用。緩衝越大則越省錢，但延遲資料能見度。

Lambda 轉換

每個 Firehose delivery stream 可選擇性地呼叫 AWS Lambda 函式，在傳輸途中轉換記錄——解析 JSON、新增欄位、轉換格式、移除 PII 或遮罩敏感數值。Lambda 函式接收一批記錄，回傳帶有每筆記錄 result 狀態（Ok、Dropped 或 ProcessingFailed）的轉換後批次。失敗的記錄會送往 S3 錯誤儲存桶。

Dynamic partitioning

Dynamic partitioning 是串流資料 Kinesis Firehose 的功能，可依據記錄內容，將記錄寫入 Amazon S3 中的分區前綴路徑——例如 s3://bucket/year=2026/month=04/day=20/customer_id=42/。若不使用 dynamic partitioning，你只會得到一個由交付時間控制的 YYYY/MM/DD/HH/ 前綴，這會使 Athena 的分區修剪失效。Dynamic partitioning 支援：

• JQ 風格的表達式，從 JSON 記錄中提取分區值。
• Lambda 提供的 partition key，用於非 JSON 記錄。
• 每筆記錄額外計費——按每 GB 分區量計費。

Firehose 資料來源

一個 Firehose delivery stream 從一個來源讀取資料：

• Direct PUT — producer 直接對 Firehose 呼叫 PutRecord / PutRecordBatch。
• Amazon Kinesis Data Streams — Firehose 作為 KDS 的 consumer，拉取記錄後交付出去。
• Amazon MSK（MSK 叢集或 MSK Serverless）— Firehose 消費 Kafka topic 並落地到 S3/Redshift/OpenSearch。
• AWS IoT、Amazon CloudWatch Logs、Amazon CloudWatch Events、AWS WAF 日誌、Amazon VPC flow logs、Amazon Route 53 Resolver 查詢日誌 — 原生整合。

Amazon Managed Service for Apache Flink（前身為 Kinesis Data Analytics）

Amazon Managed Service for Apache Flink 是無伺服器的 Apache Flink 執行環境，讓你無需管理 Flink 叢集就能建置有狀態的串流處理應用程式。2023 年從 Kinesis Data Analytics 更名；考試可能仍使用任一名稱。

三種撰寫模式

1. Apache Flink 應用程式（Java、Scala、Python） — 完整的 DataStream 或 Table API，封裝成 JAR 或 ZIP 上傳至 S3 後提交。最適合複雜事件處理、工作階段化、join 以及視窗聚合。
2. Studio notebooks with Apache Zeppelin — 互動式 SQL、Python 或 Scala notebook，背後由 Flink 驅動。適合臨時探索與原型開發，並可升格為生產環境應用程式。
3. SQL 應用程式（舊版 Kinesis Data Analytics for SQL） — 原始的 SQL on stream 引擎。AWS 已將其標記為舊版，建議新工作負載改用 Flink SQL via Studio。

資料來源與接收端

Managed Service for Apache Flink 可從 Kinesis Data Streams、Amazon MSK、Amazon MSK Serverless 以及其他 Flink 支援的連接器（Kafka、Kinesis Firehose、Amazon S3、Amazon DynamoDB Streams）讀取資料。寫入目的地也包含同樣的清單，加上 Amazon Timestream、Amazon OpenSearch、Amazon Redshift（透過 JDBC）以及 Amazon S3（透過 Flink S3 sink）。SAA-C03 的典型架構模式為：

KDS -> Managed Service for Apache Flink -> KDS -> Firehose -> S3（Parquet）

或

MSK -> Managed Service for Apache Flink -> OpenSearch（即時儀表板）

狀態、checkpoint 與擴展

Flink 應用程式是有狀態的——視窗聚合、join、模式偵測。Managed Service for Apache Flink 會自動將狀態 checkpoint 到服務管理的後端，並在故障時自動還原。擴展單位為 Kinesis Processing Unit（KPU），每個 KPU 提供 1 vCPU 與 4 GB 記憶體；平行度依 CPU 負載在 MinParallelism 與 MaxParallelism 之間自動調整。

Amazon MSK — 受管 Apache Kafka

Amazon MSK 是完全受管的 Apache Kafka 服務，提供兩種部署模式。

MSK provisioned

你選擇 broker 實例類型（kafka.m7g.large、kafka.m5.4xlarge 等）、每個可用區的 broker 數量（兩個或三個），以及每個 broker 的 EBS 儲存大小。AWS 負責執行 broker、ZooKeeper（或 Kafka 3.5+ 的 KRaft）、修補和故障復原。你需要自行管理：

• Topic 與 partition — Kafka 等同於 shard 的概念。
• 複製因子 — 通常跨三個可用區設為三。
• 保留設定 — 按 topic 設定，依時間（retention.ms）或大小（retention.bytes）決定。
• ACL、SASL/SCRAM、IAM 驗證、TLS — 存取控制。

MSK Serverless

MSK Serverless 省去 broker 大小調整的工作。你建立叢集、建立 topic，按每 GB 擷取量、每 GB 儲存量以及 partition-hour 計費。AWS 自動擴展 partition 與吞吐量，預設每叢集最高 200 MiB/s 寫入。最適合流量無法預測的 Kafka 工作負載。

MSK Connect

MSK Connect 是受管的 Kafka Connect 服務。它在 MSK 或任何 Apache Kafka 叢集上以受管叢集的方式執行 Kafka Connect worker（來源或接收連接器）。常見連接器：

• 來源：Debezium CDC（從 MySQL/Postgres）、Amazon S3 來源、JDBC。
• 接收：Amazon S3 sink、Amazon OpenSearch sink、Snowflake、Redshift、MongoDB。

MSK Connect 自動擴展 worker 數量，按 worker-hour 計費。

決策樹 — 何時選擇 KDS vs Firehose vs MSK vs Flink

SAA-C03 考試幾乎總是以「架構師應該選擇哪個服務？」的方式呈現串流資料 Kinesis 題目。使用以下決策樹。

第一步 — 目的地是單一已知的接收端嗎？

• 若管線終止於 Amazon S3、Amazon Redshift、Amazon OpenSearch 或 Splunk，且不需要多 consumer fan-out 也不需要有狀態處理 → Amazon Data Firehose。零營運、最省力、小規模下成本最低。

第二步 — 多個獨立的 consumer 需要各自取得串流的副本嗎？

• 若是，且每個 consumer 可能以不同 offset 讀取、需要重播歷史資料，或需要專屬吞吐量 → Amazon Kinesis Data Streams（傳統模式或 enhanced fan-out）。Firehose 無法對多個任意 consumer 進行 fan-out。

第三步 — 團隊已在執行 Apache Kafka，或 payload 超過 1 MiB，或需要超過 365 天的保留？

• 若是 → Amazon MSK（流量可預測用 provisioned，流量突發用 MSK Serverless）。MSK Connect 處理 Debezium CDC 和 S3 sink 模式。

第四步 — 工作負載需要有狀態的視窗處理、join 或模式偵測嗎？

• 若是 → Amazon Managed Service for Apache Flink，通常串接在 KDS 或 MSK 的前方。

第五步 — 吞吐量無法預測，且團隊希望零容量規劃？

• KDS 優先選 on-demand 模式，Kafka 選 MSK Serverless，交付選 Firehose。三者均可自動擴展。

安全性 — 加密、VPC 與存取控制

每個串流資料 Kinesis 服務都支援相同的 AWS 安全性原語，但考試很愛測試它們之間的差異。

靜態加密

• KDS 使用 AWS KMS 伺服器端加密（SSE-KMS）；按串流啟用，key 可由客戶管理或 AWS 管理。Consumer 必須對該 key 擁有 kms:Decrypt 權限。
• Firehose 使用 KMS 加密傳輸中的緩衝；目的地的加密視目的地而定（S3 的 SSE-S3/SSE-KMS、Redshift 叢集加密、OpenSearch 網域加密）。
• MSK 使用 KMS 對 broker 的 EBS 磁碟區進行靜態加密。

傳輸中加密

• KDS、Firehose 和 MSK 均支援 TLS endpoint。
• MSK 額外支援叢集內 broker 對 broker 的 TLS（必須在建立叢集時啟用）。

VPC endpoint 與私有連線

• KDS 和 Firehose 具備界面型 VPC endpoint，讓私有 VPC 中的 producer 和 consumer 永遠不會通過公共網際網路。
• MSK 的設計本就完全在你的 VPC 內執行；broker 存在於客戶的 ENI 上。

IAM 與資源政策

• KDS 資源型政策允許跨帳號存取，無需角色假設（2023 年推出）。
• Firehose 存取透過 delivery stream ARN 上的 IAM 政策授予；Firehose 的 IAM 角色需要具備寫入目的地和讀取來源的權限。
• MSK IAM 驗證讓 Kafka 用戶端可用 SigV4 進行驗證，而不需要 SASL/SCRAM 或 TLS 雙向驗證。

效能與成本模式

KDS 效能限制速查表

• 每個 shard 寫入：1 MiB/s 或 1,000 筆記錄/秒。
• 每個 shard 傳統讀取：2 MiB/s、每秒 5 次 GetRecords，共享。
• 每個 shard EFO 讀取：每個 consumer 2 MiB/s，最多 20 個 consumer。
• 最大記錄大小：1 MiB。
• 保留：預設 24h，標準延伸 7d，長期 365d。
• On-demand 預設吞吐量：每條串流 200 MiB/s 寫入、400 MiB/s 讀取（可申請提高配額）。

Firehose 效能限制速查表

• Direct PUT 吞吐量：每帳號每區域起始為 1 MiB/s 或 1,000 筆記錄/秒（可申請提高配額）。
• 緩衝大小：1 至 128 MiB，預設 5 MiB。
• 緩衝時間：0 至 900 秒，預設 300 秒。
• 最大記錄大小：1 MiB。

MSK 效能調整旋鈕

• Broker 實例類型（kafka.m7g.large 至 kafka.m5.24xlarge）。
• 每個可用區的 broker 數量（每個可用區一至三個，共三個可用區）。
• 每個 broker 的 EBS 儲存（1 GB 至 16 TB，可選自動擴展）。
• 複製因子（通常跨三個可用區設為三）。
• 叢集內網路吞吐量決定 peer 複製的餘裕。

成本調整旋鈕

• KDS provisioned：shard-hour + PUT payload 單位 + 延伸保留 shard-hour + 長期保留 GB-month + EFO consumer-shard-hour + EFO 資料讀取 GB。
• KDS on-demand：每 GB 擷取 + 每 GB 讀取 + GB-month 保留。
• Firehose：每 GB 擷取（加上每 GB 格式轉換、每 GB dynamic partitioning、每 GB VPC 交付、每 GB S3 備份）。
• MSK provisioned：broker-hour + EBS GB-month + 資料傳輸 + 可選的 tiered storage GB-month。
• MSK Serverless：每 GB 擷取 + 每 GB 儲存 + partition-hour。

高可用性與災難復原模式

同區域彈性

• KDS 和 Firehose 預設為區域性、跨多可用區。無需任何設定。
• MSK 需要你在建立叢集時將 broker 分散至三個可用區；不建議使用單一可用區的 MSK 叢集。

跨區域複製

• KDS 跨區域：無原生鏡像功能。常見模式是使用 Lambda 或 Managed Service for Apache Flink 消費來源串流，並寫入目標區域的串流。
• Firehose 跨區域：對於 HTTP endpoint 和 S3，目的地可以位於另一個區域（需額外支付資料傳輸費用）。
• MSK 跨區域：使用 MSK Replicator（2023 年）在兩個跨區域的 MSK 叢集之間進行受管的 mirror-maker 式複製。

重播與回填

KDS 和 MSK 均支援依序號 / offset / 時間戳記進行 seek。Firehose 在批次交付至目的地後不支援重播——若需要重新處理，必須從原始來源重新擷取，或從 S3 備份儲存桶讀取。

SAA-C03 考試常見架構

點擊流到資料湖

Web 應用程式 -> KPL -> KDS -> Firehose（Parquet + dynamic partitioning）-> S3 -> Athena / QuickSight。 使用 KDS 進行重播，使用 Firehose 進行零營運交付，使用 Parquet 降低掃描成本，使用 dynamic partitioning 進行 Athena 分區修剪。

IoT 遙測搭配即時異常偵測

IoT 裝置 -> AWS IoT Core -> 規則至 KDS -> Managed Service for Apache Flink（視窗異常偵測）-> KDS 告警串流 -> Lambda -> SNS。 Flink 處理有狀態的工作階段化；KDS 保留七天的重播歷史。

日誌匯聚至 OpenSearch 與 S3

Amazon CloudWatch Logs 訂閱篩選器 -> Firehose -> （Lambda 轉換）-> OpenSearch + S3 備份。 單一目的地交付，不需要 fan-out，Firehose 勝出。

從 RDS 到資料湖的變更資料擷取

RDS MySQL -> MSK Connect 上的 Debezium -> MSK -> MSK Connect S3 sink -> S3 Iceberg 資料表。 Kafka 生態系是最自然的選擇；MSK Connect 直接託管 Debezium，無需自行管理 EC2。

多租戶串流平台

SaaS 客戶（多個 AWS 帳號）-> 跨帳號 KDS 資源政策 -> 共享帳號中的中央串流 -> Managed Service for Apache Flink 進行每租戶聚合 -> Firehose -> 透過 dynamic partitioning 建立每租戶 S3 前綴。

操作陷阱與考試陷阱

串流資料 Kinesis 與其他 AWS 訊息服務的快速比較

SAA-C03 會將串流資料 Kinesis 與 Amazon SQS、Amazon SNS 以及 Amazon EventBridge 混合出題。快速判斷規則：

• Amazon SQS — 點對點佇列，每則訊息只有一個 consumer，除 FIFO 佇列外無法保證順序，最長保留 14 天。
• Amazon SNS — 發布／訂閱 fan-out 至訂閱者，無保留，僅推送。
• Amazon EventBridge — 含 schema registry 的事件匯流排，支援內容型路由與 SaaS 合作夥伴事件；每條規則的吞吐量較低。
• Amazon Kinesis Data Streams — 有序可重播的日誌，多 consumer，高吞吐量，最長保留 365 天。
• Amazon MSK — 與 KDS 相同，但使用 Apache Kafka API 與 Kafka 生態系。
• Amazon Data Firehose — 受管交付，無 consumer。

若考題說「為下週新增的下游 consumer 重播七天的事件」，答案是串流資料 Kinesis（KDS 或 MSK），而非 SQS 或 SNS。

FAQ — SAA-C03 串流資料 Kinesis

Q1. 何時應選擇 Amazon Kinesis Data Streams on-demand 而非 provisioned 模式？

當流量無法預測、突發量超過基準線的 2 倍，或不想自行管理 resharding 時，選擇 on-demand。On-demand 按擷取的 GB 數與讀取的 GB 數計費；provisioned 則不論使用率如何，一律按 shard-hour 計費。對於每月穩定工作負載超過約 250 shard-hour 的情況，provisioned 通常每 GB 便宜 30-50%。對於新工作負載，一律先從 on-demand 開始，觀察一個月後，若基準線穩定再切換至 provisioned。 Source ↗

Q2. 傳統 Kinesis consumer 與 enhanced fan-out 有何差異？

傳統 consumer 共享每個 shard 的 2 MiB/s，透過每秒一次或更長間隔的 GetRecords 輪詢拉取，端對端延遲為 200 ms 至 1 秒。Enhanced fan-out 為每個 consumer 個別註冊，各自獲得每個 shard 的 2 MiB/s 專屬吞吐量，透過 HTTP/2 推送，延遲低於 200 ms，每條串流最多支援 20 個 consumer。EFO 每個 consumer-shard-hour 及每 GB 讀取量需額外付費，因此僅在需要隔離或低延遲時使用。 Source ↗

Q3. Amazon Data Firehose 能從單一 delivery stream 交付到多個目的地嗎？

不行。每個 Firehose delivery stream 只有一個主要目的地。可選的 S3 備份儲存桶是失敗情況下的備份桶，而非第二個目的地。若你需要將相同的資料同時送到 S3、OpenSearch 和 Splunk，有兩個方案：（a）建立三個各自帶有獨立來源的 Firehose delivery stream；或（b）在前方放一個 Kinesis Data Stream，再讓三個 Firehose delivery stream 從同一個 KDS 讀取。 Source ↗

Q4. 如何防止 Amazon Kinesis Data Streams 出現 hot shard？

將 partition key 設計為高基數——user_id、device_id、session_id、request_id。避免低基數的 key（國家代碼、狀態旗標、常數）。若天然的 key 存在偏斜，可在後面附加隨機 0-9 後綴來建立合成子 key，再於下游重新聚合。透過 CloudWatch 監控每個 shard 的 IncomingBytes 與 IncomingRecords，若某個 shard 持續超過 80% 使用率，就進行 reshard（分割 hot shard）或重新設計 key。記住：單純增加 shard 無法修復 hot key——雜湊結果仍然會落在同一個 shard 上。 Source ↗

Q5. 何時應選擇 Amazon MSK 而非 Amazon Kinesis Data Streams？

當（a）團隊已在使用 Apache Kafka 且希望直接移轉而無需重寫 producer 和 consumer；（b）需要 Kafka 原生工具如 Debezium、Kafka Streams、Schema Registry、ksqlDB；或（c）payload 大小超過 KDS 的 1 MiB 上限時，選擇 Amazon MSK。當團隊沒有 Kafka 專業背景、希望緊密整合 AWS Lambda 觸發器、IAM 原生驗證、KMS 加密，並且能接受 1 MiB 的記錄上限與 365 天的保留期間時，選擇 Amazon Kinesis Data Streams。MSK Serverless 免除 broker 大小調整的負擔，是最接近 KDS on-demand 的 Kafka 等效方案。 Source ↗

Q6. 能從 Amazon Data Firehose 重播舊記錄嗎？

不行。Firehose 是單向交付管線——批次一旦推送到目的地，Firehose 就不會再保留任何可重播的副本。S3 備份儲存桶（若已設定）只保留失敗的記錄。若重播是必要需求，請在前方加上 Amazon Kinesis Data Streams（保留 1 至 365 天），並以 Firehose 作為 consumer；重播時只需重設 KDS 的 consumer checkpoint 即可。 Source ↗

Q7. Amazon Kinesis Data Streams 的跨帳號存取如何運作？

有兩種方式。（a）在串流上設定資源型政策（2023 年推出），授予其他帳號的 principal 特定操作（SubscribeToShard、GetRecords、DescribeStream）——無需角色假設。（b）傳統的跨帳號 IAM 角色在擁有串流的帳號中建立，由 consumer 帳號透過 STS 假設。若串流以客戶管理的 KMS key 加密，KMS key 政策也必須授予 consumer 帳號 kms:Decrypt，否則即使 IAM 設定正確，讀取仍會在 KMS 層收到 AccessDenied 錯誤。 Source ↗

摘要 — SAA-C03 串流資料 Kinesis 速查表

• Amazon Kinesis Data Streams — 有序、可重播、多 consumer 的日誌。Shard、partition key、1 MiB 記錄、預設 24h / 最長 365d 保留。流量未知用 on-demand，穩定基準線用 provisioned。
• Amazon Data Firehose — 零營運交付至 S3、Redshift、OpenSearch、Splunk、HTTP。緩衝大小／時間、Lambda 轉換、dynamic partitioning、Parquet/ORC 轉換。單一目的地，無重播功能。
• Amazon Managed Service for Apache Flink — 無伺服器 Flink，用於有狀態串流處理、視窗、join、模式偵測。支援 Java/Scala/Python 或 Zeppelin Studio SQL，以 KPU 為單位擴展。
• Amazon MSK — 受管 Apache Kafka。有 Kafka 生態系需求的可預測工作負載用 provisioned；突發流量用 MSK Serverless；Debezium CDC 和 S3 sink 模式用 MSK Connect；跨區域鏡像用 MSK Replicator。
• Hot shard 靠更好的 partition key 修復，增加 shard 無效。
• Enhanced fan-out 為每個 consumer 提供每個 shard 的專屬 2 MiB/s，並以 HTTP/2 推送。
• Firehose 不是發布／訂閱系統 — 每個 delivery stream 只有一個目的地。
• KMS 跨帳號需要同時具備 IAM 授權與 KMS key 政策授權。
• 有重播需求意味著要用 KDS 或 MSK，絕不能只用 Firehose。

熟記這份串流資料 Kinesis 攻略，你就能在每一道 SAA-C03 串流題目第一次閱讀時就選出正確答案——這正是剛好通過與輕鬆拿到 80 分以上的差距所在。