Analyzegear
AWSを運用していると、「CloudTrail（クラウドトレイル）」と「CloudWatch（クラウドウォッチ）」というサービスをよく目にします。
どちらもAWS環境の監視やログ管理に関係するサービスですが、役割は異なります。
簡単に整理すると、次のように考えるとわかりやすいでしょう。
- CloudTrail：AWS上で「誰が・いつ・何をしたのか」を記録する
- CloudWatch：AWSリソースやアプリケーションが「どのような状態なのか」を監視する
また、「CloudTrailやCloudWatchのログはS3に保存されるのか？」という点も混同しやすいポイントです。
この記事では、CloudTrailとCloudWatchの違い、それぞれが扱うデータ、ログの保存先、Amazon S3との関係について解説します。
CloudTrailとは
AWS CloudTrailは、AWSアカウント内で行われた操作を記録するためのサービスです。
AWS Management Console、AWS CLI、AWS SDK、AWSサービスなどを通じて実行されたAPIアクティビティを記録できます。
たとえばEC2インスタンスが停止された場合、CloudTrailを確認することで、
- いつ操作されたのか
- どのユーザーやロールが操作したのか
- どのAPIが呼び出されたのか
- どのAWSリソースが対象だったのか
といった情報を調査できます。
そのためCloudTrailは、セキュリティ調査や監査、コンプライアンス対応などで重要な役割を持っています。
CloudTrailのイベント履歴は過去90日間
AWSアカウントではCloudTrailのイベント履歴を利用でき、各AWSリージョンにおける過去90日間の管理イベントを表示・検索・ダウンロードできます。
ただし、イベント履歴はCloudTrailで記録できるすべてのイベントを長期間保存する仕組みではありません。
90日を超えて継続的にイベントを保存したい場合などには、CloudTrailの「証跡（Trail）」を作成する方法があります。
CloudTrailのログはS3に保存される？
CloudTrailで証跡を作成すると、指定したAmazon S3バケットへCloudTrailイベントのログファイルを継続的に配信できます。
構成を簡略化すると、次のようになります。
AWS上でAPI操作
↓
CloudTrail
↓
証跡（Trail）
↓
Amazon S3
S3に配信されたCloudTrailログはJSON形式のデータを含むgzip圧縮ファイルとして保存されます。
S3のライフサイクルルールなどと組み合わせれば、監査ログを長期間保管しながらストレージコストを管理することも可能です。
なお、CloudTrailのログが必ずS3に保存されるという意味ではありません。過去90日間の管理イベントを確認するイベント履歴だけを利用するケースもあります。
「CloudTrailの証跡を作成すると、指定したS3バケットへログを継続的に配信できる」と理解しておくとよいでしょう。
CloudWatchとは
Amazon CloudWatchは、AWSリソースやアプリケーションなどを監視するためのサービスです。
CloudWatchが扱う代表的なデータには、メトリクスやログがあります。
たとえばEC2であればCPU使用率などのメトリクスをCloudWatchで監視できます。
LambdaやアプリケーションからCloudWatch Logsへログを送信すれば、
- エラーログ
- アクセスログ
- アプリケーションログ
- Lambdaの実行ログ
などを確認・分析できます。
さらにCloudWatch Alarmを利用すれば、メトリクスが設定した条件を満たした場合にアラーム状態にするなど、運用監視の仕組みを構築できます。
CloudWatch Logsとは
CloudWatchの中でも、ログの収集・保存・検索などを担当するサービスが「CloudWatch Logs」です。
CloudWatch Logsでは、ログは「ロググループ」や「ログストリーム」という単位で管理されます。
構成のイメージは次のようになります。
EC2・Lambda・アプリケーションなど
↓
CloudWatch Logs
↓
ロググループ
↓
ログストリーム
つまり、CloudWatch Logsに送信されたログは、基本的にはCloudWatch Logsで管理されます。
CloudWatchのログはS3に保存される？
CloudWatch Logsのログが自動的にS3へ保存されるわけではありません。
通常はCloudWatch Logs内で管理されます。
ただし、CloudWatch LogsのログデータをAmazon S3へエクスポートする機能が用意されています。
イメージとしては、
CloudWatch Logs
↓
S3へのエクスポート
↓
Amazon S3
という構成です。
AWSでは、CloudWatch LogsからS3への定期的なエクスポートを継続的なアーカイブ手段として使用することは推奨しておらず、継続的な配信が必要な場合にはサブスクリプションなどの仕組みを利用できます。
そのため、「CloudWatchのログはS3に保存される」と単純に考えるのではなく、「CloudWatch Logsで管理し、必要に応じてS3へエクスポート・配信する」と理解するのが適切です。
CloudTrailとCloudWatchの違い
CloudTrailとCloudWatchの違いを整理すると、次のようになります。
| 項目 | CloudTrail | CloudWatch |
|---|---|---|
| 主な目的 | AWS操作の記録・監査 | システムやアプリケーションの監視 |
| 主な対象 | AWS APIアクティビティ | メトリクス、ログなど |
| 確認できること | 誰が何をしたのか | システムがどのような状態か |
| 例 | 誰がEC2を停止したか | EC2のCPU使用率が高い |
| 例 | 誰がIAM設定を変更したか | Lambdaでエラーが発生している |
| ログ管理 | CloudTrailイベント | CloudWatch Logs |
| S3との関係 | 証跡を作成してS3へログを配信可能 | CloudWatch LogsからS3へのエクスポートなどが可能 |
| 主な用途 | セキュリティ監査、操作履歴調査 | 障害監視、性能監視、ログ分析 |
覚え方としては、
CloudTrailは「操作」、CloudWatchは「状態」
と考えると違いを理解しやすくなります。
EC2が突然停止した場合はどちらを見る？
CloudTrailとCloudWatchは、どちらか一方だけを使うのではなく、組み合わせて利用することで原因調査に役立ちます。
たとえば、稼働していたEC2インスタンスが突然停止したとします。
まずCloudWatchのメトリクスやログを確認して、
- 停止前に異常が発生していなかったか
- CPU使用率などに変化がなかったか
- アプリケーションでエラーが発生していなかったか
などを調査します。
一方、CloudTrailでは、
- StopInstancesなどのAPIが実行されていないか
- 誰が実行したのか
- いつ実行されたのか
といったAWS側の操作履歴を調査できます。
つまり、
CloudWatch
「システムに何が起きていたのか」
CloudTrail
「AWS上でどのような操作が行われたのか」
という異なる視点から原因を調査できます。
CloudTrailのログをCloudWatch Logsへ送ることもできる
CloudTrailとCloudWatchは完全に独立して利用するだけでなく、連携させることもできます。
CloudTrailの証跡では、イベントをS3へ配信することに加えて、オプションでCloudWatch Logsへ配信できます。
たとえば、
AWS API操作
↓
CloudTrail
↓
Amazon S3へ保存
＋
CloudWatch Logsへ配信
↓
監視・検知
といった構成が可能です。
これによりCloudTrailでAWSの操作を記録しながら、CloudWatchを利用した監視や通知につなげることができます。
CloudTrailとCloudWatchは目的で使い分ける
CloudTrailとCloudWatchは、どちらもAWS環境の運用に欠かせないサービスですが、目的が異なります。
CloudTrailは、AWS上で行われたAPIアクティビティを記録するサービスです。「誰が、いつ、何をしたのか」を確認したい場合に利用します。
一方、CloudWatchはAWSリソースやアプリケーションの状態を監視するサービスです。メトリクスやログなどを利用して、障害や性能上の問題を把握するために利用します。
また、ログの保存先については、
CloudTrail：証跡を作成するとS3へログファイルを継続的に配信できる
CloudWatch Logs：基本的にCloudWatch Logsで管理し、必要に応じてS3へエクスポート・配信できる
という違いがあります。
「CloudTrail＝操作の記録」「CloudWatch＝状態の監視」と整理しておけば、それぞれの役割や使い分けを理解しやすくなるでしょう。
