Secrets Manager の EventBridge 直接通知と CloudTrail の配信遅延を比較してみた

はじめに

2026年7月、AWS Secrets Manager がシークレット更新時に Amazon EventBridge へ直接イベントを発行する機能がリリースされました。

https://aws.amazon.com/jp/about-aws/whats-new/2026/07/secrets-manager-update-notifications/

従来、シークレット更新を契機にした自動処理を EventBridge で実装するには、CloudTrail 経由のイベント（detail-type: "AWS API Call via CloudTrail"）を利用する必要がありました。CloudTrail 経由でも EventBridge への配信自体は near real-time ですが、CloudTrail の有効化が前提であること、イベント構造が CloudTrail のフォーマットに依存すること、配信が best effort であることなどの制約がありました。今回の新機能により、Secrets Manager がラベル移動単位でシンプルなイベントを直接発行するようになり、CloudTrail に依存せず確実にイベントを受け取れるようになります。

本記事では、EventBridge 直接通知と CloudTrail 経由の 2 系統を並行して CloudWatch Logs に流し、同一操作に対する配信速度の差を 10 回の試行で定量的に比較します。あわせて、イベント構造の違いと使い分けの判断材料を整理します。

検証内容

検証環境

• リージョン: ap-northeast-1
• テスト用シークレット名: test/eventbridge-notification-test

以下の 2 系統を同一アカウント内で並行稼働させ、同一の PutSecretValue 操作に対する配信時刻を比較しました。

• 系統 1 (Direct): Secrets Manager → EventBridge (Secret Label Updated) → CloudWatch Logs
• 系統 2 (CloudTrail): Secrets Manager → CloudTrail → EventBridge (AWS API Call via CloudTrail) → CloudWatch Logs

EventBridge ルールの作成

EventBridge ルールを作成し、Secrets Manager のラベル更新イベントをキャッチします。

aws events put-rule \
  --name secrets-manager-label-updated-test \
  --event-pattern '{
    "source": ["aws.secretsmanager"],
    "detail-type": ["Secret Label Updated"]
  }' \
  --state ENABLED

ターゲットとして CloudWatch Logs を設定します。

aws events put-targets \
  --rule secrets-manager-label-updated-test \
  --targets '[{
    "Arn": "arn:aws:logs:ap-northeast-1:123456789012:log-group:/aws/events/secrets-manager-test",
    "Id": "cloudwatch-logs-target"
  }]'

EventBridge から CloudWatch Logs へイベントを配信するには、ロググループにリソースポリシーを設定して events.amazonaws.com に対して logs:CreateLogStream と logs:PutLogEvents を許可する必要があります。

aws logs put-resource-policy \
  --policy-name EventBridgeToCloudWatchLogs \
  --policy-document '{
    "Version": "2012-10-17",
    "Statement": [
      {
        "Effect": "Allow",
        "Principal": {
          "Service": "events.amazonaws.com"
        },
        "Action": [
          "logs:CreateLogStream",
          "logs:PutLogEvents"
        ],
        "Resource": "arn:aws:logs:ap-northeast-1:123456789012:log-group:/aws/events/secrets-manager-test:*"
      }
    ]
  }'

シークレット値の更新とイベント確認

シークレット値を更新します。

aws secretsmanager put-secret-value \
  --secret-id test/eventbridge-notification-test \
  --secret-string '{"password":"new-value"}'

CloudWatch Logs でイベントの到着を確認します。

aws logs filter-log-events \
  --log-group-name /aws/events/secrets-manager-test \
  --start-time 1784748000000 \
  --limit 1

到着したイベントの構造は以下のとおりです。

{
  "version": "0",
  "id": "af1b92b2-d19e-5e0b-ac6d-d1ad0d9a2fc0",
  "detail-type": "Secret Label Updated",
  "source": "aws.secretsmanager",
  "account": "123456789012",
  "time": "2026-07-22T19:20:07Z",
  "region": "ap-northeast-1",
  "resources": [
    "arn:aws:secretsmanager:ap-northeast-1:123456789012:secret:test/eventbridge-notification-test-AbCdEf"
  ],
  "detail": {
    "name": "test/eventbridge-notification-test",
    "labelUpdated": "AWSCURRENT",
    "versionId": "a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"
  }
}

detail-type は Secret Label Updated で、detail にはシークレット名・更新されたラベル・バージョン ID の 3 項目のみが含まれます。操作者情報（誰が更新したか）はこのイベントには含まれません。なお、AWSPENDING や AWSPREVIOUS ラベルの移動はイベントの対象外です。

タイムラグの確認

2 系統が並行して動いている状態で、PutSecretValue を 10 秒間隔で 10 回実行し、CloudWatch Logs の ingestionTime（ログサービスがイベントを受信した時刻）を比較しました。ingestionTime はイベントが実際にターゲットに届いた時刻に最も近い指標です。

両系統ともイベントの time フィールドは API 実行時刻と同一秒でした。CloudWatch Logs の timestamp（EventBridge がログに書き込んだ時刻）も両系統で一致しています。差が出るのは ingestionTime であり、Direct は平均 1.1 秒、CloudTrail 経由は平均 3.4 秒でログに到達しています。

注目すべきは、CloudTrail 経由のイベントも数秒で EventBridge に配信されている点です。CloudTrail が S3 にログファイルを書き出す際の遅延（5〜15 分）とは異なり、AWS API Call via CloudTrail イベントは CloudTrail のストリーミングパイプラインから直接 EventBridge に配信されるため、実用上は数秒レベルの遅延に収まります。

ただし、CloudTrail 経由は Direct に比べてばらつきが大きく（1.9 秒〜6.0 秒）、配信は best effort です。確実にイベントを受け取りたいユースケースでは、Direct 通知のほうが安定しています。

EventBridge 通知と CloudTrail の使い分け

EventBridge 直接通知と CloudTrail のイベントで得られる情報を比較します。

CloudTrail には userIdentity（操作者・ロール・MFA 有無）、sourceIPAddress、userAgent など、誰がどこから操作したかの情報が含まれます。証跡・監査目的で「いつ・誰が・どこから」を報告する必要がある場合は、引き続き CloudTrail が有効です。

一方、シークレット更新を検知して即座に処理を走らせたい場合（キャッシュ同期、コネクションプール再作成など）は、EventBridge 直接通知が最適です。ラベル移動単位でイベントが発行されるため、ローテーション完了を 1 イベントで検知できる点も利点です。配信遅延は Direct が平均 1.1 秒と安定しており、CloudTrail 経由（平均 3.4 秒）より高速かつばらつきも小さい結果でした。なお、比較表のローテーション検知に関する記述は、イベント仕様（AWSCURRENT ラベルの移動で 1 イベントが発行される）に基づく推論であり、本記事でローテーションの検証は実施していません。

まとめ

Secrets Manager の EventBridge 直接通知は、シークレット更新を起点とする自動処理を CloudTrail に依存せず構成したい場合の選択肢になります。特にローテーション検知では1イベントで完結するため、CloudTrail で複数 API コールを突合する必要がなくなります。更新の検知と後続処理を主目的にするなら直接通知を、操作者の特定が必要な監査には CloudTrail を選び、必要に応じて併用するとよいでしょう。

参考リンク

https://docs.aws.amazon.com/secretsmanager/latest/userguide/secret-event-notifications.html