変更要約: in-scope サービス網羅(是正): §4.3 にベストプラクティス横断点検の Trusted Advisor 節を追加（参考書で未説明だった軸B欠落を解消）
4.2ログ管理
ログの収集と分析——CloudWatch Logs、Logs Insights（クエリ）、メトリックフィルター、サブスクリプションフィルター、集中ログ（Amazon Data Firehose→S3/OpenSearch）——を理解します。ログから洞察と検知を得ます。
ログは収集・検索・分析・集中管理が要点です。CloudWatch Logs を中心に、フィルターやストリーミングで活用します。
4.2.1ログの収集と分析
- CloudWatch Logs：ログを集約し、保持期間を設定。エージェントやサービスから収集。
- Logs Insights：SQL ライクなクエリでログを高速に分析する。
- メトリックフィルター：ログ内のパターン（例: ERROR）をメトリック化しアラームにつなぐ。
- サブスクリプションフィルター：ログをリアルタイムに Firehose/Lambda へストリーミングし、S3/OpenSearch へ集中転送。
「ログのクエリ分析＝Logs Insights」「ログのパターンをアラーム化＝メトリックフィルター」「ログのリアルタイム転送/集中化＝サブスクリプションフィルター→Firehose→S3/OpenSearch」 は DOP-C02 で頻出です。組織横断のログ集中管理はサブスクリプションフィルター＋Firehose が定番です。
「特定の文字列（例: NullPointerException）がログに出たらアラート」はメトリックフィルターでメトリック化→アラームが定石です。長期保管は S3、全文検索/可視化は OpenSearch を使い分けます。
DOP-C02 のログ設計は「収集→分析→検知→集中保管」の各段で適切なサービスを選べるかが問われます。CloudWatch Logs はロググループごとに保持期間を設定でき（無期限も可だがコストに注意）、統合 CloudWatch Agent が EC2/オンプレからメトリックとログをまとめて送ります。Logs Insights は SQL ライクな構文（fields/filter/stats/sort）で大量ログを横断検索し、よく使うクエリは保存できます。メトリックフィルターはログ内パターンをカウント/抽出してメトリック化し、アラームへつなぎます（ただし過去ログには遡及しない点に注意）。リアルタイムの配信は サブスクリプションフィルターで、宛先は Kinesis Data Streams/Firehose/Lambda。組織横断では各アカウントのロググループから中央アカウントの Firehose へ送り、S3（長期・安価、Athena でクエリ）や OpenSearch（全文検索・ダッシュボード）へ集約します。改ざん耐性が要るなら S3 Object Lock や、API 監査の CloudTrail（→ CloudWatch Logs/ S3）を併用します。コスト最適化として、不要なデバッグログの抑制・保持期間の見直し・ログのサンプリング/フィルタリングを行うのも DevOps の責務です。
| やりたいこと | 機能 | 要点 |
|---|---|---|
| ログを対話的に分析 | Logs Insights | SQL ライクなクエリ・保存可 |
| ログのパターンを検知 | メトリックフィルター→アラーム | ERROR 数などをメトリック化（遡及なし） |
| リアルタイムに転送 | サブスクリプションフィルター | Kinesis/Firehose/Lambda へ |
| 長期保管 / 全文検索 | S3 / OpenSearch | 安価保管は S3・検索は OpenSearch |
シナリオ：数十アカウントのアプリログを 1 か所に集め、セキュリティ調査では全文検索、監査では 7 年保管したい。→ 各アカウントの サブスクリプションフィルターから中央アカウントの Amazon Data Firehose へストリーミングし、Firehose の分岐で OpenSearch（全文検索/ダッシュボード）と S3（7 年保管・Object Lock）の両方へ配信。S3 は Athena でアドホック分析でき、長期コストも抑えられます。
FAQ：メトリックフィルターとサブスクリプションフィルターはどう違う？ メトリックフィルターはログ内パターンをメトリック化してアラームにつなぐ（CloudWatch 内で完結）。サブスクリプションフィルターはマッチしたログをリアルタイムに外部（Kinesis/Firehose/Lambda）へストリーミングして集中処理・転送します。検知ならメトリックフィルター、転送/集中化ならサブスクリプションフィルター、と使い分けます。
ひっかけ：メトリックフィルターは設定後に到着するログにのみ適用され、過去のログには遡及しません。「過去のログから件数を数えたい」場合は Logs Insights でクエリします。また長期・大量保管をすべて CloudWatch Logs に置くと割高——保管は S3、検索/可視化は OpenSearch へ寄せるのが定石です。
4.2.2ログ/運用データの大規模分析・可視化
S3 に集めたログや運用データは、目的に応じた分析サービスで掘り下げます。Athena は S3 上のデータに対しサーバーレスで SQL クエリを実行でき、インフラ管理なしにアドホック調査やコスト/アクセスログ分析に向きます（前述の集中ログの定番）。Amazon EMR は Spark/Hadoop などで大規模なバッチ/分散処理を行い、Athena では重い TB 級ログの ETL や複雑な集計に使います。Amazon QuickSight は分析結果をBI ダッシュボードとして可視化し、運用 KPI やコストを関係者へ共有できます。Amazon AppFlow は SaaS（例: 監視/チケット系 SaaS）と AWS の間でノーコードのデータ連携を行い、外部データを分析基盤へ取り込みます。いずれも DevOps では「観測データを意思決定に変える」後段の分析レイヤーであり、リアルタイム検知（メトリックフィルター/アラーム）とは役割が異なります。
4.2.3この節のまとめ
- 分析＝Logs Insights／検知＝メトリックフィルター→アラーム
- 集中化＝サブスクリプションフィルター→Firehose→S3/OpenSearch
- 大規模分析＝Athena（SQL）/EMR（分散処理）、可視化＝QuickSight、SaaS連携＝AppFlow
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. 大量のログから、SQL ライクなクエリで特定条件のエントリを高速に分析したい。何を使いますか？
Q2. ログに特定のエラー文字列が一定回数以上出現したらアラームを出したい。何を使いますか？
Q3. 複数アカウントのログをリアルタイムに集約し、S3 や OpenSearch へ集中転送したい。何を使いますか？