地味だけど、AWSユーザーにとっては嬉しいアップデートがありました！
EventBridgeとは
Amazon EventBridgeは、AWSが提供するイベント配信サービスです。簡単に言うと「何かが起きたとき（イベント）に、それを他のシステムに自動で知らせる」ことができるマネージドな機能です。
例えば、ECサイトで注文が入ったとき、EventBridgeを使って在庫管理システムや配送システムに自動で通知することができます。また、サーバーにエラーが発生したとき、自動でSlackに通知を送ったり、監視システムにアラートを出すことも可能です。
さらに、AWSの各種サービス自体の状態変化もイベントとして扱えます。例えば、EC2インスタンスが起動・停止したとき、S3にファイルがアップロードされたとき、RDSのバックアップが完了したときなど、AWS内の様々な出来事を自動的にキャッチして他のシステムに連携できます。
システムの機能的な用途としても用いられますが、非機能(監視やセキュリティなど)的な用途としても用いられるケースも多いです。このように、EventBridgeはAWS上で稼働するシステムにとっては欠かせない存在となっています。
アップデート内容
Amazon EventBridge now supports enhanced logging for improved observability
2025年7月15日、Amazon EventBridgeに拡張ログ機能が追加されました。これまでEventBridgeはログを出力しなかったため、イベントの配信状況やエラーの原因を調査することが困難でしたが、この機能により問題の特定やデバッグが大幅に簡単になりました。
ログの出力先は、CloudWatch Logs、S3、Data Firehoseから選択でき、ログレベルもinfo、error、traceの3種類が用意されています。また、オプションでイベントペイロード（実際のデータ内容）も含めることができるため、より詳細な分析が可能です。ログ出力機能自体に追加料金はかからず、ログの保存やデータ転送には従来通りの料金が適用されます。
対応リージョン
7/16現在
マネージメントコンソール上ではオハイオリージョンのみ対応
アップデート情報には全リージョンに対応していると記載がありますが、2025/7/16の時点ではマネージメントコンソールから操作する場合、オハイオリージョンしか拡張ログ機能を設定できません。(AWS CLIなどからは未確認です)
今後、全リージョンのマネージメントコンソールから利用できるようになると思います。
EventBridgeにおける課題
これまでのEventBridgeには、大きな課題がありました。それは「ログを出力しない」ことです。
EventBridgeでイベントの配信に問題が発生した場合、何が原因なのかを調査することが非常に困難でした。イベントが正常に送信されたのか、ターゲットに届いたのか、どこでエラーが発生したのかといった情報を把握する手段が限られていたのです。
本格的な調査を行う場合は、DLQ（デッドレターキュー）を設定して未処理のイベントを追跡する方法もありましたが、DLQの設定には事前準備が必要であり、キューの中身をすぐに見ることも難しいため、運用面での負担が大きいという問題がありました。このような理由から、EventBridgeのトラブルシューティングは開発者にとって頭の痛い作業となっていました。
実際に触ってみた
拡張ログ機能はイベントパスごとに有効にできます。
今回は新規でイベントバスを2つ作成して、イベントバス1->イベントバス2にテストイベントを送信することによって、どのようなログが記録されているかを見ていきます。
ログレベルはtraceにします。
traceではinfo/errorを内包した形で全てのステップを記録します。
詳細は[こちら]をご参照ください。(https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-event-bus-logs.html#eb-event-bus-logs-level)
送信元のイベントバスの作成ができたので、送信先のイベントバスを作成します。
(転送先のイベントバスはログの設定はしない)
送信元(test-log)から送信先(test-dest)にイベントが送信されるようにルールの作成をします。
イベントパターンは本来ならちゃんとフィルタリングすべきですが、今回は「すべてのイベント」を指定します。
これで準備OKです。
それでは送信元(test-log)にてイベントの送信をします。
送信できたので、ロググループを見てみます。
イベント送信は１度だが、ログが8エントリー出力されています。
以下はEventBridgeがイベントを処理する際のフローです。
フローは1つ1つのステップから構成されています。
各ステップの右下にi/t/xとマークされています。
ログレベルがtraceの場合はi/t/x全てのステップがログに記録されます。
ログレベルがinfoの場合はiのみが、errorの場合はxのみが記録されるようになっています。
今回はログレベルがtraceなので、フローにおける実行された全てのステップ分のログが出力されています。
一番最初のログを見ています。
{
"resource_arn": "arn:aws:events:us-east-2:xxxxxxxxxxxx:event-bus/test-log",
"message_timestamp_ms": 1752644464410,
"event_bus_name": "test-log",
"request_id": "98e2b23f-b67a-4a84-ba96-a5b720fe2e89",
"event_id": "fd5a0dee-f230-688c-5673-ade1ed54a429",
"message_type": "EVENT_RECEIPT",
"log_level": "TRACE",
"details": {
"caller_account_id": "xxxxxxxxxxxx",
"source_time_ms": 1752644463000,
"source": "hoge.hoge",
"detail_type": "testEvent",
"resources": []
}
}
"message_type": "EVENT_RECEIPT"となっているので、ログはEvent raceivedステップのものであるとわかります。
では一番最後のログを見てみましょう。
{
"resource_arn": "arn:aws:events:us-east-2:xxxxxxxxxxxx:event-bus/test-log",
"message_timestamp_ms": 1752644464492,
"event_bus_name": "test-log",
"request_id": "98e2b23f-b67a-4a84-ba96-a5b720fe2e89",
"event_id": "fd5a0dee-f230-688c-5673-ade1ed54a429",
"invocation_id": "fd5a0dee-f230-688c-5673-ade1ed54a429_b5d6fcc2-f432-a61c-5658-038c3a42769a",
"message_type": "INVOCATION_SUCCESS",
"log_level": "INFO",
"details": {
"rule_arn": "arn:aws:events:us-east-2:xxxxxxxxxxxx:rule/test-log/test-rule",
"role_arn": "arn:aws:iam::xxxxxxxxxxxx:role/service-role/Amazon_EventBridge_Invoke_Event_Bus_2042411593",
"target_arn": "arn:aws:events:us-east-2:xxxxxxxxxxxx:event-bus/test-dest",
"total_attempts": 1,
"final_invocation_status": "SUCCESS",
"ingestion_to_start_latency_ms": 13,
"ingestion_to_complete_latency_ms": 64,
"ingestion_to_success_latency_ms": 64,
"target_duration_ms": 0
}
}
"message_type": "INVOCATION_SUCCESS"となっており、イベントの処理に成功したことがわかります。detailsからは送信先や試行回数、かかった時間などがわかります。
それでは意図的にイベントの送信を失敗させて、失敗時のログを見てみましょう。
上でルールを作成する際に、同時に作成されたIAMロール(イベントバス)のポリシーを書き換えます。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ActionsForResource",
"Effect": "Allow",
"Action": [
"events:PutEvents"
],
"Resource": [
"arn:aws:events:us-east-2:xxxxxxxxxxxx:event-bus/test-dest"
]
}
]
}
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ActionsForResource",
"Effect": "Deny",
"Action": [
"events:PutEvents"
],
"Resource": [
"arn:aws:events:us-east-2:xxxxxxxxxxxx:event-bus/test-dest"
]
}
]
}
これで送信先イベントにイベント発行できなくなります。
それでは再度イベントを送信します。
そしてlog_levelがerrorのログを見てみます。
{
"resource_arn": "arn:aws:events:us-east-2:xxxxxxxxxxxx:event-bus/test-log",
"message_timestamp_ms": 1752645605529,
"event_bus_name": "test-log",
"request_id": "f834bf65-2ad9-470e-a340-9435f82473a6",
"event_id": "ef9209b2-61ca-12fe-ff36-efce67f46f9d",
"invocation_id": "ef9209b2-61ca-12fe-ff36-efce67f46f9d_cd69e133-826b-7330-1d86-d92a2bb72952",
"message_type": "INVOCATION_FAILURE",
"log_level": "ERROR",
"details": {
"rule_arn": "arn:aws:events:us-east-2:xxxxxxxxxxxx:rule/test-log/test-rule",
"role_arn": "arn:aws:iam::xxxxxxxxxxxx:role/service-role/Amazon_EventBridge_Invoke_Event_Bus_2042411593",
"target_arn": "arn:aws:events:us-east-2:xxxxxxxxxxxx:event-bus/test-dest",
"total_attempts": 1,
"final_invocation_status": "NO_PERMISSIONS",
"ingestion_to_start_latency_ms": 61,
"ingestion_to_complete_latency_ms": 61,
"target_duration_ms": 0,
"http_status_code": 400
},
"error": {
"error_message": "Lack of permissions to invoke cross account target.",
"aws_service": "AWSEvents"
}
}
message_typeがINVOCATION_FAILUREとなっており、さらにerror_messageとしてLack of permissions to invoke cross account target.と出ています。
このerror_messageの内容から、権限が不足していることによるイベント発行の失敗であるとわかります。
所感
- 簡単な設定でログを出力/確認できるようになったので、かなり快適になった印象
- 間違いなくデバッグ時には必須となる機能なので、積極的に有効化したい
- ただし、イベントのやり取りが膨大なシステムにおいては、ログの保存とデータ転送の料金が無視できなくなるので注意が必要