本記事は 春のスキルアップ応援フェア2026 4/29付の記事です。 |
こんにちは、クラウドサービス関連の業務をしている藪内です。
本記事では、AWSコンソールでAWS LambdaのAmazon SQSをイベントソースとするトリガーの情報を閲覧するために必要なIAM権限についてまとめています。
Lambdaのトリガーを設定できるIAMロールを業務で作成しようとしたのですが、
作成したIAMロールでトリガーのページを開いても、閲覧できず、何が不足しているのか全くわかりませんでした。
この問題をどう解決したのか、どのIAM権限が必要だったのかを紹介します。
結論
お急ぎの方はここだけ読んでください。
以下のポリシーをIAMロールにアタッチすることで、Lambdaのトリガーに関する情報がコンソールに表示されるようになります。
ポイントはlambda:GetPolicyの追加です。一見トリガーの表示とは無関係に見えますが、この権限の追加が必要でした。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Statement1",
"Effect": "Allow",
"Action": [
"lambda:ListFunctions"
],
"Resource": "*"
},
{
"Sid": "Statement2",
"Effect": "Allow",
"Action": [
"lambda:GetFunction",
"lambda:GetFunctionConfiguration",
"lambda:GetPolicy"
],
"Resource": [
"*"
]
},
{
"Sid": "Statement3",
"Effect": "Allow",
"Action": [
"lambda:ListEventSourceMappings"
],
"Resource": "*"
},
{
"Sid": "Statement4",
"Effect": "Allow",
"Action": [
"lambda:GetEventSourceMapping"
],
"Resource": [
"<イベントソースマッピングのARN>"
]
}
]
}
問題の状況
特定の作業用IAMロールに対して、Lambdaのトリガーに関する情報をAWSコンソールで閲覧できる最小権限を付与しようとしました。
lambda:ListEventSourceMappings や lambda:GetEventSourceMapping など、「トリガーの表示に必要そうな権限」を追加してコンソールを確認しましたが、下図のようにトリガーのタブはローディング状態が続き、トリガーの情報を閲覧できませんでした。
生成AIに尋ねた
不足しているIAM権限を追加するために、まずは生成AIに
と入力しました。すると、生成AIは以下の5つのIAM権限が必要であると出力しました。
しかし、実際にそれらを付与しても、状況は変わりませんでした。
- lambda:GetFunction
- lambda:ListFunctions
- lambda:ListEventSourceMappings
- sqs:ListQueues
- sqs:GetQueueAttributes
後から気づいたことですが、入力を
とすることで、不足していたlambda:GetPolicyも出力されました。
トリガーにSQSを設定していることを記述していなければ、十分なIAM権限を早く知ることができていました。
試行錯誤
検索エンジンで「Lambda」や「トリガー」、「IAM」などをキーワードとして検索しましたが、ヒントになる記事は見つかりませんでした。
そこで、IAM権限の地道な絞り込みで解決することにしました。
手順は以下のとおりです。
- Lambda のすべての権限(lambda:*)を付与し、Lambdaの権限さえあればトリガーの情報が表示されることを確認した
- Lambda の読み取り系権限をすべて付与し、トリガーの情報が表示されることを確認して候補を絞り込んだ
- 不要な権限を一つずつ除外し、表示に必要な権限を特定した
この作業の中で不足していると判明したのがlambda:GetPolicyでした。
lambda:GetPolicyとは
lambda:GetPolicyについて、AWSの公式APIリファレンスに以下のように書かれています。
Returns the resource-based IAM policy for a function, version, or alias.
(関数、バージョン、エイリアスのリソースベースの IAM ポリシーを返します。)
参照:GetPolicy – AWS Lambda
Lambda関数におけるリソースベースのIAMポリシーとは、「AWSサービスやアカウントがこのLambda関数を呼び出せるか」を定義するものです。
With resource-based policies, you can specify who has access to the resource and what actions they can perform on it.
(リソースベースのポリシーによって、何がリソースにアクセスでき、それらがリソースでどのようなアクションを実行できるかを指定できます。)
参照:アイデンティティベースおよびリソースベースのポリシー – AWS Identity and Access Management
lambda:GetPolicyが必要であったことから、Lambda画面でトリガーのタブを開くと、内部でlambda:GetPolicyのAPIが呼び出され、リソースベースのIAMポリシーが取得されていることがわかりました。
Amazon S3のようなLambdaを直接呼び出すサービスをトリガーに設定した場合だけでなく、SQSのようにLambdaがメッセージをポーリングして動作し、
Lambdaが直接呼び出されない場合にもlambda:GetPolicyのAPIが使用されているようです。
まとめ
今回は、AWSコンソールでAWS LambdaのAmazon SQSをイベントソースとするトリガーの情報を閲覧するために必要なIAM権限について探った経験を紹介しました。
以下の6つの権限を付与することによって、トリガーの情報をコンソールで閲覧できるIAMロールを作成できました。
- lambda:ListFunctions
- lambda:GetFunction
- lambda:GetFunctionConfiguration
- lambda:GetPolicy
- lambda:ListEventSourceMappings
- lambda:GetEventSourceMapping
今回の経験から、AWSコンソールで特定の情報を閲覧するのに必要な権限は、画面上で扱う情報の種類だけからは判断できないことを学べました。
生成AIへの質問や既存のWeb記事で解決できず、lambda:*で全権限を付与した状態から必要な権限を絞り込むという、地道な方法で解決しました。
しかし、今後はこのような地道な方法では時間がかかるため、まずは、AWS CloudTrail(AWSコンソールやCLIの操作ログを記録しているサービス)を用いてコンソールが内部でどのAPIを呼び出しているかをログから追跡して解決しようと思います。
最後までご覧いただきありがとうございました。




