AWS Certified CloudOps Engineer - Associate (SOA-C03) #3 Domain 1-2 モニタリング — CloudWatch Logs・Logs Insights・エージェント

#2 ではメトリクスで「何が起きたか」を整理しました。メトリクスは数値なので素早く傾向を見られますが、なぜそれが起きたかは教えてくれません。その答えはログにあります。この記事では CloudWatch Logs の構造と、ログを収集・分析・配信する運用の流れを整理します。

ログの構造: ログ グループとログ ストリーム #

CloudWatch Logs は 2 つの段階でログをまとめます。

設定の単位は ログ グループです。保持期間、KMS 暗号化、アクセス権限をログ グループに設定します。ログ ストリームはその中でソースごとに分かれる実際の行です。

保持期間とコスト #

ログ グループのデフォルト保持は 無期限です。つまり設定しなければログが永遠に溜まり、ストレージコストが増え続けます。運用ではログ グループごとに保持期間 (例: 30 日、90 日) を定めるのが基本です。長期保管が必要なら S3 へエクスポートしてより安いストレージクラスに置くのが定石です。

「ログコストが増え続ける」というシナリオの第一の答えは 保持期間の設定、長期保管は S3 エクスポート + ライフサイクルです。

CloudWatch Agent: ログと OS メトリクスの収集 #

EC2 やオンプレミスサーバーのログファイルと OS メトリクスは、デフォルトでは CloudWatch に入りません。CloudWatch Agent をインストールする必要があります。

• ログ収集 — /var/log/... のようなファイルを指定したログ グループへ送信
• OS メトリクス収集 — #2 で見た メモリ・ディスク使用率をカスタムメトリクスとして発行
• 設定 — エージェント設定ファイル (JSON)。Systems Manager Parameter Store に設定を保存して複数のインスタンスへ一貫してデプロイするのが推奨パターン
• 権限 — インスタンスに CloudWatchAgentServerPolicy を付けた IAM Role が必要

試験で「複数の EC2 に同一のエージェント設定を一貫してデプロイせよ」の答えは通常 SSM Parameter Store に設定を保存 + SSM でエージェントをデプロイです。

メトリクスフィルター (Metric Filter): ログからメトリクスを抽出 #

ログはテキストですが、その中から 特定パターンの出現回数をメトリクスに変換できます。これがメトリクスフィルターです。

例えばアプリケーションログから ERROR 文字列を数えて ErrorCount メトリクスを作り、そのメトリクスにアラームを設定します。

フィルターパターン: "ERROR"
→ メトリクス: MyApp/ErrorCount
→ アラーム: 5 分間に ERROR が 10 件を超えたら SNS 通知

核心は ログ自体にはアラームを設定できないという点です。ログをメトリクスに変えてから、そのメトリクスにアラームを設定する順序です。「ログに特定のメッセージが現れたら通知」という要求の標準的な実装がメトリクスフィルター + アラームです。

Logs Insights: ログのクエリ #

Logs Insights は 大量のログを SQL に似たクエリで分析するツールです。

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

メトリクスフィルターが「あらかじめ定めたパターンを常時集計」するのに対し、Logs Insights は 事後にその場で掘り下げるツールです。「障害が起きた時間帯のログを分析して原因を見つけよ」というトラブルシューティングシナリオの答えが Logs Insights です。複数のログ グループを一度にクエリできます。

サブスクリプションフィルター (Subscription Filter): ログのリアルタイム配信 #

ログが入ってくるとすぐに 別の宛先へ流す構成です。宛先は次のいずれかになります。

「ログをリアルタイムで分析システムへ送れ」や「複数アカウントのログを 1 か所に集めよ」という要求の答えがサブスクリプションフィルターです。クロスアカウントのログ収集もサブスクリプションフィルターで構成します。

ログのセキュリティ: 暗号化とアクセス #

• 暗号化 — ログ グループに KMS キーを接続して保存時に暗号化。機密ログのコンプライアンス要求を満たす
• アクセス制御 — ログ グループに対する読み取り・書き込み権限を IAM で制御
• CloudTrail との関係 — API 呼び出しの記録である CloudTrail ログも CloudWatch Logs へ送ってメトリクスフィルター・アラームを設定できる。例えば「ルートアカウントのログイン時に通知」は CloudTrail → CloudWatch Logs → メトリクスフィルター → アラームで実装

試験での出題パターン #

• ログコストが増え続ける → ログ グループの 保持期間設定、長期保管は S3 エクスポート
• 複数の EC2 にエージェント設定を一貫してデプロイ → SSM Parameter Store + SSM デプロイ
• ログに特定のメッセージが現れたら通知 → メトリクスフィルター + アラーム
• 障害時間帯のログを事後分析 → Logs Insights
• ログをリアルタイムで別システムへ配信 → サブスクリプションフィルター (Lambda・Kinesis・OpenSearch)
• ルートログイン・権限変更のような API イベントの監視 → CloudTrail → CloudWatch Logs → メトリクスフィルター

よくある落とし穴 #

1) ログに直接アラームを設定できると考える #

CloudWatch アラームは メトリクスにのみ設定できます。ログはメトリクスフィルターでメトリクス化してから、はじめてアラームの対象になります。

2) エージェントなしでログが収集されると誤解する #

Lambda・ECS のようなマネージドサービスはログを自動で送りますが、EC2・オンプレミスのファイルログは CloudWatch Agent があってこそ入ってきます。

3) デフォルト保持が短いと仮定する #

デフォルト保持は短いのではなく 無期限です。コスト管理のために明示的に減らす必要があります。

4) Logs Insights を常時集計に使おうとする #

Logs Insights はその場限りのクエリツールです。常時モニタリングとアラームは、メトリクスフィルターでメトリクスを作って設定する方が適切です。

まとめ #

この記事で押さえたこと:

• ログは ログ グループ(設定単位)と ログ ストリーム(ソースごと)で構成。保持・暗号化・権限はログ グループに
• デフォルト保持は 無期限 → コスト管理のため保持期間を設定、長期保管は S3 エクスポート
• CloudWatch Agent で EC2 のファイルログとメモリ・ディスクメトリクスを収集。設定は SSM Parameter Store で一貫してデプロイ
• メトリクスフィルターでログをメトリクス化してアラーム。ログ自体にはアラームを設定できない
• Logs Insights は事後のその場クエリ (トラブルシューティング)、サブスクリプションフィルター はリアルタイム配信 (Lambda・Kinesis・OpenSearch)
• CloudTrail ログを CloudWatch Logs へ送って API イベントアラームを構成

次へ: Domain 1-3 自動復旧とパフォーマンス最適化 #

メトリクスとログで検知まで整理したので、次は 検知後の自動対応です。#4 Domain 1-3 モニタリング: 自動復旧とパフォーマンス最適化 では、EventBridge でイベントに反応する方法、Systems Manager Automation で復旧を自動化する方法、EC2 自動復旧と Auto Scaling のセルフヒーリング、そして Compute Optimizer・CloudWatch でパフォーマンスを診断・最適化する流れまで整理します。