AWS認定資格 WEB問題集＆徹底解説

会員登録/ログイン

A. 課金イベントデータを Amazon Kinesis Data Streams を使って直接 Amazon S3 に送り、成果報酬計算に利用する。さらに別の Amazon Data Firehose 配信ストリームを作成し、Amazon Redshift にもデータを送信する。

Amazon Kinesis Data Streams はデータを保持するだけのストリームであり、S3 へ「直接」書き出す機能は持たない。
S3 に落とすには Lambda や KCL アプリケーションなどのコンシューマーを自分で作って運用する必要があり、シャード数の管理（オンデマンドを使わない場合）も付いて回る。
「直接 Amazon S3 に送り」という記述の時点で誤りであり、運用の手間も選択肢 C より大きい。

B. 課金イベントデータを AWS Glue のジョブでバッチとして Amazon S3 にエクスポートし、成果報酬計算に利用する。さらに別の Amazon Data Firehose 配信ストリームを作成し、Amazon Redshift にもデータを送信する。

AWS Glue のジョブはバッチ指向の ETL であり、EC2 上のアプリが発行するイベントをそのまま受け取る入口にはならない。
スケジュール実行が前提のため「ほぼリアルタイムに S3 へ配信」という要件を満たせない。
ジョブのスクリプト作成・実行間隔の調整・失敗時のリカバリも必要で、運用の手間も増える。

正解

C. 課金イベントデータを Amazon Data Firehose を使って Amazon S3 に送り、成果報酬計算に利用する。さらに別の Amazon Data Firehose 配信ストリームを作成し、Amazon Redshift にもデータを送信する。

Amazon Data Firehose は、受け取ったストリーミングデータをバッファリングして S3・Redshift・OpenSearch などへ自動配信するフルマネージドサービスで、コンシューマーの実装もシャード管理も不要。
S3 向けと Redshift 向けにそれぞれ配信ストリームを作れば、同じ課金イベントを 2 系統に流す構成が設定だけで完成する（Redshift 配信も内部で S3 経由の COPY を Firehose が実行してくれる）。
バッファ間隔・サイズの設定でほぼリアルタイムの配信ができ、要件をすべて満たす運用負荷最小の解。

D. 課金イベントデータを Amazon Managed Service for Apache Flink を使って Amazon S3 に送り、成果報酬計算に利用する。さらに別の Amazon Data Firehose 配信ストリームを作成し、Amazon Redshift にもデータを送信する。

Amazon Managed Service for Apache Flink（旧 Amazon Kinesis Data Analytics）は、ストリームに対して集計や変換を行うストリーム処理エンジンであり、単純な「受けて S3 に置く」用途のために置くサービスではない。
入力には Kinesis Data Streams や Amazon MSK などのソースが別途必要で、EC2 のアプリから直接受け取る構成にはならない。
Flink アプリケーションのコード・並列度・チェックポイントの管理が発生するため、運用の手間は Firehose 単体より明確に大きい。

構成図

Amazon EC2 Auto Scaling グループ（課金イベント）
   │ PutRecord
   ├─▶ Amazon Data Firehose 配信ストリーム 1 ──▶ Amazon S3（成果報酬計算）
   └─▶ Amazon Data Firehose 配信ストリーム 2 ──▶ Amazon Redshift（行動分析）

正解への思考ルート

問題文から要件を抽出し、選択肢の適否を判断するのがポイントです。

要件	判断ポイント
EC2 Auto Scaling グループのアプリからイベントを収集する	アプリから直接投入でき、配信先まで面倒を見るのは Amazon Data Firehose。バッチ ETL の Glue は入口にならない →選択肢（B）を消す
ほぼリアルタイムに Amazon S3 へ配信する	Kinesis Data Streams から S3 への直接配信はできない（コンシューマーの自作が必要）。Glue のバッチも準リアルタイムにならない →選択肢（A・B）を消す
同じデータを Amazon Redshift にも投入する	Firehose は配信先に Redshift を指定できる（内部で S3 経由の COPY を実行）。用途別に配信ストリームを 2 本作ればよい →選択肢（C）が正解
運用の手間が最も少ないこと（判断軸）	コンシューマーや Flink アプリのコードを書いた時点で負け。マネージドな配信で完結する構成を選ぶ →選択肢（A・D）を消す・選択肢（C）が正解

ひっかけポイント

• 「Kinesis Data Streams を使って直接 Amazon S3 に送り」がひっかけ。Data Streams は保持するだけで、S3 へ書き出すのは自作のコンシューマーか Firehose の役目
• どの選択肢も後半の「別の配信ストリームで Redshift にも送信する」は共通。違いは前半の S3 への入口だけなので、そこだけを比較すれば速く解ける
• 「Managed Service for Apache Flink（旧 Kinesis Data Analytics）」は変換・集計が必要なときのサービス。加工要件が無いのに挟むと運用負荷が増えるだけ
• AWS Glue は名前の印象と違いバッチ ETL。「ほぼリアルタイム」と書かれた設問では真っ先に外す

出題バリエーション

同じ知識が本番では条件を変えて出題されます。

問題文がこう変わったら	正解はこう変わる
「イベントを集計・異常検知してから S3 に置きたい」	Managed Service for Apache Flink（またはFirehose の Lambda 変換）が正解軸に浮上する。
「複数のアプリが同じストリームを別々の速度で読みたい／再処理したい」	データを一定期間保持できる Kinesis Data Streams が正解軸に（Firehose は保持・再読み込みができない）。
「イベントを1 日 1 回まとめて S3 に置ければよい」	AWS Glue や EMR のバッチでも十分となり、コスト観点で正解が変わり得る。
「レコードの形式を JSON から Parquet に変換して S3 に置きたい」	Firehose のデータ形式変換（Glue データカタログ連携）を有効化する、が加わる。
「配信先が Amazon OpenSearch Service やサードパーティ SaaS」	同じく Firehose の配信先設定を変えるだけで対応できる（構成の型は同じ）。

関連サービスの解説

Amazon EC2 Auto Scaling
Amazon Kinesis
Amazon Redshift
Amazon Simple Storage Service (Amazon S3)

リファレンス

この問題を解くために必要な知識を扱う公式ドキュメントです。

知識項目	公式ドキュメント
Amazon Data Firehose の S3 / Redshift への配信（Redshift は COPY 実行）	Amazon Data Firehose とは何ですか?