AWS を使っていると必ず耳にする CloudTrail と CloudWatch。両方とも AWS のモニタリング系サービスですが、何が違うの？と思う方もいるのではないでしょうか。
この記事では、それぞれの基本と違い、使い分けのポイントをざっくりまとめてみます！

そもそも CloudTrail って何？

CloudTrail は、AWS での API 呼び出し履歴を記録・監査するためのサービス です。

対象
- AWS アカウントで行われた管理イベント（例えば EC2 の起動や IAM ポリシーの変更など）や一部のデータイベント（S3 オブジェクト操作など）をログとして保存。
- 誰がいつどんな操作をしたかを追跡できる。
保存先
- 標準的には S3 にログを出力する。オプションで CloudWatch Logs にも流し込んで可視化やアラートをかけたりできる。
用途
- 監査やセキュリティ対策（不審なアクションがないかチェック）。
- 障害調査（「いつ誰が何をやった？」を追う）。
- リソース操作の履歴が必要なコンプライアンス要件など。

CloudWatch って何？

CloudWatch は、AWS リソースとアプリケーションをモニタリングするためのサービス です。CPU 使用率やディスク I/O、メモリ使用率（※カスタムメトリクスが必要）などを可視化したりアラート設定できたりします。

メトリクス
- EC2、RDS、DynamoDB、ALB など、各種 AWS サービスがデフォルトでメトリクスを CloudWatch に送信。
- 自分でカスタムメトリクスを送ってアプリ固有の情報を記録することも可能。
ログ管理 (CloudWatch Logs)
- アプリケーションログや Lambda のログ出力をリアルタイムで収集し、監視や可視化ができる。
- Metrics Filter などを使ってログの中の特定文字列を検知 → アラートを発火、といった使い方も。
アラーム
- しきい値を超えたら SNS 通知を送る、Auto Scaling を発火させる、などの柔軟な設定が可能。

項目	CloudTrail	CloudWatch
主な目的	API 呼び出しの監査・ログ記録	リソースやアプリのメトリクス＆ログ監視
ログ/データの内容	“誰が何をしたか” という操作履歴	稼働状況(CPU,メモリ)やログ情報(エラー数など)
出力先	S3 (標準)、CloudWatch Logs(オプション)	CloudWatch メトリクス・CloudWatch Logs
主なユースケース	セキュリティ監査、障害調査、コンプライアンス	リソースの稼働監視、パフォーマンス可視化、アラート設定
リアルタイム性	やや遅延して記録 (数分)	ほぼリアルタイム (数十秒〜数分)
料金イメージ	無料枠あり。大量保存時は S3 コストなどに注意	メトリクス数や保存期間、Logs の GB 数などで変動

操作履歴の監査が必要 → CloudTrail
- 不審な操作がないかチェックしたり、障害時に「どの操作が原因だった？」と調べるなら CloudTrail。
システム稼働状況やログを監視 → CloudWatch
- サーバーの CPU 使用率やメモリ、アプリログをリアルタイムにモニタしてアラートを飛ばしたいなら CloudWatch。
両方を組み合わせる事例が多い
- CloudTrail のログを CloudWatch Logs に送って、特定の管理イベントをトリガーに通知を受け取ったりすることもできる。
- 「操作ログの保管」は CloudTrail、「メトリクス・ログ監視」は CloudWatch と役割分担している感じ。

どちらも AWS 運用には欠かせない定番サービスですが、役割が異なるので混同しないようにしましょう。
大抵は両方設定しておいて、セキュリティ監査とシステム監視をセットで固めるのがオススメです！

もし何か不明点や追加情報があれば、コメントで教えてください！
この記事が少しでも参考になればうれしいです。