AWS CloudTrail活用入門|操作ログの取得・CloudWatch連携・Athena分析の実践
CloudTrailとは?AWSの全操作を記録する監査ログサービス
「誰が・いつ・何をしたか」を証明できることは、AWS運用においてセキュリティと証跡管理の両面で非常に重要です。インシデント対応や監査対応の現場で必ず参照するのがAWS CloudTrailです。AWSセキュリティ設計を担当する中で日常的に活用しているサービスなので、実践的な観点からお伝えします。
CloudTrailはAWSアカウントで発生したすべてのAPI操作を記録するサービスです。マネジメントコンソールからの操作・AWS CLIコマンド・SDKからのAPI呼び出しのすべてがログとして記録されます。
CloudTrailが記録する情報
CloudTrailのログ(イベント)には以下の情報が含まれます。
- 誰が:実行したIAMユーザー・ロール・AWSサービス
- いつ:操作日時(UTC)
- 何を:実行したAPIアクション(例:RunInstances、DeleteBucket)
- どこから:送信元IPアドレス
- 成功/失敗:操作が成功したかどうか
実際の現場では「本番環境のS3バケットが削除された」「セキュリティグループが勝手に変更された」といったインシデントが発生したとき、CloudTrailで原因を特定します。
証跡(Trail)の設定
CloudTrailはデフォルトで過去90日間のイベントをコンソールで確認できますが、長期保管や自動分析には「証跡(Trail)」の設定が必要です。
- 証跡を作成してS3バケットにログを保存(長期保管・コンプライアンス対応)
- すべてのリージョン対象にする設定を推奨(グローバルサービスイベント含む)
- ログファイルの整合性検証を有効化(改ざん検知)
- CloudWatch Logsへの配信設定でリアルタイム分析も可能
CloudWatch Logsと連携したアラート設定
CloudTrailのログをCloudWatch Logsに配信することで、特定の操作が実行されたときにアラートを発報できます。
現場でよく設定するアラートの例:
- rootアカウントのログイン検知
- IAMポリシーの変更(CreatePolicy・AttachUserPolicy)
- セキュリティグループの変更(AuthorizeSecurityGroupIngress)
- S3バケットのACL・ポリシー変更
- CloudTrail自体の停止・設定変更
設定手順はCloudWatch Logsのメトリクスフィルターを作成し、フィルターパターンに対象のAPIアクション名を指定、アラームをSNSトピックに接続するだけです。
Athenaを使ったCloudTrailログの分析
大量のCloudTrailログを効率よく分析するにはAmazon Athenaが便利です。S3に保存されたCloudTrailログに対してSQLクエリを実行できます。
- CloudTrailコンソールの「Athenaでクエリを実行」からテーブル作成が簡単にできる
- 「過去1週間にEC2インスタンスを終了したユーザーを特定する」などの調査が可能
まとめ:CloudTrailはAWSセキュリティ運用の基盤
CloudTrailはAWSを本番運用するすべての環境で有効化すべきサービスです。設定自体はシンプルですが、証跡の長期保管・CloudWatch Logsとの連携・Athenaによる分析を組み合わせることで、セキュリティ運用の質が大きく向上します。AWSアカウントを持っているなら今すぐ証跡設定を確認してください。
CloudTrailの有効化と証跡(Trail)の設定
CloudTrailはデフォルトで90日分のイベント履歴をマネジメントコンソールで確認できますが、長期保存・分析には「証跡(Trail)」の作成が必要です。
- 証跡の作成:S3バケットにログを継続的に保存する設定。全リージョン対象にすることを推奨
- ログファイルの検証:証跡設定で「ログファイルの検証」を有効化すると、ログの改ざん検知が可能になる
- CloudWatch Logsへの配信:リアルタイム監視のためにCloudWatch Logsと連携させる
現場では「証跡を作ったが、CloudWatch Logsに連携していなかったため障害時に即時確認できなかった」というケースを見たことがあります。証跡作成とCloudWatch連携は必ずセットで設定することを強くおすすめします。
CloudWatchとの連携:リアルタイムアラートを設定する
CloudTrailのログをCloudWatch Logsに送ることで、特定の操作が発生した際にリアルタイムでアラートを受け取れます。
現場でよく設定するアラートの例:
- rootアカウントでのサインインが発生したとき
- IAMポリシーが変更されたとき(AttachUserPolicy・DetachRolePolicyなど)
- セキュリティグループのインバウンドルールが変更されたとき
- S3バケットのパブリックアクセス設定が変更されたとき
設定手順はCloudTrail → CloudWatch Logs → メトリクスフィルター → アラーム → SNS通知の順で構築します。
Amazon Athenaでのログ分析:大量ログの効率的な検索
CloudTrailのログはJSON形式でS3に保存されます。ログ量が多くなるとマネジメントコンソールでの検索では限界があります。そこで活用するのがAmazon Athenaです。
- Athenaとは:S3上のデータをSQLで直接クエリできるサービス。サーバー不要でクエリ実行量に応じた課金
- CloudTrailとの連携:AWSはCloudTrail用のAthenaテーブル作成を自動化するウィザードを提供している
Athenaを使った実践的なクエリ例:
-- 特定のIAMユーザーの操作履歴を確認
SELECT eventtime, eventname, sourceipaddress, requestparameters
FROM cloudtrail_logs
WHERE useridentity.username = 'target-user'
AND eventtime BETWEEN '2026-01-01T00:00:00Z' AND '2026-01-31T23:59:59Z'
ORDER BY eventtime DESC;
CloudTrailのコスト管理
CloudTrailは以下のコスト構造を持ちます。把握しておくことで無駄なコストを防げます。
- 管理イベント:最初の証跡は無料。2つ目以降は100,000イベントあたり約0.1USD
- データイベント:S3オブジェクトレベルやLambda関数の呼び出しを記録する場合は別途課金。量が多い環境では注意が必要
- Insightsイベント:異常な操作パターンを検出する機能。有効化する場合は追加コストが発生
まとめ:CloudTrailを現場で活かすための3ポイント
- 証跡は全リージョン対象で作成し、CloudWatch Logsと連携させる
- rootアカウント利用・IAM変更のアラートは最低限必ず設定する
- 大量ログの分析にはAthenaを活用し、インシデント対応を効率化する
CloudTrailはAWSセキュリティの「目」です。設定しているだけで終わらず、定期的にログを確認する習慣と、異常時に即時通知が届く仕組みを整えることが現場では重要です。




