AWS CloudTrail

解決する課題

• 「誰が、いつ、どのリソースに、何の操作をしたか」を後から追えないと、障害や不正の原因究明ができない → API操作を自動で記録したい
• 監査やコンプライアンスで操作の証跡を求められる → 改ざんされにくい形で長期保存したい
• 複数アカウント・複数リージョンに散らばった操作ログを個別に集めるのは大変 → 横断的に一元集約したい

主要概念と用語

• イベント（Event）: API呼び出しなど1件の操作を表す記録。誰が・いつ・どこから・何をしたかを含む
• イベント履歴（Event history）: 直近の管理イベントを設定なしで閲覧・検索できる機能。保持期間は短め
• 証跡（Trail）: イベントをS3バケットなどへ継続的に配信する設定。長期保存や全リージョン記録に使う
• 管理イベント: リソースの設定・管理に関わる操作（コントロールプレーン）。設定変更やリソース作成など
• データイベント: リソース内データへの操作（データプレーン）。S3オブジェクトの読み書きやLambda実行など。量が多く既定では無効
• インサイトイベント: 通常と異なる操作量の急増などを自動検知した異常の記録
• CloudTrail Lake: イベントを取り込んでSQLで分析できるマネージドなイベントデータストア

仕様・制限・クォータ

• アカウント作成時から 直近の管理イベントはイベント履歴で閲覧可能。長期保存には証跡やLakeが必要
• 証跡は 全リージョンを対象にでき、新しいリージョンの操作も自動で記録対象になる
• データイベントは既定で無効。S3やLambdaなど対象を指定して有効化する。量が多くコストに直結する
• 配信先は主に S3。任意で CloudWatch Logs や EventBridge にも連携できる
• イベントは記録までに通常わずかな遅延がある。リアルタイムの即時遮断ではなく事後追跡が主目的
• 1アカウントで作成できる証跡数には上限があり、用途に応じて整理する

内部の仕組み

ユーザーやサービスがAWS APIを呼び出すと、その操作はCloudTrailが イベント として捕捉します。マネジメントコンソールの操作も内部的にはAPI呼び出しのため記録されます。各イベントには、実行した主体（IAMユーザーやロール）、時刻、送信元IP、対象リソース、リクエストとレスポンスの内容などが含まれます。

イベントは大きく 管理イベント（コントロールプレーン）と データイベント（データプレーン）に分かれます。管理イベントは既定で記録されますが、S3オブジェクト操作のようなデータイベントは件数が膨大になるため、明示的に有効化したときだけ記録されます。

証跡 を作成すると、イベントが継続的に S3バケット へJSON形式のログファイルとして配信されます。配信時にはログファイルダイジェスト（整合性検証用のハッシュ）を併せて出力でき、後から 改ざんの有無を検証 できます。証跡を 組織の証跡 にすると、AWS Organizations配下の全アカウントの操作を1か所へまとめられます。

設計パターン / ベストプラクティス

• 全リージョン対象の証跡を1つ作る: 特定リージョンだけでなく全リージョンを記録し、想定外の地域での操作も捕捉する
• 組織の証跡で一元集約: Organizationsと連携し、専用のログ用アカウントのS3バケットへ全アカウント分を集約する
• ログファイル検証を有効化: ダイジェストを出力し、改ざんされていないことを後から証明できるようにする
• 保存先S3を保護: バケットポリシーで書き込みを限定し、バージョニングやオブジェクトロックで保護する
• 重要操作の通知: CloudWatch LogsやEventBridgeと連携し、特定の操作を検知したら通知・自動対応につなぐ
• 長期分析はLake: SQLでの調査や長期保持が必要なら、S3への配信に加えてCloudTrail Lakeを使う

運用・監視

• イベント履歴 はまず最初の調査窓口。直近の操作を素早く検索して原因を当たる
• CloudWatch Logs に配信し、メトリクスフィルタとアラームで「ルートユーザーのログイン」「セキュリティグループ変更」などを検知する
• EventBridge 経由でSNS通知やLambdaによる自動対応をつなぐ
• CloudTrail Lake でSQLを使い、横断的な調査や定期的な監査クエリを実行する
• ログ配信が止まっていないか、証跡の状態（ロギング有効/無効）を定期的に確認する

コスト

管理イベントは1つ目の証跡への記録については追加料金なしで利用できることが多く、イベント履歴の閲覧も無料です。コストが大きくなりやすいのは データイベント で、S3オブジェクト操作やLambda実行など件数が膨大な操作を記録すると課金が積み上がります。CloudTrail Lakeも取り込み量や保持・分析に応じて課金されます。加えて、配信先である S3の保存料 やCloudWatch Logsの料金も別途かかります。データイベントは本当に必要な対象だけに絞ることが費用最適化の要点です。最新の料金は公式の料金ページで確認してください。

セキュリティ

• ログ保存先のS3バケットは 書き込み権限を最小化 し、改ざん・削除を防ぐ。バージョニングやオブジェクトロックを併用する
• ログファイル検証 を有効化し、ダイジェストで整合性を担保する
• ログには機微な情報が含まれうるため、KMSでの暗号化 と閲覧権限の最小化を行う
• 証跡の 停止・削除の操作自体 も記録されるため、設定変更を検知して通知する
• CloudTrailは事後の追跡が役割であり、リアルタイムの脅威検出はGuardDutyなどと組み合わせる

Well-Architected の観点

• セキュリティ: 全API操作の証跡を残し、不正調査やコンプライアンス対応の基盤となる。改ざん検証と暗号化で証跡の信頼性を確保する
• 運用上の優秀性: 変更の原因究明や監査を仕組み化し、検知から通知・自動対応までイベント駆動でつなげる

試験で問われるポイント

関連サービス・比較

監査の文脈でよく AWS Config と比較されます。CloudTrailは「操作の記録」、Configは「設定状態の記録と評価」が主眼です。

ハンズオン / CLI例

# 全リージョン対象の証跡を作成し、S3バケットへ配信する
aws cloudtrail create-trail \
  --name org-audit-trail \
  --s3-bucket-name my-cloudtrail-logs \
  --is-multi-region-trail \
  --enable-log-file-validation

# 作成した証跡のロギングを開始する
aws cloudtrail start-logging --name org-audit-trail

# イベント履歴から特定ユーザーの直近の操作を検索する
aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=Username,AttributeValue=alice \
  --max-results 20