AWS サービスによるログ分析

ログは、障害の原因の調査、セキュリティの監査、利用状況の把握に欠かせないデータです。AWS には、ログの置き場所と量、調べたい速さに応じて、、、、といった分析の道具がそろっています。

DEA では、監査用のログの抽出、・フローログ・アクセスログなどの分析、そしてビッグデータのアプリケーションのログを含む大量のログを、どのサービスで分析するかの選び分けが問われます。

Point

VPC Flow Logs (VPC フローログ) は、VPC のネットワークインターフェイスを通る通信の記録 (送信元、送信先、ポート、許可か拒否か) です。
S3 server access logs (S3 サーバーアクセスログ) は、S3 バケットへのリクエストの記録です。
Logs Insights は CloudWatch Logs のログにクエリを実行する機能です。
和訳
- Audit: 監査
- Weblio英和辞書「audit」

概要

ログの分析の道具は、「ログがどこにあるか」と「何をしたいか」で選びます。

道具	ログの場所	得意なこと
	Logs	集めたログをその場でクエリして、障害を素早く調べる
		大量のログにでアドホックに問い合わせる。長期間の監査
	OpenSearch のインデックス	全文検索、ほぼリアルタイムのダッシュボード、継続的なログの監視
	S3 /	非常に大量のログをなどで加工・集計する

主要技術

①CloudWatch Logs Insights ⚠️ 頻出

は、 Logs のロググループに対して、クエリ言語で検索と集計を行う機能です。サーバーの用意は不要で、スキャンしたログの量で課金されます。

fields @timestamp, @message
| filter @message like /ERROR/
| stats count(*) as errors by bin(5m)
| sort errors desc

特徴	内容
クエリ言語	Logs Insights のクエリ言語に加え、の PPL やでも書けます。
自動で見つける項目	やフローログなどのログでは、項目を自動で認識します。のログは項目ごとに扱えます。
複数のロググループ	複数のロググループ (他アカウントのものも、の設定で) をまとめてクエリできます。
結果の活用	結果をダッシュボードに追加したり、クエリを保存して再利用したりできます。

Lambda のエラーの件数を時間ごとに数える、特定のリクエスト ID の処理を追う、といった運用中の調査に向きます。何年分ものログを安く保管して分析するなら、との方が向きます。

②Athena による CloudTrail・VPC フローログ・S3 アクセスログの分析 ⚠️ 頻出

に保存されたログは、でテーブルを定義してで分析できます。

ログ	Athena での扱い	調べる例
	証跡が S3 に出力したのログにテーブルを作ります。を使うと、日付やのパーティションの登録が不要になります	特定のユーザーが特定の期間に呼んだ、削除の操作、アクセスの拒否 (AccessDenied)
フローログ	S3 への出力形式にと Hive 互換のプレフィックス (時間ごとのパーティション) を選ぶと、スキャン量を減らせます	拒否 (REJECT) された通信、特定のアドレスとの通信量
S3 サーバーアクセスログ	アクセスログ用のに出力されたログにテーブルを作ります	どのオブジェクトに誰がアクセスしたか、エラーの多い要求
/ のログ	S3 のアクセスログにテーブルを作ります	応答の遅い URL、エラーの割合

S3 のオブジェクトへの操作の記録には、S3 サーバーアクセスログと CloudTrail のデータイベントの2つがあります。AWS は監査には CloudTrail を推奨しています。データイベントはプレフィックス単位で対象を絞れ、ログファイルの整合性の検証ができ、約5分ごとに配信されます。サーバーアクセスログは S3 のバケットへの配信なら保存料金だけで使えますが、配信は数時間以内のベストエフォートで、整合性の検証の仕組みはありません。一方、ライフサイクルによる移行や期限切れの削除、認証に失敗した要求は、サーバーアクセスログには記録されますが、CloudTrail には記録されません。

Athena のコンソールには、CloudTrail のログからテーブルを作る機能があります。ログは量が多くなるため、日付のパーティションで絞り込んでクエリするのが基本です。

③監査用のログの抽出

監査のためにログを抽出するときは、次の点を押さえます。

観点	内容
抽出の条件	期間、ユーザー (userIdentity)、イベント名 (eventName)、送信元のアドレス、結果 (エラーコード) で絞ります。
保存	抽出した結果をやでに保存し、監査の担当者に渡します。
改ざんの防止	元のログは、のログファイルの整合性の検証 (ダイジェストファイル) や S3 Object Lock で守ります (#74)。
アクセスの制限	監査用のログのとのワークグループへのアクセスを、監査の担当者に限ります。
長期の保管	ライフサイクルで安いへ移し、保持の要件を満たします。

CloudTrail のログをで集中管理する手段として CloudTrail Lake がありましたが、CloudTrail Lake は 2026 年 5 月 31 日に新規の利用者の受け付けを終えました (既存の利用者は使い続けられます)。新しく作る構成では、証跡のログを S3 に出力して Athena で分析するか、 Logs に送ってで調べる方法を選びます。

④Amazon OpenSearch Service によるログ分析

は、ログを取り込んでインデックスにし、全文検索と OpenSearch Dashboards による可視化を行います。

特徴	内容
取り込み	Logs の、、OpenSearch Ingestion (マネージドのパイプライン) で送ります。
検索	エラーメッセージのキーワードや、任意の項目で素早く検索できます。
可視化と監視	OpenSearch Dashboards で、ほぼリアルタイムのダッシュボードやアラートを作ります。
コストの調整	古いログはやコールドストレージに移して保存のコストを下げます (#44)。

⑤Amazon EMR による大量のログの処理

ビッグデータのアプリケーションのログ (Web サーバーのアクセスログ、クリックストリーム、のイベントログなど) が非常に多い場合は、で Spark を使って加工・集計します。

向く場面	内容
複雑な加工	ログの解析 (パース)、セッションごとのまとめ、複数のログの結合
定期的な大規模の集計	毎日、数 TB のログを集計して、結果をでに書きます。結果はやで分析します。
コストを抑えた一時的な処理	処理のときだけクラスターを起動し、終わったら終了します。タスクノードにスポットを使います。EMR Serverless も選べます。

単純な検索や集計で済むなら、まず Athena で足りるかを考えます。

試験対策

①判断マトリクス

問題文のキーワード	選ぶもの	理由
Logs のログを、その場で検索・集計		集めたログに直接クエリできます。
ののログをで分析	()	サーバーなしで SQL を実行できます。
フローログを安く速く分析	+ 時間ごとのパーティションで S3 に出力し、Athena	スキャン量が減ります。
S3 のオブジェクトへのアクセスを調べる	S3 サーバーアクセスログ + Athena (または CloudTrail のデータイベント)	要求ごとの記録を分析します。
ログの全文検索とリアルタイムのダッシュボード		インデックスと Dashboards で可視化します。
数 TB の Web のログを毎日加工・集計	()	大量のデータの複雑な加工に向きます。
監査の担当者に、期間とユーザーで絞ったログを渡す	Athena で抽出し、 / で S3 に保存	抽出結果を残せます。
CloudTrail のイベントを SQL で集中管理したい (新規)	S3 の証跡 + Athena、または CloudWatch Logs + Logs Insights	CloudTrail Lake は新規の受け付けを終えています。

②よくある誤答

何年分ものログを、のために Logs に置き続けること。長期の保管と分析はとの方が安くなります。
単純なの集計のためにのクラスターを立てること。まず Athena を考えます。
フローログを CSV (テキスト) のまま、パーティションなしで分析すること。とパーティションでスキャン量を減らします。