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

会員登録/ログイン

A. 各店舗のログを Amazon OpenSearch Service クラスターへ送信し、AWS Lambda でログを正規化したうえで Amazon S3 へエクスポートする

正規化のためだけに Amazon OpenSearch Service のクラスターを常時起動することになり、ノードの費用が固定で発生する。
OpenSearch は検索・可視化の基盤であって、S3 へ渡す前段の変換パイプラインとして置くのは役割が過剰。
さらに Lambda での正規化と S3 へのエクスポート処理も別途作り込む必要があり、最も低コストという判断軸から最も遠い。

B. AWS Glue のジョブを定期実行し、Amazon S3 に格納された生ログを読み込んで正規化したうえで別の S3 プレフィックスに書き戻す

生ログをいったん S3 に置き、AWS Glue のジョブで読み直して別プレフィックスへ書き戻す構成。動作はするが、設問の「S3 に書き込む前に標準化する」という要件に反し、生ログと正規化済みログの二重保管でストレージ費用も増える。
Glue ジョブは DPU 時間で課金されるため、ストリーミング取り込み時に Lambda で変換する方式よりコスト面で不利。
定期実行のため、取り込みから分析可能になるまでの遅延も生じる。

C. 各店舗のログを Amazon QuickSight に送信し、SPICE エンジンで正規化してそのまま QuickSight 上で分析する

Amazon QuickSight は BI（可視化）サービスであり、ログの取り込み口にも ETL 基盤にもならない。
SPICE はダッシュボード高速化のためのインメモリの計算エンジンで、異なる形式のログを共通フォーマットへ正規化する機能ではない。
そもそも要件である「S3 バケットへの標準化済みログの格納」も「Athena での分析」も満たせない。

正解

D. 各店舗サーバーに Amazon Kinesis Agent を導入して Amazon Data Firehose の配信ストリームにログをアップロードし、AWS Lambda 関数でログを正規化したうえで Amazon S3 へロードする

各店舗サーバーの Kinesis Agent がログを Amazon Data Firehose へ送り、Firehose が配信前に AWS Lambda を呼び出してレコードを共通フォーマットへ変換し、そのまま Amazon S3 へロードする。
クラスターやサーバーを持たず、実際に流れたデータ量と Lambda の実行分だけの課金で済むため最も低コスト。
S3 に着地した時点で形式が統一されているので、Athena で全店舗分をまとめてクエリできるという後続要件にも合致する、定番のログ集約パターン。

構成図

各店舗の POS レジ（形式バラバラ・Kinesis Agent）
   │ ログを送信
   ▼
Amazon Data Firehose ⇄ AWS Lambda（共通フォーマットへ正規化）
   │ 変換後レコードを配信
   ▼
Amazon S3（標準化済みログ） ──▶ Amazon Athena で分析

正解への思考ルート

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

要件	判断ポイント
店舗ごとにログの形式が異なる（共通フォーマットへ標準化が必要）	取り込みの途中で変換できるのは Firehose のレコード変換（Lambda）。BI ツールは正規化の役割を持たない →選択肢（C）を消す・選択肢（D）が正解
S3 バケットに書き込む「前に」標準化する	生ログを S3 に置いてから直す方式は要件の順序に反し、二重保管でストレージ費用も増える →選択肢（B）を消す
最も低コストで実現する（判断軸）	常時起動のクラスターを持たせない。従量課金のマネージド配信＋関数実行で完結させる →選択肢（A）を消す・選択肢（D）が正解
後から Amazon Athena でまとめて分析する	S3 上のデータが同一形式であれば Athena で横断クエリできる。取り込み時に整形しておくのが素直 →選択肢（D）が正解

ひっかけポイント

• 選択肢 B（Glue で後から正規化）は技術的には実現できるのが罠。設問は「S3 に書き込む前に標準化」と順序を指定しており、さらに判断軸が最も低コストである点で外れる
• 「OpenSearch Service に送る」は検索できて便利そうに見えるが、ノードが常時課金される。低コスト要件の設問でクラスターを立てる選択肢はまず疑う
• QuickSight の SPICE は可視化を高速化するインメモリエンジンであって、ETL・正規化の仕組みではない。名前の響きで選ばない
• Firehose の「変換」は Lambda を呼んでレコードを書き換える機能で、別途パイプラインを組む必要はない。ここを知らないと選択肢 B に流れる

出題バリエーション

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

問題文がこう変わったら	正解はこう変わる
「ログを JSON から Parquet に変換して Athena のスキャン量を減らしたい」	Firehose のデータ形式変換（AWS Glue データカタログ連携）を有効化する、が加わる。
「変換だけでなく時間窓での集計もしたい」	Amazon Managed Service for Apache Flink を挟む構成が正解軸に。
「店舗サーバーにエージェントを入れられない（既存の CloudWatch Logs に出ている）」	CloudWatch Logs のサブスクリプションフィルター → Firehose でつなぐ形に変わる。
「ログを全文検索・可視化して障害調査に使いたい」	Amazon OpenSearch Service（Firehose の配信先に指定）が一転して正解になり得る。
「取り込みは不要で、すでに S3 にある大量の生ログを整形したい」	AWS Glue の ETL ジョブが正解軸に（選択肢 B の構成が正しくなる）。

関連サービスの解説

Amazon Simple Storage Service (Amazon S3)
AWS Lambda
Amazon Data Firehose

リファレンス

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

知識項目	公式ドキュメント
Amazon Data Firehose の配信前のデータ変換と S3 への配信	Amazon Data Firehose とは何ですか?