MENU
category

EventBridgeのLambdaトリガーが表示されない?実行ロールとリソースベースポリシーの確認手順

EventBridgeのルールでLambdaをターゲットにしたのに、Lambdaコンソールのトリガー一覧から関連が見つからないことがあります。この場合、トリガーの表示だけで設定漏れと判断せず、ルールのターゲットと呼び出し許可を確認します。

この記事では、同一アカウント内のEventBridgeルールからLambdaを呼び出す構成を扱います。EventBridge SchedulerやPipesは別の仕組みなので、最初にどの機能を使っているかを確認してください。

目次

Lambda呼び出しは3つに分けると整理できる

  1. ルール:どのイベントに反応するかを決める。
  2. ターゲット:一致したイベントをどのLambda関数へ送るかを決める。
  3. 許可:EventBridgeがそのLambda関数を呼び出せるようにする。

Lambda側のトリガー一覧は、関連を確認するための表示です。ルールやターゲット、許可の実体がすべてこの一覧だけに保存されているわけではありません。

呼び出しの許可には2つの方式がある

EventBridgeルールからLambdaを呼ぶ際は、IAM実行ロールまたはLambdaのリソースベースポリシーを使用できます。現在の仕様はEventBridgeのリソースベースポリシーの公式資料に記載されています。

方式 確認する場所 確認内容
Lambdaのリソースベースポリシー Lambda関数のアクセス許可 EventBridgeによる呼び出しと、対象ルールの条件
EventBridgeの実行ロール ルールのターゲット設定とIAMロール RoleArn、ロールの信頼関係、lambda:InvokeFunction

リソースベースポリシーによるルールとの関連は、Lambdaのトリガー表示に反映されます。一方、実行ロールで許可し、同じ関連のリソースベースポリシーがない構成では、Lambda側の一覧に表示されない場合があります。

したがって、表示されないことと、呼び出せないことは別々に確認します。画面へ表示させるためだけに同じルールを作り直す前に、現在の設定を調べましょう。

1. EventBridge側でターゲットとRoleArnを確認する

対象ルールが有効になっているか、イベントバスとイベントパターンが想定どおりかを確認します。次に、ターゲットのLambda ARNを確認します。関数名が似ている場合や、エイリアスを使っている場合はARNまで照合してください。

CLIでターゲット一覧を確認する読み取り専用コマンドの例です。プロファイル、リージョン、ルール名、バス名は実際の環境に置き換えます。

aws events list-targets-by-rule --profile example --region ap-northeast-1 --rule example-rule --event-bus-name default

ターゲットに RoleArn がある場合は、そのロールの権限も確認します。Lambdaの実行ロールと混同しないようにしてください。EventBridgeの実行ロールは「関数を呼ぶため」、Lambdaの実行ロールは「関数のコードがAWSサービスを利用するため」のものです。

2. 選択した方式の呼び出し許可を確認する

リソースベースポリシーを使用する場合は、Lambda側でEventBridgeサービスからの lambda:InvokeFunction が許可され、対象ルールのARNなどの条件が一致しているかを確認します。関数のエイリアスをターゲットにしているなら、許可を確認する対象も合わせます。

実行ロールを使う場合は、EventBridgeが引き受けられる信頼関係と、対象Lambdaへの呼び出し権限を確認します。具体的な考え方はターゲットへ送信するためのIAMロールを参照できます。

両方の方式を無条件に追加する前に、どちらで許可する設計なのかを明確にします。既存の設定を把握してから修正すると、不要な許可や管理箇所を増やさずに済みます。

3. 実行されたかはメトリクスとログで確認する

設定を確認した後は、想定するイベントが実際にルールへ届いたか、ターゲット呼び出しが失敗していないか、Lambdaが処理を開始したかを順に確認します。

  • イベントパターンに合うイベントが発生しているか。
  • EventBridge側の呼び出し・失敗メトリクスに変化があるか。
  • LambdaのInvocationsやErrorsが記録されているか。
  • CloudWatch Logsに処理開始や例外が出ているか。

ログがない場合は、ログ出力権限やアプリケーション側の実装も関係するため、ログだけで未実行と断定しません。トリガー表示、呼び出し結果、関数内の処理結果を分けて調べると、原因を絞りやすくなります。

どちらのコンソールから設定すればよい?

同じルール、ターゲット、許可を構成するなら、操作を始める画面だけで実行の意味が変わるわけではありません。イベントの振り分けをまとめて管理するならEventBridge側、関数との関連を確認しながら作業するならLambda側など、運用の管理単位に合わせて選びます。

また、1つのLambda関数を複数のイベント源から呼び出すことは可能です。「Lambda側はトリガーが1つしか設定できない」という前提で、設定方法を限定する必要はありません。

Schedulerの表示はルールと分けて考える

定時実行にEventBridge Schedulerを使う場合は、Schedulerの実行ロールとスケジュールを確認します。現在のLambda公式資料では、Lambdaを対象とするSchedulerのスケジュールはトリガー欄のSchedulerラベルに表示されると説明されています。一部の暗号化・ターゲット構成には例外があります。

この表示仕様を、EventBridgeルールの表示へそのまま当てはめないようにします。詳しくはSchedulerでLambdaを実行する公式手順を確認してください。

関連する記事

よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!

この記事を書いた人

目次