developersIO
[アップデート] Amazon EventBridgeのPutEvents呼び出しがCloudTrailで追跡できるようになりました

[アップデート] Amazon EventBridgeのPutEvents呼び出しがCloudTrailで追跡できるようになりました

AWSAmazon EventBridgeAWS CloudTrailupdate
2026.05.09

はじめに

みなさんこんにちは、クラウド事業本部コンサルティング部の浅野です。

2026年5月4日にAmazon EventBridgeがAWS CloudTrailのデータプレーンログ記録に対応しました。

https://aws.amazon.com/jp/about-aws/whats-new/2026/05/amazon-eventbridge-data-aws-cloudtrail/

EventBridgeを使ってシステム連携や非同期処理を組んでいる環境では「あのPutEventsいつどこから投げたっけ」「このバスにイベントを送ってきているのは誰だ」と後から追跡したい場面が出てきます。

これまではEventBridge自体のログ配信機能(CloudWatch Logs / Amazon Data Firehose / S3への出力)を有効化しておかないとPutEventsの呼び出しは追えず、CloudTrailからは管理イベント(PutRule、PutTargets、CreateEventBus 等)しか見えませんでした。

今回のアップデートでPutEvents / PutPartnerEventsがCloudTrailのデータイベントとして記録できるようになり、監査・証跡の選択肢が増えた形になります。本記事ではこのアップデートで何が記録対象になったかを整理しつつ、検証アカウントで実際にPutEventsを3パターン投げて記録のされ方を確認していきます。

検知可能なイベント

このアップデートでCloudTrailのデータイベントのリソースタイプとして以下の3種が追加されました。

Resource type (コンソール表示) resources.type 値 記録対象API
EventBridge event bus AWS::Events::EventBus PutEvents
EventBridge partner event source AWS::Events::EventSource PutPartnerEvents
EventBridge endpoint AWS::Events::Endpoint PutEvents(グローバルエンドポイント経由・成功時のみ)

これらのいずれかをCloudTrailのデータイベント対象に設定すると、PutEvents / PutPartnerEventsの呼び出しが「いつ・誰が・どのバスに・何件送ったか」のレベルでCloudTrailに流れるようになります。詳細は公式ドキュメントを参照してください。

なお仕様上、PutEventsのDetail(イベント本体のペイロード)はCloudTrailのログにはそのまま残らず、機密データ保護のためマスクされる扱いです。ペイロードの中身まで詳細に追いたい場合は引き続きEventBridgeのログ配信機能(CloudWatch Logs / Firehose / S3への出力)を併用する形になり、本アップデートはあくまで「監査・追跡」目的の機能と捉えるのがよさそうです。

どのアカウントに記録されるか

CloudTrailのデータイベントには「APIを呼び出したアカウントにのみ記録される」という重要な仕様があります(公式ドキュメント)。バス所有者の側には記録されないため、追跡できる範囲は呼び出し元の視点で決まります。

シナリオ 記録される側 自アカウントの証跡から追える?
自アカウント → 自分のバス 自アカウント ○
自アカウント → 他アカウントのバス 自アカウント(呼び出し元) ○
他アカウント → 自分のバス 呼び出した他アカウントのみ ×
SaaSパートナー → 自分のバス(PutPartnerEvents) SaaSパートナー側のみ ×

ここは従来からあるEventBridgeのログ配信機能との重要な差分になります。EventBridgeのログ配信機能はバス所有者がバス単位で設定する仕組みで、ログ対象として「Events sent to the bus via PutEvents」が公式に明記されており、呼び出し元アカウントを問わず自分のバスに到達したPutEventsをCloudWatch Logs / Firehose / S3に記録できます。一方、本アップデートで追加されたCloudTrailのデータイベントは呼び出し元アカウントの視点で記録される仕組みのため、外部アカウントから自分のバスに飛んできたPutEventsは見えません。

つまり「自分のバスに何が飛んできたか」を追いたい場合は従来のEventBridgeログ配信機能を、「自アカウントから誰に何を送ったか」を送信元のIAM情報込みで監査したい場合は今回のCloudTrailのデータイベントを、という使い分けができそうです。

やってみた

検証アカウントで以下の流れで試していきます。

  1. 検証用カスタムイベントバスを作成
  2. CloudTrailの証跡を新規作成し、EventBridge event busのデータイベントを有効化
  3. PutEventsを3パターン実行(基本送信 / バッチ送信 / 失敗試行)
  4. S3に配信されたログを開いて記録のされ方を確認

リージョンは東京(ap-northeast-1)、マネジメントコンソール操作で進めます。

Step 1: カスタムイベントバスの作成

EventBridgeコンソールから「イベントバスを作成」を開き、以下の設定で作成します。

  • 名前: demo-cloudtrail-eventbus
  • 暗号化・ログ送信先・リソースベースのポリシー: いずれも既定のまま

今回はカスタムバスを作成しましたが、デフォルトバスでも同じように記録されます。

2026-05-09-eventbridge-putevents-cloudtrail-tracking-01

以下のように作成できました。

2026-05-09-eventbridge-putevents-cloudtrail-tracking-02

Step 2: CloudTrailの証跡でEventBridgeのデータイベントを有効化

CloudTrailコンソールで新しい証跡を作成します。

ステップ1「証跡属性の選択」では基本情報を入力します。

  • 証跡名: demo-eventbridge-data-events
  • ストレージの場所: 新しいS3バケットを作成する
  • ログファイルのSSE-KMS暗号化: 無効(検証用のため)
  • ログファイル検証 / SNS通知の配信 / CloudWatch Logs連携: 無効

2026-05-09-eventbridge-putevents-cloudtrail-tracking-03

ステップ2「ログイベントの選択」でデータイベントにチェックを入れ、リソースタイプのドロップダウンを開くと、以下の4種類が選択できました。

  • EventBridge endpoint
  • EventBridge event bus
  • EventBridge partner event source
  • EventBridge rule

公式ドキュメントには記載はないのですが、EventBridge rule を選ぶことでイベントルール単位の粒度で記録対象を指定できるようでした。本検証では EventBridge event bus を対象にします。

2026-05-09-eventbridge-putevents-cloudtrail-tracking-04

リソースタイプとログセレクターテンプレートは以下を選択しました。

  • リソースタイプ: EventBridge event bus
  • ログセレクターテンプレート: すべてのイベントをログに記録する

2026-05-09-eventbridge-putevents-cloudtrail-tracking-05

確認画面で「証跡の作成」を押下すると証跡が作成されます。

2026-05-09-eventbridge-putevents-cloudtrail-tracking-06

Step 3: PutEventsを3パターン実行

証跡が記録を始めたところで、AWS CLIからPutEventsを3パターン投げてみます。

パターン1: 基本送信 + Resourcesフィールド付き

適当な文字列を含む Detail と、関連リソースのARNを指定する Resources を併せて送ります。

aws events put-events --region ap-northeast-1 --entries '[{
  "Source": "demo.audit",
  "DetailType": "OrderCreated",
  "Detail": "{\"orderId\":\"ORD-001\",\"creditCard\":\"4111-1111-1111-1111\"}",
  "Resources": ["arn:aws:s3:::demo-bucket/orders/ORD-001.json","arn:aws:lambda:ap-northeast-1:************:function:notify"],
  "EventBusName": "demo-cloudtrail-eventbus"
}]'

レスポンス:

{
    "FailedEntryCount": 0,
    "Entries": [
        {"EventId": "865efc03-c9ac-18ef-bb40-742993037083"}
    ]
}

パターン2: バッチ送信(複数エントリ)

1回のPutEventsに3エントリを含めて送信します。

aws events put-events --region ap-northeast-1 --entries '[
  {"Source":"demo.audit","DetailType":"BatchA","Detail":"{\"id\":\"A\"}","EventBusName":"demo-cloudtrail-eventbus"},
  {"Source":"demo.audit","DetailType":"BatchB","Detail":"{\"id\":\"B\"}","EventBusName":"demo-cloudtrail-eventbus"},
  {"Source":"demo.audit","DetailType":"BatchC","Detail":"{\"id\":\"C\"}","EventBusName":"demo-cloudtrail-eventbus"}
]'

レスポンス:

{
    "FailedEntryCount": 0,
    "Entries": [
        {"EventId": "797c4e0e-58b5-aaa5-41eb-32b8265ecdb1"},
        {"EventId": "7d18e5cc-4b64-a4e0-687c-c0da55fddb79"},
        {"EventId": "c7b8df87-c009-ba48-e1cb-de3afca08489"}
    ]
}

パターン3: バリデーション失敗(Source欠落)

EventBridgeの必須項目である Source を欠落させた状態で送信します。

aws events put-events --region ap-northeast-1 --entries '[{
  "DetailType": "MissingSource",
  "Detail": "{}",
  "EventBusName": "demo-cloudtrail-eventbus"
}]'

EventBridge側でバリデーション失敗(InvalidArgument)し、FailedEntryCount: 1 で返ってきます。

{
    "FailedEntryCount": 1,
    "Entries": [
        {
            "ErrorCode": "InvalidArgument",
            "ErrorMessage": "Parameter Source is not valid. Reason: Source is a required argument."
        }
    ]
}

Step 4: S3配信ログでCloudTrailのデータイベントを確認

CloudTrailコンソールの「イベント履歴」画面は管理イベント専用で、データイベントは表示されません。データイベントは証跡がS3に配信したログファイル(*.json.gz)を直接開いて確認します。

aws s3 cp s3://<trail-bucket>/AWSLogs/<account-id>/CloudTrail/ap-northeast-1/2026/05/09/ . --recursive
gunzip *.json.gz
grep -l "PutEvents" *.json

PutEventsを含むファイルを開いて、各パターンのレコードを確認します(以下、機密情報をマスク済み)。

パターン1のログ: 基本送信 + Resources

{
  "eventVersion": "1.11",
  "userIdentity": {
    "type": "AssumedRole",
    "principalId": "AROA3XFRBF23EXAMPLE:session-id",
    "arn": "arn:aws:sts::************:assumed-role/cm-asano.haruki/session-id",
    "accountId": "************",
    "accessKeyId": "ASIAIOSFODNN7EXAMPLE",
    "sessionContext": {
      "sessionIssuer": {
        "type": "Role",
        "arn": "arn:aws:iam::************:role/cm-asano.haruki",
        "userName": "cm-asano.haruki"
      },
      "attributes": {
        "creationDate": "2026-05-09T05:59:35Z",
        "mfaAuthenticated": "true"
      }
    }
  },
  "eventTime": "2026-05-09T05:59:36Z",
  "eventSource": "events.amazonaws.com",
  "eventName": "PutEvents",
  "awsRegion": "ap-northeast-1",
  "sourceIPAddress": "192.0.2.1",
  "userAgent": "aws-cli/2.33.22 ...",
  "requestParameters": {
    "entries": [
      {
        "source": "demo.audit",
        "resources": [
          "arn:aws:s3:::demo-bucket/orders/ORD-001.json",
          "arn:aws:lambda:ap-northeast-1:************:function:notify"
        ],
        "detailType": "OrderCreated",
        "detail": "HIDDEN_DUE_TO_SECURITY_REASONS",
        "eventBusName": "demo-cloudtrail-eventbus"
      }
    ]
  },
  "responseElements": {
    "failedEntryCount": 0,
    "entries": [
      {"eventId": "865efc03-c9ac-18ef-bb40-742993037083"}
    ]
  },
  "readOnly": false,
  "resources": [
    {
      "type": "AWS::Events::EventBus",
      "ARN": "arn:aws:events:ap-northeast-1:************:event-bus/demo-cloudtrail-eventbus"
    }
  ],
  "managementEvent": false,
  "eventCategory": "Data"
}

仕様通りDetailは HIDDEN_DUE_TO_SECURITY_REASONS でマスクされていました。一方でエントリ内に指定した Resources フィールドのARNはそのまま記録されていました。

パターン2のログ: バッチ送信

{
  "eventTime": "2026-05-09T05:59:50Z",
  "eventSource": "events.amazonaws.com",
  "eventName": "PutEvents",
  "requestParameters": {
    "entries": [
      {"source": "demo.audit", "detailType": "BatchA", "detail": "HIDDEN_DUE_TO_SECURITY_REASONS", "eventBusName": "demo-cloudtrail-eventbus"},
      {"source": "demo.audit", "detailType": "BatchB", "detail": "HIDDEN_DUE_TO_SECURITY_REASONS", "eventBusName": "demo-cloudtrail-eventbus"},
      {"source": "demo.audit", "detailType": "BatchC", "detail": "HIDDEN_DUE_TO_SECURITY_REASONS", "eventBusName": "demo-cloudtrail-eventbus"}
    ]
  },
  "responseElements": {
    "failedEntryCount": 0,
    "entries": [
      {"eventId": "797c4e0e-58b5-aaa5-41eb-32b8265ecdb1"},
      {"eventId": "7d18e5cc-4b64-a4e0-687c-c0da55fddb79"},
      {"eventId": "c7b8df87-c009-ba48-e1cb-de3afca08489"}
    ]
  },
  "readOnly": false,
  "resources": [
    {"type": "AWS::Events::EventBus", "ARN": "arn:aws:events:ap-northeast-1:************:event-bus/demo-cloudtrail-eventbus"}
  ],
  "managementEvent": false,
  "eventCategory": "Data"
}

3エントリのバッチ送信でもCloudTrailレコードは1件にまとまり、responseElements.entries[] に3件分のEventIdが順番通りに並びます。API呼び出し単位での集約なので、ログ量が膨らまないのは嬉しいですね。

パターン3のログ: バリデーション失敗

{
  "eventTime": "2026-05-09T05:59:58Z",
  "eventSource": "events.amazonaws.com",
  "eventName": "PutEvents",
  "requestParameters": {
    "entries": [
      {
        "detailType": "MissingSource",
        "detail": "HIDDEN_DUE_TO_SECURITY_REASONS",
        "eventBusName": "demo-cloudtrail-eventbus"
      }
    ]
  },
  "responseElements": {
    "failedEntryCount": 1,
    "entries": [
      {
        "errorCode": "InvalidArgument",
        "errorMessage": "Parameter Source is not valid. Reason: Source is a required argument."
      }
    ]
  },
  "readOnly": false,
  "resources": [
    {"type": "AWS::Events::EventBus", "ARN": "arn:aws:events:ap-northeast-1:************:event-bus/demo-cloudtrail-eventbus"}
  ],
  "managementEvent": false,
  "eventCategory": "Data"
}

バリデーション失敗したPutEvents呼び出しもCloudTrailに記録され、responseElements.entries[0] に errorCode: "InvalidArgument" と失敗理由を含む errorMessage が残りました。不正試行や設定ミスを後追いしたい場合の手がかりに使えそうです。

最後に

EventBridgeの PutEvents / PutPartnerEvents がCloudTrailのデータイベントとして記録できるようになり、これまで管理イベントだけでは見えなかった「いつ・誰が・どのバスに・何件PutEventsしたか」を監査ログから追跡できるようになりました。

このアップデートで嬉しいポイントを整理すると、以下の3点になると思います。

1. 組織内アカウントが発信したPutEventsを一括集約できる

CloudTrailで組織の証跡を作成してEventBridge event busのデータイベントを対象に含めれば、AWS Organizations配下のメンバーアカウントが発信したPutEvents呼び出しを管理アカウント側のS3バケットに一元集約できます。新規メンバーアカウントが追加された場合も自動的に監査対象になります。

ただし「検知可能なイベント」のとおり、組織外のアカウントから組織内バスへのPutEventsは追えません。受信側を見たい場合は引き続きEventBridgeのログ配信機能で対応する形になります。

2. PII・機密情報を伏せた状態で長期保管できる

PutEventsで送信したDetail本体はCloudTrailのログ上 HIDDEN_DUE_TO_SECURITY_REASONS でマスクされるため、誰がどのバスに何のイベントを送ったかを追跡しつつ、ペイロードの中身は監査ログから切り離して扱えます。個人情報や決済情報などのPIIをイベントに乗せる業務システムでも、監査ログをS3に長期保管したり組織横断で共有したりする際の漏洩リスクを抑えられる形です。

3. 失敗したPutEvents呼び出しも記録される

検証で確認したとおり、バリデーション失敗のPutEventsもCloudTrailに記録され、errorCode / errorMessage がそのまま残ります。アクセスキー漏洩時の探索試行や想定外のロールからの送信試行を後追いする際の手がかりに使えます。

一方で、Detail本体はマスクされるため、アプリケーションペイロードレベルのデバッグには引き続きEventBridgeのログ配信機能が必要です。本アップデートは「監査・追跡」用途、ログ配信機能は「デバッグ・運用観察」用途と役割を分けて併用するのが現実的だと思います。

今回は以上です。最後までお読みいただきありがとうございました。

この記事をシェアする

AWSのお困り事はクラスメソッドへ

関連記事

イラストで理解するAWS CloudTrail
よなみね
2025.07.08
CloudTrail Lakeのエンリッチメントでコンプライアンス監視をやってみた
酒井剛
2025.06.24
[アップデート]Amazon CloudWatch で AWS CloudTrail イベントの簡素化された有効化を開始されました
たかやま
2025.12.08
見落としがちな CloudTrail 証跡設定を確認し、マルチリージョン証跡に変換してみた
Shiina Yuichi
2025.11.07