CloudWatch・CloudTrail・Config

このページで押さえる論点

• 3 つのサービスの役割の違い（性能・操作・設定）
• CloudWatch メトリクス（基本モニタリングと詳細モニタリング、カスタムメトリクス、CloudWatch エージェント、保存期間）
• CloudWatch アラーム（状態・評価のしくみ・アクション）
• CloudWatch Logs（保持期間・メトリクスフィルター・Logs Insights・サブスクリプション）と EventBridge
• CloudTrail（イベント履歴・証跡・データイベント・整合性の検証・組織の証跡・Insights）
• AWS Config（設定の記録・ルール・自動修復・アグリゲーター）
• ワークロードの可視性（AWS X-Ray）と、要件に合わせた監視メトリクスの選び方

3 つのサービスの役割の違い

3 つとも「記録する」「見える化する」サービスなので、名前だけで覚えると混ざります。何を見ているかで区別しましょう。

API とは、AWS を操作するための窓口のことです。マネジメントコンソールでボタンを押しても、AWS CLI でコマンドを打っても、裏では API が呼ばれます。CloudTrail はこの API 呼び出しを記録するので、画面から行った操作もコマンドから行った操作も残ります。

1 つの出来事を 3 つのサービスがどう見るかを、下の図で確かめてみましょう。

CloudWatch メトリクス

メトリクスとは、「CPU 使用率」「ネットワーク受信量」のように、時間とともに変わる数値を一定間隔で記録したものです。1 つ 1 つの記録をデータポイントと呼びます。多くの AWS サービスは、何も設定しなくても CloudWatch にメトリクスを送ります。

基本モニタリングと詳細モニタリング（EC2）

「負荷の変化にすばやく反応して Auto Scaling させたい」という要件なら、5 分待たずに変化をつかめる詳細モニタリングが候補になります。

標準では取れないメトリクスと CloudWatch エージェント

EC2 の標準メトリクスは、AWS がサーバーの外側から測れるもの（CPU 使用率、ネットワーク、ディスクの読み書き回数など）です。メモリ使用率やディスクの空き容量のように、OS の内側でしかわからない値は含まれません。これらを集めるには、インスタンスに CloudWatch エージェント（情報を集めて送るソフトウェア）を入れます。エージェントはアプリのログファイルを CloudWatch Logs に送ることもでき、オンプレミスのサーバーにも入れられます。

カスタムメトリクスと保存期間

アプリが自分で数値（例: ログイン中のユーザー数）を送ることもでき、これをカスタムメトリクスと呼びます。1 分より細かい間隔（最短 1 秒）で送るものは高解像度メトリクスです。

メトリクスは、時間がたつほど粗い間隔にまとめられて保存されます。

つまりメトリクスは 15 か月で消えます。それより長く保管したい、または自由に分析したい場合は、メトリクスやログを S3 などへ出力しておく設計にします。

CloudWatch アラーム

アラームは、1 つのメトリクスを見張って、しきい値を超えたら何かを実行する仕組みです。アラームには次の 3 つの状態があります。

判定には「評価期間（直近いくつのデータポイントを見るか = N）」と「アラームを実行するデータポイント（そのうちいくつ超えたら ALARM にするか = M）」を使います。「3 個中 2 個」のように決めておくと、一瞬の跳ね上がりで警報が鳴るのを防げます。データが届かなかったとき（欠落）の扱いも選べます。下のシミュレーターで試してみましょう。

ALARM や OK に状態が変わったときに実行できる主なアクションは次のとおりです。

• Amazon SNS へ通知（メールや、SNS の先の Lambda などへ）
• EC2 アクション: インスタンスの停止・終了・再起動・復旧（基盤のハードウェア障害でステータスチェックが失敗したとき、別のハードウェアで起動し直す）
• EC2 Auto Scaling のスケーリングポリシー（ステップスケーリング・簡易スケーリング）の実行
• Systems Manager の OpsItem やインシデントの作成

アクションは状態が変わった時点で 1 回だけ実行され、ALARM が何時間続いても繰り返されません（Auto Scaling のアクションを除く）。複数のアラームを「A かつ B」のように組み合わせる複合アラームを使うと、関連する警報をまとめて通知の数を減らせます。

CloudWatch Logs と EventBridge

CloudWatch Logs は、アプリや AWS サービスのログ（出来事を文字で書いた記録）を集めて保管するサービスです。ログはロググループ（アプリごとなどのまとまり）単位で管理します。

• 保持期間: 既定では無期限に保存されます。ロググループごとに保持期間を設定すると、古いログは自動で削除され、保存料金を抑えられます
• メトリクスフィルター: ログの中から「ERROR」などの文字を数えてメトリクスに変換します。これにアラームを設定すれば「エラーが 1 分間に 10 回を超えたら通知」ができます
• CloudWatch Logs Insights: 専用のクエリ（問い合わせ文）でログを検索・集計します
• サブスクリプションフィルター: ログをほぼリアルタイムに Lambda・Kinesis Data Streams・Amazon Data Firehose などへ流し、別の場所で処理・保管します
• S3 へのエクスポート: 長期保管やほかのツールでの分析のために、ログを S3 へ書き出せます

Amazon EventBridge（旧 CloudWatch Events）は、「EC2 インスタンスが停止した」「決まった時刻になった」などのイベントを受け取り、ルールに合うものを Lambda や SNS などへ届けるサービスです。「状態の変化をきっかけに自動で処理する」「毎日決まった時刻に処理を動かす」という要件で使います。CloudTrail が記録した API 呼び出しもイベントとして受け取れるので、「特定の操作が行われたらすぐ通知する」仕組みも作れます。

AWS CloudTrail

CloudTrail は、AWS アカウントで行われた操作（API 呼び出し）をイベントとして記録します。イベントには「誰が（どの IAM ユーザー・ロールが）」「いつ」「どこから（送信元 IP アドレス）」「何をしたか」「成功したか」が含まれます。セキュリティ調査や監査（規則どおりに運用されているかの確認）の基本になるサービスです。

イベント履歴と証跡

「90 日より前の操作も調べたい」「監査のために何年も保管したい」という要件では、証跡を作って S3 に保管します。S3 のライフサイクルルールで古いログを安いストレージクラスに移せば、保管コストも抑えられます。

管理イベントとデータイベント

管理イベントは、リソースそのものに対する操作（EC2 インスタンスの作成、セキュリティグループの変更、IAM ポリシーの変更など）です。データイベントは、リソースの中身に対する操作（S3 のオブジェクトの読み取り・書き込み、Lambda 関数の実行など）で、件数が非常に多くなるため、既定では記録されません。「S3 のどのファイルを誰が読んだか記録したい」なら、証跡でデータイベントの記録を有効にします（追加料金がかかります）。

ログを守る・まとめる・異常に気づく

• ログファイルの整合性の検証: 配信後にログファイルが変更・削除されていないかを、ハッシュ（SHA-256）とデジタル署名で確かめられます。「ログが改ざんされていないことを証明したい」ときに使います
• ログの保護: 保管先の S3 バケットはバケットポリシーでアクセスを絞り、必要に応じて SSE-KMS で暗号化します。削除を防ぐには S3 の Object Lock も組み合わせます
• 全リージョンの記録: 証跡はすべてのリージョンのイベントを記録するように作れます。使っていないリージョンで不正な操作が行われても見逃しません
• 組織の証跡: AWS Organizations の管理アカウントで作ると、組織内のすべてのアカウントのイベントを 1 つの証跡にまとめて記録できます
• CloudTrail Insights: API の呼び出し回数やエラーの割合を過去の傾向（ベースライン）と比べ、急な増加などの異常を検出します

AWS Config

AWS Config は、AWS リソースの設定を記録し続け、設定が変わるたびに履歴を残すサービスです。「このセキュリティグループには、先月の時点でどんなルールがあったか」「このリソースはほかのどのリソースとつながっているか」を後から確認できます。CloudTrail が「操作」を記録するのに対し、Config は「その結果どういう設定になったか」を記録します。

Config ルールと適合パック

Config ルールは、リソースの設定が望ましい状態かを自動で評価するものです。結果は「準拠（COMPLIANT）」か「非準拠（NONCOMPLIANT）」で表示されます。

• マネージドルール: AWS が用意したルール（例: EBS ボリュームが暗号化されているか、S3 バケットが公開されていないか、ルートユーザーに MFA があるか）
• カスタムルール: 自分で Lambda 関数などを使って評価の中身を書くルール
• 適合パック: 複数のルールと修復アクションをまとめて、アカウントや組織に一括で展開する仕組み

Config ルールは「見つけて知らせる」ものです。IAM ポリシーのように操作そのものを止める（拒否する）ことはできません。設定変更を禁止したいなら、IAM ポリシーや SCP（組織のアカウントに付ける権限の上限）で拒否します。

自動修復とアグリゲーター

非準拠になったリソースには、修復アクションを設定できます。修復には Systems Manager の Automation ドキュメント（手順を定義したもの）を使い、「公開された S3 バケットを非公開に戻す」などを自動で実行できます。

アグリゲーターを使うと、複数のアカウント・複数のリージョン（AWS Organizations の組織全体も可）の設定と準拠状況を 1 か所に集めて確認できます。

ワークロードの可視性と監視するメトリクスの選び方

試験ガイドには「ワークロードの可視性（AWS X-Ray など）」と「ビジネス要件に基づいてメトリクスを特定する」が含まれています。

AWS X-Ray は、1 つのリクエストが API Gateway → Lambda → DynamoDB のように複数のサービスを通るとき、その経路と各区間の処理時間をトレース（追跡記録）として表示するサービスです。マイクロサービス（小さなサービスを組み合わせた構成）で「どこで遅くなっているか」「どこでエラーが出ているか」を探すときに使います。CloudWatch のメトリクスが「全体として遅い」ことを教えてくれるのに対し、X-Ray は「どの区間が遅いか」を教えてくれます。

何を監視するかは、要件から決めます。

問題文のキーワード → 選ぶべき答え

引っかけポイント

• 「EC2 のメモリ使用率は CloudWatch の標準メトリクスで見られる」→ ✕。OS の内側の値なので、CloudWatch エージェントが必要
• 「誰がインスタンスを終了したか知るには CloudWatch」→ ✕。操作（API 呼び出し）の記録は CloudTrail。CloudWatch は性能と状態
• 「設定の変更履歴や準拠状況は CloudTrail で見る」→ ✕（最適ではない）。設定の履歴とルール評価は AWS Config。CloudTrail は操作の記録
• 「CloudTrail は設定しなくても何年分もの操作を記録している」→ ✕。イベント履歴で見られるのは過去 90 日分の管理イベント。長期保管には証跡が必要
• 「証跡を作れば S3 のオブジェクト読み取りも記録される」→ ✕。データイベントは既定で記録されない。追加の設定が必要
• 「Config ルールを設定すれば、ルール違反の変更はブロックされる」→ ✕。Config は検出と記録（と修復）で、操作を拒否しない。止めたいなら IAM ポリシーや SCP
• 「CloudWatch Logs のログは既定で 30 日で消える」→ ✕。既定は無期限。コストを抑えるなら保持期間を設定する
• 「CloudWatch のメトリクスは無期限に保存される」→ ✕。1 時間間隔のデータでも 455 日（15 か月）まで

まとめ: SAA 試験で押さえるポイント

• 性能・状態の監視 → CloudWatch、誰が何をしたか → CloudTrail、設定の履歴とルールへの準拠 → AWS Config
• EC2 の基本モニタリングは 5 分間隔（無料）、詳細モニタリングは 1 分間隔（有料）。メモリやディスク空き容量は CloudWatch エージェントで集める
• アラームは OK / ALARM / INSUFFICIENT_DATA の 3 状態。「N 個中 M 個」で判定し、SNS 通知・EC2 の停止や復旧・Auto Scaling を実行できる
• CloudWatch Logs は既定で無期限保存。メトリクスフィルターでログからアラームを作り、サブスクリプションフィルターでほかのサービスへ流す
• CloudTrail のイベント履歴は 90 日分。長期保管・監査は証跡で S3 へ。データイベントは既定で記録されない。改ざんの確認はログファイルの整合性の検証、組織全体は組織の証跡
• Config ルールは非準拠を「検出」するもので、操作は止めない。自動で直すなら Systems Manager Automation の修復アクション、複数アカウントはアグリゲーター
• マイクロサービスのどこが遅いかを探す → AWS X-Ray