CloudWatch Logs Insights難易度 標準無料
本番障害の一次対応中、SysOps管理者は直近24時間分のアプリケーションログ（複数のロググループにまたがる）から、特定のリクエストIDを含むログ行を横断的に検索し、レイテンシの分布を素早く集計したい。事前にS3へのエクスポートやAthenaテーブルの構築を行う時間は無い。最も適切な方法を選べ。（単一選択）
- A対象の複数ロググループを指定してCloudWatch Logs Insightsクエリを実行し、
filterでリクエストIDを絞り込み、statsでレイテンシの分布を集計する - Bまず
CreateExportTaskで対象ロググループをS3へエクスポートし、Athenaでテーブルとパーティションを新規作成してからクエリする - C各ロググループを個別にダウンロードし、ローカルのテキストエディタでリクエストIDを手動でgrepして集計する
- D対象ロググループにサブスクリプションフィルタを新規作成し、今後発生するログイベントだけをKinesisへ転送して集計する
正解・解説・誤答理由・ひっかけを見る▼ open
✓ 正解：AAI作成・独立検証済
解説
CloudWatch Logs Insightsは、CloudWatch Logsに保存済みのロググループへ事前のエクスポートや外部インフラ構築なしに、
その場でクエリ言語（fields/filter/stats/parse 等）を使ってアドホックに検索・集計できる機能である。
- 複数ロググループを横断して同時にクエリでき、時間範囲を指定して直近24時間分などに絞り込める。
statsコマンドでレイテンシの平均・パーセンタイル・分布集計も1クエリ内で完結できる。- これに対しAmazon Athenaでの分析は、ログが事前にS3へエクスポートされ、かつテーブル/パーティションが定義済みであることが前提となり、 障害対応中の即時調査には向かない（構築の時間的余裕が無い今回の状況と合わない）。
- Bエクスポート完了・テーブル定義に時間がかかり、障害対応中の即時調査には間に合わない。今回は「事前構築の時間が無い」という前提に反する。
- C複数ロググループ・24時間分の手動ダウンロード＋grepは非効率でスケールせず、レイテンシの統計的集計も手作業では困難。
- Dサブスクリプションフィルタは作成以降のログイベントにしか効かず、既に発生した直近24時間分の過去ログを遡って検索する用途には使えない。
ひっかけ： 「Athenaの方が高機能だから常に優先すべき」という思い込みに注意。Athenaは事前にS3上へログが存在しテーブル定義済みであることが前提で、
即時性が必要な障害対応の第一手としてはCloudWatch Logs Insightsが本命である。用途（即時調査 vs 長期集計）で使い分ける。
AIが作成し、独立した検証を経た解説です（有資格者による監修は経ていません）