ログとメトリクスの集約設計 CloudWatch Logs から横断分析までを組み立てる

DOP-C02 では「複数アカウント・複数サービスのログをどう集めて、どう気づくか」という運用設計が問われます。収集・保管・検知・分析の4工程で組み立てると、選択肢の役割がはっきりします。

覚え方は「集める・貯める・気づく・掘る」

集める＝エージェントやサブスクリプションで一か所へ、貯める＝保持期間とコストを設計、気づく＝メトリクスとアラームで通知、掘る＝必要なときに横断検索。要件文の「気づくのが遅い」は検知の層、「調査に時間がかかる」は分析の層の話です。

工程ごとの打ち手

収集は、EC2やオンプレサーバーには CloudWatch エージェント、コンテナには awslogs もしくは FireLens、Lambda は自動で CloudWatch Logs に出ます。マルチアカウントでは、各アカウントのロググループにサブスクリプションフィルターを設定し、集約アカウントの Kinesis Data Streams や Amazon Data Firehose へ流して S3 に集めるのが定番です。保管では、ロググループごとに保持期間を設定し（既定は無期限＝高コスト）、長期保管が必要なものだけ S3 のライフサイクルでアーカイブします。検知は、メトリクスフィルターでログ中の文字列（たとえば ERROR の出現回数）をカスタムメトリクス化し、CloudWatch アラームで通知します。異常判定のしきい値を固定できない場合は異常検出（Anomaly Detection）を使うと、曜日や時間帯の変動を学習したバンドで判定できます。分析は、直近の調査なら CloudWatch Logs Insights のクエリ、S3 に集約済みの大量ログなら Athena が向きます。

チェックリスト

• ログ収集の4工程を順に説明できる
• サブスクリプションフィルターによる集約構成を描ける
• メトリクスフィルターとアラームの連携を説明できる
• Logs Insights と Athena の使い分けを説明できる
• 複合アラームと異常検出の使いどころを言える

まとめ

ログ設計は「集める・貯める・気づく・掘る」で分解し、コストと通知の質まで含めて最適化するのが実務的な正解です。 理解度の確認にはクイズが便利です。試験範囲や申し込みの最新情報はAWS認定 公式ページもあわせて確認してください。