AWS Config vs CloudTrail — 監査・コンプライアンスツールの使い分け

Config と CloudTrail の根本的な違い

CloudTrail:
  → 「誰が何のAPI操作をしたか」を記録
  → 例: IAMユーザー alice が s3:PutBucketPolicy を実行
  → いつ・誰が・何をしたか（操作ログ）
  → デフォルト: 管理イベント（マネジメントコンソール/API操作）

AWS Config:
  → 「リソースの設定がどう変わったか」を記録
  → 例: S3バケット my-bucket のパブリックアクセスが有効になった
  → いつ・何が変わったか（設定変更履歴）
  → Config Rulesで設定の準拠状況を継続評価

記録する情報の違い

CloudTrail が記録する情報（管理イベント）:
  - API操作の名前（CreateBucket, PutBucketPolicy等）
  - 実行者（IAMユーザー、ロール、サービス）
  - 送信元IPアドレス
  - タイムスタンプ
  - リクエスト/レスポンスの詳細
  
CloudTrail が記録しないもの（デフォルト）:
  - データイベント（S3 GetObject等）→ 有効化が必要で料金がかかる
  - コンソールへのログイン（マネジメントコンソールはサインイン記録あり）

AWS Config が記録する情報:
  - リソースの設定の全スナップショット
  - 変更前と変更後の設定の差分
  - 変更をトリガーしたCloudTrailイベントへのリンク
  - リソース間の関係（依存関係グラフ）
  
AWS Config が記録しないもの:
  - APIの呼び出し操作（誰がやったか）
  - データ操作（S3バケットへのファイルアップロード等）

相互補完の使い方

調査シナリオ: S3バケットのパブリックアクセスが有効になった

1. AWS Config でリソース変更を確認:
   「いつ」「何が変わったか」を特定
   → my-bucket の BlockPublicAcls が true → false に変更
   → 変更タイムスタンプ: 2026-04-08T10:30:00Z

2. CloudTrail でAPI操作を確認:
   「誰が」操作したかを特定
   → s3:PutBucketPublicAccessBlock API が実行された
   → 実行者: arn:aws:iam::123456789012:user/developer-bob
   → 送信元IP: 203.0.113.50

3. GuardDuty で脅威を確認:
   → 悪意のある操作か判定
   → 既知の脅威IPからの操作か等

CloudTrail で調査する操作の例

# 特定リソースへのAPI操作をCloudTrailで検索
aws cloudtrail lookup-events \
  --lookup-attributes '[{
    "AttributeKey": "ResourceName",
    "AttributeValue": "my-bucket"
  }]' \
  --start-time "2026-04-08T00:00:00Z" \
  --end-time "2026-04-09T00:00:00Z"

# 特定ユーザーの操作を検索
aws cloudtrail lookup-events \
  --lookup-attributes '[{
    "AttributeKey": "Username",
    "AttributeValue": "developer-bob"
  }]'

Config の設定履歴確認

# リソースの設定変更履歴を確認
aws configservice get-resource-config-history \
  --resource-type AWS::S3::Bucket \
  --resource-id my-bucket \
  --start-time "2026-04-01T00:00:00Z" \
  --end-time "2026-04-09T00:00:00Z"

# リソースの現在の設定を確認
aws configservice get-discovered-resource-counts \
  --resource-types AWS::S3::Bucket AWS::EC2::Instance

CloudTrail Lake

CloudTrail Lakeは構造化されたクエリで長期的なAudit分析が可能なサービスだ。

-- CloudTrail Lake でS3パブリックアクセス変更を検索
SELECT
  eventTime,
  userIdentity.arn,
  requestParameters,
  sourceIPAddress
FROM
  my-event-data-store
WHERE
  eventName = 'PutBucketPublicAccessBlock'
  AND requestParameters like '%"BlockPublicAcls":false%'
ORDER BY eventTime DESC

各サービスの保存期間

CloudTrail（標準）:
  → 90日間（無料、S3への保存なし）
  → S3に保存: 無制限（S3料金がかかる）
  → CloudTrail Lake: 最大7年

AWS Config:
  → 設定スナップショット: S3に保存（無制限）
  → Config Rules 評価履歴: S3保存で無制限

GuardDuty:
  → 検出結果: 90日間
  → S3へのエクスポートで長期保存

試験頻出ポイント

シナリオ	回答
リソース設定が変わった経緯を追跡	AWS Config（設定変更履歴）
誰がEC2を停止したかを確認	CloudTrail（API操作ログ）
S3バケットの現在の設定違反を検出	Config Rules
コンソールログインを追跡	CloudTrail（サインインイベント）
セキュリティ調査でConfigとCloudTrailを組み合わせ	Config→「何が変わったか」、CloudTrail→「誰がやったか」

まとめ

ConfigとCloudTrailは相互補完的なサービスだ。設定変更の事実（何が変わったか）はConfigで、その変更を実行したAPI操作（誰がやったか）はCloudTrailで確認する。セキュリティ調査では両者を組み合わせて完全な状況把握を行う。

S	公式ソース確認済み
A	成功実績多数・失敗例少数
B	賛否両論
C	動作未確認・セキュリティリスク高
Z	個人所感