Lambda のアクセス権に関する問題をトラブルシューティングする方法を教えてください。

簡単な説明

Lambda 関数のアクセス権の問題は、次の理由により発生します。

• Lambda 関数には、コード内のアクションを実行するアクセス権がありません。
• Lambda 関数の呼び出しを行う AWS サービスには、関数を呼び出すための十分なアクセス権限がありません。
• ユーザーアカウントには、Lambda リソースを作成、更新、削除するための適切なアクセス権がありません。
• Amazon Elastic Compute Cloud (Amazon EC2) のアクセス権がないため、Lambda にはエラスティックネットワークインターフェイスを作成する権限がありません。

解決方法

アクセス権に関する考慮事項

• Lambda 関数の実行ロール は、AWS のサービスとリソースにアクセスするためのアクセス権を関数に付与するAWS ID およびアクセス管理 (IAM) ロールです。関数を作成するときにこのロールを指定すると、関数が呼び出されたときに Lambda がそのロールを引き受けます。Amazon CloudWatch にログを送信し、トレースデータを AWS X-Ray にアップロードする権限を持つ実行ロールを作成できます。
• Lambda 関数の実行ロールへのアクセス権はいつでも追加または削除できます。別のロールを使用するように Lambda 関数を設定することもできます。関数が AWS SDK で呼び出すすべての AWS サービスのアクセス権を追加します。次に、Lambda がオプション機能を有効にするために使用する AWS サービスのアクセス権を追加します。
• Lambda 関数を作成するときに、実行ロールを指定します。新しい Lambda 関数を呼び出すと、Lambda は実行ロールを引き継いで関数に一時的な認証情報を自動的に提供します。関数コードで sts: AssumeRole を呼び出す必要はありません。Lambda 関数にアクセス権を追加するときは、関数のコードまたは設定も更新します。関数のコードまたは構成を更新すると、関数の実行中のインスタンスは強制的に停止され、置き換えられる可能性があります。詳細については、「Lambda のリソースベースのポリシーを使用する」を参照してください。
• リソースベースのポリシーを使用して、各リソースの使用許可を他の AWS アカウントまたは組織に付与します。リソースベースのポリシーでは、ユーザーに代わって Lambda 関数を呼び出すアクセス権を AWS サービスに与えることができます。
• Lambda 関数を呼び出したり管理したりするには、アカウントにアクセス権を付与します。リソースベースのポリシーを 1 つ作成して、AWS Organizations 内の組織全体に権限を付与します。リソースベースのポリシーを使用して AWS サービスに呼び出し権限を付与し、指定されたアカウントアクティビティに応じて関数を呼び出せるようにします。
• リソースベースのポリシーは、単一の関数、バージョン、エイリアス、またはレイヤーバージョンに適用されます。リソースベースのポリシーは、1 つ以上の AWS サービスとアカウントにアクセス権を付与します。複数のリソースにアクセスする必要がある信頼できるアカウントや、リソースベースのポリシーでサポートされていない API アクションを使用する場合は、クロスアカウントロールを使用してください。詳細については、Lambda のアクセス権を参照してください。
• IAM アイデンティティベースのポリシーを使用して、アカウントのユーザーに Lambda へのアクセス権を付与します。ID ベースのポリシーは、ユーザーに直接適用することも、ユーザーに関連付けられているグループやロールに適用することもできます。別のアカウントのユーザーに、アカウントのロールを引き受け、Lambda リソースにアクセスする権限を付与します。
• Lambda は、Lambda API アクションへのアクセスを許可する AWS 管理ポリシーを提供します。管理ポリシーでは、Lambda リソースの開発と管理に使用される他の AWS サービスへのアクセス権を許可する場合があります。Lambda はこれらの管理ポリシーを必要に応じて更新し、ユーザーが新機能のリリース時に確実にアクセスできるようにします。詳細については、「Lambda のアイデンティティベースの IAM ポリシー」を参照してください。

トラブルシューティング手順

1.    Lambda 関数が別の関数または別の AWS サービスを呼び出すはずなのに失敗する場合は、Lambda 実行ロールを確認してください。
詳細については、「 Lambda 実行ロール」を参照してください。

2.    AWS のサービスまたはユーザーに lambda: InvokeFunction アクションのアクセス権が設定されていることを確認します。
詳細については、「AAWS Lambda のアクション、リソース、および条件キー」をご参照ください。

3.    クロスアカウントのシナリオでは、ソースアカウントと宛先アカウントにアクセスして、Lambda 関数を呼び出す IAM ロールを引き受けるために必要な権限を確認します。
詳細については、「別の AWS アカウントで IAM ロールを引き受けるように Lambda 関数を設定するには?」を参照してください。

4.    VPC に接続するには、Lambda 関数の実行ロールに次の権限が必要です。
ec2:CreateNetworkInterface
ec2:DescribeNetworkInterfaces
ec2:DeleteNetworkInterface

5.    非稼働権限セットと作業中の設定を比較して、権限の問題を解決します。AWS ドキュメントを参照して権限を確認することもできます。

6.    ソースアカウントには、Lambda 関数を呼び出す権限が必要です。Lambda 関数に必要なイベントソースマッピング権限を確認してください。イベントソースマッピングでは、関数の実行ロールの許可を使用して、イベントソース内の項目を読み取り、管理します。注： 許可、イベント構造、設定、およびポーリング動作は、イベントソースによって異なります。詳細については、「 AWS Lambda の ID とアクセスのトラブルシューティング」を参照してください。

7.    AWS CloudTrail ログをチェックして、Lambda に行われた API 呼び出しを追跡してください。CloudTrail によって収集された情報を確認して、次の点を判断してください。
Lambda に対して行われたリクエスト。
リクエストが行われた IP アドレス。
誰がリクエストしたのか。
リクエストが行われた日時。
詳細については、「AWS CloudTrail を使用した Amazon Route 53 API コールのログ記録」を参照してください。

8.    それでも問題が解決しない場合は、AWS サポートに問い合わせてください。ケースで次の情報を提供してください。

• Lambda 関数の ARN。
• Lambda 関数のワークフローには、AWSサービスがすべて含まれています。
• 問題が断続的か継続的かに関する詳細。
• 問題がクロスアカウントシナリオかどうかについての詳細。
• 関連する権限や IAM ロール名。
• 問題が発生したときの CloudWatch ログを .txt 形式で完成させます。これらの CloudWatch ログは、タイムアウトの問題、Init Duration、許可の問題を含む Lambda 関数のエラーを特定するために使用されます。
• 問題の正確なタイムスタンプ (タイムゾーンまたはタイムスタンプ付き (UTC))。

注: セキュリティとプライバシー上の理由から、AWS サポート担当者はお客様の CloudWatch ログにアクセスできません。

---

関連情報

AWS Lambda でリソースベースのポリシーを使用して、AWS のサービスにアクセス権を許可するにはどうすればよいですか?

別の AWS アカウントで IAM ロールを引き受けるように Lambda 関数を設定するにはどうすればよいですか?