2026.10.17 AWS

EventBridge ログの調べ方：ルールが発火しない原因をメトリクス・バスログ・DLQで特定する

Q: スケジュールで動かすルールが指定した時刻に動きません。何を確認しますか？

まず時刻の基準を確認します。ルールの ScheduleExpression はUTCで解釈されるため、日本時間の9時に動かしたいなら cron(0 0 * * ? *) と書きます。ルールは指定した分の中で動き、秒単位の精度はありません。タイムゾーンを指定したい、1回限りの実行をしたいといった要件なら、EventBridge Schedulerのほうが向いています。Schedulerの書き方は EventBridge SchedulerのAPI で解説しています。

Q: ルールは動いているのにLambda関数が起動しないのはなぜですか？

多くはLambda側のリソースベースポリシーの不足です。 aws lambda get-policy で、プリンシパル events.amazonaws.com と対象ルールのARNを条件にした lambda:InvokeFunction の許可があるかを確認します。公式のトラブルシューティングによると、ポリシーに SourceAccount が入っているとEventBridgeから呼べないため削除が必要です。エイリアスやバージョンを呼んでいる場合は --qualifier を付けて確認します。

EventBridge ログの調べ方：ルールが発火しない原因をメトリクス・バスログ・DLQで特定する

EventBridgeのルールを作ったのにターゲットが動かないとき、最初に困るのは「どこを見ればよいか」です。EventBridgeは処理の途中経過を既定ではどこにも残さないため、調べる側でログの出口を用意する必要があります。本記事では、CloudWatchメトリクスで止まった段を特定し、イベントバスのログ記録・CloudWatch Logsターゲット・DLQで原因を読む手順を、CLIとLogs Insightsのクエリ例つきで整理しました。EventBridge全体の仕組みはAmazon EventBridgeとは？仕組み・料金とCLI・Pythonでの実装手順に譲ります。仕様と上限値は2026年10月時点の公式ドキュメントの記載です。

まとめ：EventBridgeのログ調査はメトリクスで段を絞りバスログとDLQで原因を読む

調査で最初に行うのは、問題が起きた段階の切り分けです。まずルール単位のメトリクスTriggeredRules・Invocations・FailedInvocationsを見て、「ルールに一致していない」のか「一致したがターゲットに届いていない」のかを分けます。前者ならイベントパターンと実際のイベントの差を、後者なら権限・リソースの有無・ターゲット側のエラーを疑います。

原因を読む手段は、照合から配信までの各段を残すバスのログ記録、届いたイベント本文を残すCloudWatch Logsターゲット、失敗理由を残すDLQの3つです。AWSサービスのイベントは不一致だとバスのログにも残らないため、パターン不一致の調査ではCloudWatch Logsターゲットで実物を捕まえます。常時はERRORレベルとアラーム、DLQまでにとどめ、TRACEや詳細データは調査の間だけ有効にします。

ログを出す3つの手段｜バスのログ記録・CloudWatch Logs・DLQの守備範囲

3つの手段は記録する対象が違い、どれか1つでは足りない場面があります。最初に守備範囲を押さえておくと、調査で遠回りしません。

イベントバスのログ記録が残す処理の段と、記録しないAWSイベントの条件

イベントバスのログ設定を有効にすると、EventBridgeはイベントの受け取り・ルール照合・ターゲット呼び出しの各段をログとして送ります。送信先はCloudWatch Logs、Amazon Data Firehose、Amazon S3の3つで、どの送信先にも同じ内容が届きます。既定のレベルはOFFで、何も記録されません。

記録の対象には条件があります。PutEventsで送ったイベント、パートナーのイベント、アーカイブから再生したイベントは、ルールに一致してもしなくても記録されます。一方、AWSサービスのイベントは、バス上のルールに一致したものだけが対象です。処理ステップの説明には、どのルールにも一致しないAWSイベントは破棄されログも生成されないと書かれています。マネージドルールだけに一致したイベントも記録されません。

EC2の状態変化を拾うルールが動かない場合、バスのログが空でも、イベントが来ていないのかパターンに合わなかったのかは区別できません。

CloudWatch Logsターゲットで届いたイベント本文をそのまま残す用途

ルールのターゲットにCloudWatch Logsのロググループを指定すると、ルールに一致したイベントのJSONがログエントリとして保存されます。バスのログが「どの段で何が起きたか」を残すのに対し、こちらは「どんな中身のイベントが来たか」を残す手段です。

手段	記録されるもの	分かること	既定
イベントバスのログ記録	照合・呼び出しの各段とエラー	一致したか、どのターゲットで何のエラーか	OFF
CloudWatch Logsターゲット	一致したイベントの本文	実際に届くイベントのフィールドと値	なし（ルールを作る）
DLQ（SQS）	配信に失敗したイベントと失敗理由	ERROR_CODE・再試行回数・対象ルール	なし（ターゲットに設定）

パターン不一致の調査では、条件をsourceだけに緩めた調査用ルールを別に作り、ターゲットをCloudWatch Logsにします。そこに残った実イベントと本番ルールのパターンを突き合わせれば、どのフィールドで外れているかが分かります。

本記事のメトリクス名とmessage_typeは、デフォルトバスと従来型のカスタムバス（Custom Event Bus – Classic）のものです。2026年9月に追加された購読者型のCustom Event Busは、専用の可観測性ページにあるとおりメトリクスがAWS/EventsV2に出て、ログも購読者ごとのLogConfigurationで有効にする別系統です。

ルールが発火しないときの最初の確認｜CloudWatchメトリクスで止まった段を特定

ログを有効にする前に、設定なしで毎分送られているメトリクス（AWS/Events名前空間）で段を絞ります。

TriggeredRulesとFailedInvocationsで止まった段を見分ける

メトリクスの一覧から、ルールが発火しない調査で使う4つを並べます。統計はSumを使います。

メトリクス	数えるもの	0またはデータなしのときの読み方
TriggeredRules	イベントに一致して動いたルールの数	パターン不一致か、イベント自体が来ていない
Invocations	ターゲットを呼んだ回数（成功・失敗の両方）	一致していても呼び出しまで進んでいない
FailedInvocations	再試行を経ても失敗した呼び出し	値があれば権限・リソース・ターゲット側のエラー
InvocationsSentToDlq	DLQへ送られた呼び出し	値があればDLQのERROR_CODEを読む

TriggeredRulesに値がありFailedInvocationsも増えているなら、問題はターゲットへの配信側です。TriggeredRulesが出ていないなら、配信側をいくら調べても答えは出ません。

get-metric-statisticsでルール単位のSumを取りデータなしを読む

CLIでは次のように取得します。--dimensionsにルール名を入れ、5分刻みのSumを見ます。

aws cloudwatch get-metric-statistics \
  --namespace AWS/Events \
  --metric-name TriggeredRules \
  --dimensions Name=EventBusName,Value=orders-bus Name=RuleName,Value=order-created-to-sqs \
  --start-time 2026-10-17T00:00:00Z --end-time 2026-10-17T06:00:00Z \
  --period 300 --statistics Sum

ここに2つの落とし穴があります。1つ目は次元の指定です。公式によると、RuleNameだけを指定したメトリクスはデフォルトバスのルールを指し、カスタムバスのルールはEventBusNameとRuleNameの両方で記録されます。カスタムバスのルールをRuleNameだけで探すと、動いていても何も返りません。

2つ目は「0」が記録されないことです。InvocationsやFailedInvocations、InvocationsSentToDlqは値が0でないときだけ送られ、TriggeredRulesはルールが一度動くまでメトリクス自体が現れません。データポイントが空なのは「0回」の意味で、取得の誤りとは限らない。なお、メトリクスはベストエフォートで、1分単位の完全な記録ではないと明記されています。

イベントバスのログを有効にする手順｜ログレベル・詳細データ・送信先の設定

段が絞れたら、バスのログ記録で中身を読みます。設定はレベル、詳細データの有無、送信先の3点です。

update-event-busでレベルを指定しロググループへ配信する設定例

レベルと詳細データはupdate-event-busの--log-configで指定します。値はLevelがOFF・ERROR・INFO・TRACE、IncludeDetailがNONE・FULLです。送信先はCloudWatch Logsのログ配信の仕組み（配信元・配信先・配信の3つ）で紐づけます。コンソールのバス編集画面で送信先を選べば、この紐づけは画面側で作られます。

# 1. バスのログレベルと詳細データを設定する
aws events update-event-bus --name orders-bus \
  --log-config IncludeDetail=FULL,Level=INFO

# 2. 配信先のロググループを作る（/aws/vendedlogs/ で始める）
aws logs create-log-group --log-group-name /aws/vendedlogs/events/orders-bus

# 3. バスを配信元、ロググループを配信先として登録し、両者を紐づける
aws logs put-delivery-source --name orders-bus-info \
  --resource-arn arn:aws:events:ap-northeast-1:123456789012:event-bus/orders-bus \
  --log-type INFO_LOGS

aws logs put-delivery-destination --name orders-bus-cwl \
  --delivery-destination-configuration destinationResourceArn=arn:aws:logs:ap-northeast-1:123456789012:log-group:/aws/vendedlogs/events/orders-bus

aws logs create-delivery --delivery-source-name orders-bus-info \
  --delivery-destination-arn DESTINATION_ARN

DESTINATION_ARNにはput-delivery-destinationの応答に入るARNを入れます。--log-typeは設定したレベルに合わせた種別を指定します。ロググループ名を/aws/vendedlogs/で始めておくと、配信用のリソースポリシーをCloudWatch Logs側が管理してくれる、というのが購読者型バスの手順にある説明です。設定する側のIAMには、対象バスに対するevents:AllowVendedLogDeliveryForResourceの許可が要ります。

ERROR・INFO・TRACEで記録されるmessage_typeと選び方

レベルは上位が下位を含む関係です。ログのスキーマにあるmessage_typeで見ると、調査に効くものは次のとおりです。

ERROR：INVOCATION_FAILURE・INVOCATION_ATTEMPT_PERMANENT_FAILURE・INVOCATION_ATTEMPT_RETRYABLE_FAILURE・INVOCATION_DLQ・EVENT_INGEST_FAILUREなどの失敗と、スロットリング
INFO：上記に加え、RULE_MATCH（一致したルールとターゲット）、NO_STANDARD_RULES_MATCHED（一致なし）、INVOCATION_START・INVOCATION_SUCCESS
TRACE：上記に加え、EVENT_RECEIPT・RULE_MATCH_START・試行ごとのINVOCATION_ATTEMPT_START・INVOCATION_ATTEMPT_SUCCESS

「ルールに一致したか」を知りたいならINFOで足ります。NO_STANDARD_RULES_MATCHEDが出ていれば、PutEventsで送ったイベントはどのルールにも合わなかったと分かる。TRACEは再試行の1回ごとまで出るため、スロットリングや遅延を追うときに限ります。IncludeDetail=FULLにするとtarget_inputなどが付き、ターゲットに何を渡したかまで読める。1レコードは1MBが上限で、超えた分の項目はdropped_fieldsに記録されて削られます。

Logs Insightsでevent_idを軸に呼び出しの失敗まで追うクエリ

CloudWatch Logsに届いたレコードはJSONなので、Logs Insightsでフィールドを指定して読めます。最初に段ごとの件数を数え、次に1件のイベントをevent_idで追います。

# 直近の段ごとの件数
fields message_type
| stats count(*) as n by message_type
| sort n desc

# 1件のイベントを受け取りから呼び出しの結果まで時系列で追う
fields @timestamp, message_type, details.rule_arn, details.target_arn, error.aws_service, error.http_status_code, error.error_message
| filter event_id = "6a7e8feb-b491-4cf7-a9f1-bf3703467718"
| sort @timestamp asc

失敗したレコードのerrorには、呼び出し先のサービス名、HTTPステータス、エラーメッセージが入ります。ターゲット側のログを探す前にここを見ます。Logs Insightsはスキャン量で課金されるため、期間を絞って実行してください。クエリ言語と課金の詳細はCloudWatch Logs Insightsの料金と使い方にまとめています。

原因別の確認手順｜パターン不一致・CloudTrail・権限不足・DLQの失敗理由

メトリクスとログで見えた症状ごとに、確認する場所と直し方を並べます。

RULE_MATCHが出ないときは実イベントをtest-event-patternで照合

ルールを作成・変更した直後は、反映まで少し時間がかかると公式のトラブルシューティングに書かれています。時間を置いても一致しないなら、実際に届くイベントを捕まえてパターンと照合します。

# 調査用：sourceだけで拾うルールを作り、CloudWatch Logsへ流す
aws events put-rule --name debug-ec2-all \
  --event-pattern '{"source":["aws.ec2"]}'

aws events put-targets --rule debug-ec2-all \
  --targets 'Id=cwl,Arn=arn:aws:logs:ap-northeast-1:123456789012:log-group:/aws/events/debug-ec2'

# ロググループに残ったイベントをevent.jsonに保存し、本番ルールのパターンと照合する
aws events test-event-pattern \
  --event-pattern file://pattern.json \
  --event file://event.json

test-event-patternは一致すれば"Result": trueを返します。外れやすいのは、ARNの区切り文字です。多くのAWSサービスはARNのコロンとスラッシュを同じ扱いにしますが、EventBridgeのパターンは厳密一致なので、イベントに入っている通りの文字で書きます。CloudTrailのAPIイベントはresourcesが空のことがあり、resourcesで絞ると一致しません。演算子の書き方はEventBridge イベントパターンの書き方で扱っています。調査が終わったらdebug-ec2-allは削除します。

CloudTrail経由のイベントは証跡・読み取り系の状態・us-east-1を確認

detail-typeがAWS API Call via CloudTrailのイベントは、条件を満たさないとそもそもバスに届きません。CloudTrail経由のイベントのページで確認すべき点は3つです。

ログ記録が有効なCloudTrailの証跡があるか。CloudTrail系のdetail-typeは証跡が無いと記録されない
Get・List・Describeなどの読み取り系の管理イベントを拾いたい場合、ルールの状態がENABLED_WITH_ALL_CLOUDTRAIL_MANAGEMENT_EVENTSになっているか。既定のENABLEDでは一致しない
IAMやRoute 53などグローバルサービスのAPIイベントを、米国東部（バージニア北部）のus-east-1で受けているか

CloudTrailのイベントはデフォルトバスにだけ届くため、カスタムバスで拾うには転送用のルールが要ります。読み取り系を転送するなら、転送元と転送先の両方のルールに上記の状態が必要です。バスをまたぐ送信のポリシーはEventBridge イベントバスの使い分けで解説しています。

CloudWatch Logsに書き込まれない原因はロググループのリソースポリシー

ルールは動いているのにロググループが空なら、まず権限を疑います。リソースベースのポリシーのページによると、ロググループ側にEventBridgeが書き込めるリソースポリシーが要り、コンソールなら自動で作られますが、CLIやIaCでは自分で登録します。

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

CloudWatch LogsのターゲットにはRoleArnを指定しないよう公式に注意書きがあります。ロールを付ければ動く、という発想で直そうとすると遠回りです。またput-resource-policyで登録するポリシーは、CloudWatch Logsのクォータでリージョンごとに10個までと決まっており、引き上げできません。ロググループごとにポリシーを足すのではなく、/aws/events/のような接頭辞で1つにまとめます。Terraformで書く場合の例はTerraform EventBridgeの実装手順にあります。

DLQのERROR_CODE属性で権限不足とリソース不在を見分けて直す

ターゲットにDLQを付けておくと、配信に失敗したイベントがSQSに残り、メッセージ属性に失敗の理由が入ります。DLQのページにある属性はRULE_ARN・TARGET_ARN・ERROR_CODE・ERROR_MESSAGE・EXHAUSTED_RETRY_CONDITION・RETRY_ATTEMPTSの6つです。

aws sqs receive-message \
  --queue-url https://sqs.ap-northeast-1.amazonaws.com/123456789012/orders-bus-dlq \
  --message-attribute-names All \
  --max-number-of-messages 10 \
  --visibility-timeout 0

ERROR_CODEがNO_PERMISSIONSならターゲット側のリソースポリシーかロール、NO_RESOURCEならターゲットのリソースが消えている、THROTTLINGならターゲットの処理能力不足です。公式によると、権限不足・リソース不在・アドレス不正は再試行されずに直接DLQへ送られます。RETRY_ATTEMPTSが0で届いたものは再試行の対象外だった失敗なので、まず権限やリソースの設定を疑う。回数が多いものなら、調査の起点はターゲット側の一時的な障害です。APIでDLQを指定した場合はキュー側のポリシーも手で付ける必要があり、抜けるとInvocationsFailedToBeSentToDlqが増えます。DLQからの再投入はEventBridgeとSQS・Lambdaの非同期構成で扱っています。

ログ調査の運用判断｜常時有効にする範囲と調査時だけ上げる設定の線引き

ログは多く出すほど調査は楽になりますが、費用と情報の複製が増えます。常時の設定と調査時の設定を分けておきます。

常時はERRORレベルと失敗のアラーム、全ターゲットのDLQで足りる

本番で常に有効にしておくのは次の3つで足ります。

バスのログ記録をERROR・IncludeDetail=NONEで有効にする（失敗した段とエラー内容だけが残る）
FailedInvocationsのSumが1以上でSNSに通知するCloudWatchアラーム（公式のトラブルシューティングに作成手順がある）
すべてのターゲットにDLQを付け、InvocationsSentToDlqにもアラームを張る

EventBridgeは配信を最大24時間再試行し、尽きるとFailedInvocationsを記録してイベントを捨てます。DLQが無い構成では、失敗に気づいた時点で中身は残っていません。ログより先にDLQを付ける、が優先順位です。

TRACEとFULLを調査の間だけに限る理由はペイロードの複製

IncludeDetail=FULLにすると、イベント本文とターゲットへの入力がログに複製されます。購読者型バスのドキュメントは、ペイロード付きのログはロググループを読める人なら誰でも本文を読めると警告し、調査が済んだら戻すよう案内しています。個人情報や注文情報を流すバスでFULLを出しっぱなしにする構成は採りません。

費用の面でも、バスのログはCloudWatchのVended Logsの料金（料金ページのLogsタブ）で課金され、TRACEはイベント1件ごとに複数のレコードを生みます。流量の多いバスで常時TRACEにする理由はありません。調査はINFOから始め、再試行やスロットリングを追う必要が出たときだけTRACEに上げ、終わったらERRORに戻す運用にします。イベント駆動の構成で監視や障害調査の仕組みまで含めて設計を見直したい場合は、インフラ構築（AWS・Google Cloud・Azure）でご相談いただけます。

よくある質問

EventBridgeのログと発火しないルールの調査でよく出る疑問に、公式ドキュメントの記載をもとに答えます。

EventBridgeのログはどこで見られますか？

既定ではどこにも出ていません。バスのログ記録かCloudWatch Logsターゲットを設定するまで記録は無く、障害が起きてから有効にしても過去分は読めません。過去の状況は、設定なしで出ているCloudWatchメトリクスのAWS/Events名前空間で確認します。

スケジュールで動かすルールが指定した時刻に動きません。何を確認しますか？

まず時刻の基準を確認します。ルールのScheduleExpressionはUTCで解釈されるため、日本時間の9時に動かしたいならcron(0 0 * * ? *)と書きます。ルールは指定した分の中で動き、秒単位の精度はありません。タイムゾーンを指定したい、1回限りの実行をしたいといった要件なら、EventBridge Schedulerのほうが向いています。Schedulerの書き方はEventBridge SchedulerのAPIで解説しています。

ルールは動いているのにLambda関数が起動しないのはなぜですか？

多くはLambda側のリソースベースポリシーの不足です。aws lambda get-policyで、プリンシパルevents.amazonaws.comと対象ルールのARNを条件にしたlambda:InvokeFunctionの許可があるかを確認します。公式のトラブルシューティングによると、ポリシーにSourceAccountが入っているとEventBridgeから呼べないため削除が必要です。エイリアスやバージョンを呼んでいる場合は--qualifierを付けて確認します。