SAA（Solutions Architect Associate）攻略・ 2026-07-23

SAA Kinesis 設計パターン（KDS/KDF/KDA）｜ストリーミングデータ処理の選択基準を体系化

AWS SAA-C03 で Kinesis は「データ処理の設計パターン」として毎回出題される。KDS（リアルタイム複数処理）・KDF（S3/Redshift への自動配信）・KDA（SQL/Flink 分析）の3サービスを「リアルタイム性・配信先・処理複雑度」の3軸で整理し、KDS のみ・KDF のみ・KDS+KDF・KDS+KDA+KDF の4設計パターンを要件キーワードから即断できる粒度まで分解する。結論は「秒単位かつ複数処理→KDS、配信だけ→KDF、分析も必要→KDA を追加」。

#AWS #SAA #SAA-C03 #Solutions Architect #Kinesis #Kinesis Data Streams #Kinesis Data Firehose #Kinesis Data Analytics #ストリーミング #リアルタイム処理 #試験対策 #AWS認定資格

Kinesis 問題を「より高性能なサービスを選ぶ問題」と勘違いすると、過剰設計の選択肢を毎回引いてしまう。 AWS SAA-C03 でストリーミングデータ処理は、配点26%の「高パフォーマンスなアーキテクチャ」と「弾力性のあるアーキテクチャ」双方に絡むため、ほぼ毎回シナリオ形式で登場する。攻略の核心は、KDS・KDF・KDA の3サービスを**「リアルタイム性 × データの行き先 × 処理の複雑さ」の3軸で整理し、要件文にある「秒単位のリアルタイム」「S3/Redshift に自動配信」「SQL で分析」「複数アプリが同時消費」**といったキーワードから、必要十分なパターンを一意に決めることだ。本記事では4つの設計パターンを、どの AWS サービスを使うか・障害時どうなるか・試験ひっかけのポイントはどこか、まで分解する。読み終えれば Kinesis シナリオ問題をパターンマッチで解けるようになる。

※ 本記事はアフィリエイト広告（Amazon アソシエイト等）を含みます

📑 目次

結論：Kinesis 問題は「リアルタイム性 × 配信先 × 処理複雑度」で1本に絞る
KDS の基本構造（シャード・プロデューサー・コンシューマー）
KDF の基本構造（バッファリング・変換・自動配信）
KDA の基本構造（SQL/Flink でのリアルタイム分析）
3サービス比較表（設計判断の3軸）
パターン1：KDS のみ（リアルタイム・カスタム処理）
パターン2：KDF のみ（S3/Redshift への簡易配信）
パターン3：KDS + KDF（リアルタイム処理 + 永続化の組み合わせ）
パターン4：KDS + KDA + KDF（分析→配信まで一気通貫）
要件キーワード早見表
頻出ひっかけパターンと正しい打ち手
次のアクションチェックリスト
関連記事
関連サイト

1. 結論：Kinesis 問題は「リアルタイム性 × 配信先 × 処理複雑度」で1本に絞る

SAA-C03 の Kinesis 問題を最短で解く骨格は、**「要件文から3つの軸を読み取り、4つの設計パターンのどれかを1本に絞る」**ことだ。

軸	問いかけ	判断のキーワード
リアルタイム性	秒単位か？分〜時間単位でよいか？	「秒単位」「ミリ秒」→ KDS 必須
データの行き先	S3/Redshift/ES か？カスタムアプリか？	「S3 に保存」「Redshift にロード」→ KDF
処理の複雑さ	SQL 分析・ウィンドウ集計が必要か？	「リアルタイム分析」「異常検知」→ KDA

4パターンは「KDS のみ → KDF のみ → KDS+KDF → KDS+KDA+KDF」という複雑さのグラデーションを作る。要件に対して**「必要十分・シンプル最小」**のパターンを選ぶのが正解であり、過剰なサービスを追加すると「コスト最適でない」として誤答になる。

2. KDS の基本構造（シャード・プロデューサー・コンシューマー）

Amazon Kinesis Data Streams（KDS）は、プロデューサーが送ったレコードをシャードという並列処理単位で受け取り、複数のコンシューマーが同時・独立に読み取れるリアルタイム基盤だ。

シャード：1シャードあたり PUT 1MB/秒・1,000件/秒、GET 2MB/秒。スループットはシャード数で水平スケール。
プロデューサー：EC2・Lambda・SDK・Kinesis Agent・CloudWatch ログなどが送信。
コンシューマー：Lambda（イベントソースマッピング）・KDF・KDA・EC2 上のカスタムアプリが並列消費。
データ保持期間：デフォルト24時間、最大365日。データを再読み込みできることが最大の特徴。
オンデマンド容量モード（2022年〜）：シャード数を手動管理せず自動スケール。SAA では「シャード管理が不要」という要件で登場する。

3. KDF の基本構造（バッファリング・変換・自動配信）

Amazon Data Firehose（旧称 Kinesis Data Firehose、KDF）は、ストリームデータをバッファリングしてから指定した配信先に自動で届けるマネージドサービスだ。

配信先（Destinations）：S3・Amazon Redshift・Amazon OpenSearch Service・HTTP エンドポイント（Datadog・Splunk 等）。
バッファリング：サイズ（1MB〜128MB）または時間（60秒〜900秒）でバッファを切り、まとめて配信。完全なリアルタイムではない（最短でも数十秒〜数分のレイテンシー）。
Lambda による変換：配信前に Lambda を呼び出してデータの整形・フォーマット変換（CSV→Parquet 等）が可能。
管理コスト最小：シャード管理不要・スケーリング自動。「操作が簡単」「フルマネージド」という要件で登場。

4. KDA の基本構造（SQL/Flink でのリアルタイム分析）

Amazon Kinesis Data Analytics for Apache Flink（KDA）は、KDS または KDF から流れ込むデータを SQL または Java/Python（Apache Flink）でリアルタイム分析するマネージドサービスだ。

入力ソース：KDS・KDF・S3 参照テーブル（ルックアップ用）。
処理モデル：タンブリングウィンドウ・スライディングウィンドウ・累積集計など、時系列分析に特化。
出力先：KDS・KDF・Lambda・S3。KDA 単独では配信先にはならず、KDF と組み合わせて最終的に S3/Redshift へ届けるパターンが多い。
ユースケース：リアルタイム異常検知・直近5分間の平均値監視・クリックストリームのリアルタイム集計。

5. 3サービス比較表（設計判断の3軸）

KDS / KDF / KDA 比較表（設計判断の3軸）

評価項目	KDS	KDF	KDA
正式名称	Kinesis Data Streams	Amazon Data Firehose	Kinesis Data Analytics for Apache Flink
リアルタイム性	◎ ミリ秒〜秒単位	△ 数十秒〜数分（バッファリングあり）	◎ 秒単位（分析レイヤー）
配信先	コンシューマーが任意に処理	S3/Redshift/OpenSearch/HTTP	KDS・KDF（単独では配信不可）
複数コンシューマー	◎ 複数が同時消費可能	✕ 1配信先のみ	— 分析処理専用
データ再読み込み	◎ 保持期間内なら可能	✕ 不可	— ソースは KDS/KDF
管理コスト	△ シャード管理が必要（オンデマンドモードで軽減）	◎ フルマネージド	◎ フルマネージド
主なユースケース	複数アプリが並列消費・再処理が必要	S3/Redshiftへの配信パイプライン	リアルタイム異常検知・ウィンドウ集計

3サービスは「リアルタイム性・配信先・処理複雑度」で役割が明確に分かれる。要件に対して必要十分な構成を選ぶことが SAA の正解法則。

6. パターン1：KDS のみ（リアルタイム・カスタム処理）

要件のキーワード

「複数のアプリケーションが同じデータストリームを同時に処理したい」
「処理後にデータを再読み込みする可能性がある」
「秒単位のリアルタイムでカスタムロジックを適用したい」

アーキテクチャ

プロデューサー（EC2 / IoT / ClickStream）
   ↓ PUT
KDS（シャード × N）
   ├─ Lambda（リアルタイム変換・アラート送信）
   ├─ EC2 上のカスタムアプリ（集計・ストア）
   └─ KDA（ウィンドウ分析）

試験での正解条件

「複数のコンシューマーが独立して処理」「データをあとで再読み込み」→ KDS 単体で OK。
Lambda を KDS のコンシューマーとして設定すると、バッチサイズ・最大待機秒数を調整できる（イベントソースマッピング）。

7. パターン2：KDF のみ（S3/Redshift への簡易配信）

要件のキーワード

「ストリームデータをS3 に自動保存したい（分析は後で Athena 等で実施）」
「Redshift にリアルタイムでロードしたい（数分のラグは許容）」
「フルマネージドで運用負荷を最小化したい」

アーキテクチャ

プロデューサー（CloudWatch Logs / IoT）
   ↓
KDF（バッファリング60〜900秒）
   ├─ Lambda 変換（オプション：CSV→Parquet など）
   └─ S3 / Redshift / OpenSearch

試験での正解条件

「シャード管理不要」「運用オーバーヘッドなし」→ KDF が最適。
「完全なリアルタイム処理は不要」という条件が必ず入っている。

8. パターン3：KDS + KDF（リアルタイム処理 + 永続化の組み合わせ）

要件のキーワード

「リアルタイム処理（Lambda）と S3 への永続化を同時に実現したい」
「同じデータストリームをLambda でアラート処理しながら S3 にもアーカイブしたい」
「データを再処理できる状態で保持しつつ、S3 にも流したい」

アーキテクチャ

プロデューサー
   ↓
KDS（シャード × N、データ保持24h〜365d）
   ├─ Lambda コンシューマー（リアルタイム処理・DynamoDB への書き込みなど）
   └─ KDF コンシューマー（バッファリング → S3 / Redshift）

試験での正解条件

「2つの独立した処理経路が必要」→ KDS が両コンシューマーを並列で捌く。
「データを再処理したい（エラー時など）」→ KDS の保持期間があるから可能。KDF だけでは再処理不可。

9. パターン4：KDS + KDA + KDF（分析→配信まで一気通貫）

要件のキーワード

「ストリームデータをリアルタイムで SQL 分析し、異常値を検知したい」
「ウィンドウ集計（直近5分の平均など）を行いながら結果を S3 に保存したい」
「Apache Flink を使ったストリーム分析パイプラインを構築したい」

アーキテクチャ

プロデューサー
   ↓
KDS（入力ストリーム）
   ↓
KDA for Apache Flink
  （SQL / Java で分析・ウィンドウ集計・異常検知）
   ↓ 出力ストリーム
KDF
   ↓
S3 / Redshift / OpenSearch（分析結果の保存）

試験での正解条件

「リアルタイム分析＋S3 への結果保存」→ KDS+KDA+KDF の3段構成が正解。
「SQL またはコードで集計ロジックを定義したい」→ KDA 固有の要件。Lambda では複雑なウィンドウ集計が難しい。

10. 要件キーワード早見表

要件文のキーワード	正解パターン	理由
「秒単位のリアルタイム処理」	KDS（+ Lambda）	KDF はバッファリングがあり秒単位に対応不可
「複数アプリが同時に同じデータを処理」	KDS	KDF は1配信先のみ
「データを再処理・再読み込みしたい」	KDS	KDF はワンタイム配信（再読み込み不可）
「S3 に自動保存・Redshift に自動ロード」	KDF	フルマネージドで自動配信するのが KDF の役割
「シャード管理不要・運用オーバーヘッド最小」	KDF	KDF はシャード概念なし・フルマネージド
「リアルタイムで SQL 分析・ウィンドウ集計」	KDA	KDS+KDA（+KDF で配信）
「異常検知をリアルタイムで行い S3 に保存」	KDS + KDA + KDF	分析(KDA) → 配信(KDF) の3段
「CloudWatch Logs を S3 に流したい」	KDF	Logs サブスクリプションフィルタ → KDF 直接
「IoT デバイスデータをリアルタイム処理＋蓄積」	KDS + KDF	並列コンシューマー構成

11. 頻出ひっかけパターンと正しい打ち手

ひっかけ1：「リアルタイムに S3 に保存したい」→ KDF を選ぶと落とし穴

KDF にはバッファリング（最短60秒）があるため、純粋な秒単位リアルタイムではない。問題文に「ほぼリアルタイム（near real-time）」「数分のラグは許容」とあれば KDF でOK。「秒単位」「ミリ秒」なら KDS + Lambda が正解。

ひっかけ2：「KDF から Redshift に直接ロードできる」は本当だが、落とし穴もある

KDF → Redshift は「S3 経由でのロード」を内部で行っているため、S3 バケットが必要だ。Redshift のロード遅延があることも覚えておこう。「KDF → Redshift に即座に反映」という要件は誤答を引く。

ひっかけ3：「KDA 廃止では？」という混乱

Kinesis Data Analytics for SQL（旧版）は2023年以降新規作成不可。現在のサービスは Kinesis Data Analytics for Apache Flink（MSF：Managed Service for Apache Flink）だ。SAA 問題では「Kinesis Data Analytics」の名称で出てくる場合が多い。試験で「SQL でストリーム分析」とあれば KDA（MSF）を選べばよい。

ひっかけ4：「SQS と KDS の使い分け」

比較軸	KDS	SQS
メッセージ順序	シャード内で保証	FIFO キューで保証
複数コンシューマー	◎ 同一データを複数が消費可能	△ 1つのコンシューマーがメッセージを取得したら他は受け取れない
データ再読み込み	◎ 保持期間内なら何度でも	✕ 消費済みメッセージは削除
ユースケース	ストリーム分析・複数処理経路	タスクキュー・マイクロサービス連携

「複数のアプリが同じメッセージを読む」→ KDS（または SNS）が正解。SQS は消費したら消える。

12. 次のアクションチェックリスト

KDS / KDF / KDA の3サービスを「リアルタイム性・配信先・処理複雑度」の3軸で即答できるか確認
「秒単位かつ複数処理 → KDS」「S3/Redshift 配信 → KDF」「SQL 分析 → KDA」を暗唱できるか
KDS の「シャード」「プロデューサー/コンシューマー」「データ保持期間」の意味を説明できるか
KDF の「バッファリング」「Lambda 変換」「配信先4種」を覚えたか
KDS + KDF の「並列コンシューマー構成」を図で描けるか
SQS vs KDS の「複数コンシューマー」比較を2文で説明できるか
模擬問題で Kinesis シナリオを3問以上解いて正答確認

📑 目次

1. 結論：Kinesis 問題は「リアルタイム性 × 配信先 × 処理複雑度」で1本に絞る

2. KDS の基本構造（シャード・プロデューサー・コンシューマー）

3. KDF の基本構造（バッファリング・変換・自動配信）

4. KDA の基本構造（SQL/Flink でのリアルタイム分析）

5. 3サービス比較表（設計判断の3軸）

6. パターン1：KDS のみ（リアルタイム・カスタム処理）

要件のキーワード

アーキテクチャ

試験での正解条件

7. パターン2：KDF のみ（S3/Redshift への簡易配信）

要件のキーワード

アーキテクチャ

試験での正解条件

8. パターン3：KDS + KDF（リアルタイム処理 + 永続化の組み合わせ）

要件のキーワード

アーキテクチャ

試験での正解条件

9. パターン4：KDS + KDA + KDF（分析→配信まで一気通貫）

要件のキーワード

アーキテクチャ

試験での正解条件

10. 要件キーワード早見表

11. 頻出ひっかけパターンと正しい打ち手

ひっかけ1：「リアルタイムに S3 に保存したい」→ KDF を選ぶと落とし穴

ひっかけ2：「KDF から Redshift に直接ロードできる」は本当だが、落とし穴もある

ひっかけ3：「KDA 廃止では？」という混乱

ひっかけ4：「SQS と KDS の使い分け」

12. 次のアクション チェックリスト

13. 関連記事

14. 関連サイト

12. 次のアクションチェックリスト