Lambda 統合 API をクローンした際に発生する 500 エラーの原因と対処法をまとめてみた
2025.05.19こんにちは。テクニカルサポートチームのShiinaです。
はじめに
API Gateway を利用して API の開発や検証を行う際、既存の API をクローンして新しい環境を構築することができます。
今回、プライベート API を作成するために、既存の Lambda 関数と統合された API をクローンしました。
しかしながら、クローンした API がうまく動作しない事象に遭遇し、原因特定に時間を要しました。
原因や対処方法についてまとめてみましたので同じ事象に遭遇した方の助けになれば幸いです。
困っていた事象
既存の Lambda 関数と統合された API をクローンして新たに API を作成をしました。
しかし、クローンした API のエンドポイントにアクセスすると、500 Internal Server Error が返されました。
curl -X GET -I https://{rest-api-id}.execute-api.ap-northeast-1.amazonaws.com/dev/data?id=111
HTTP/1.1 500 Internal Server Error
Server: Server
Date: Mon, 19 May 2025 05:01:00 GMT
Content-Type: application/json
Content-Length: 36
Connection: keep-alive
x-amzn-RequestId: XXXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXX
x-amzn-ErrorType: InternalServerErrorException
x-amz-apigw-id: XXXXXXXXX
結論
Lambda 統合を含む既存 API をクローンした場合、Lambda 関数のリソースベースのポリシーが自動で設定されず、Internal Server Error が発生します。
統合リクエストを再設定してデプロイするか、AWS CLI コマンドを利用して Lambda 関数のリソースポリシーを手動で付与する必要があります。
なお、AWS Lambda の管理コンソールからトリガーを追加する方法では動作が異なるため、根本的な解決につながらない可能性があります。
エラーの調査方法
Internal Server Error のエラーは API Gateway の実行ログから調査することができます。
前提として、ログ記録の設定が有効になっている必要があります。
設定方法については、以下のドキュメントをご参照ください。
今回発生した事象では次のエラーメッセージが実行ログに記録されていました。
(中略)
(XXXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXX) Execution failed due to configuration error: Invalid permissions on Lambda function
(XXXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXX) Method completed with status: 500
(中略)
原因
Lambda 関数に対する適切な実行権限が設定されていないことが原因です。
API Gateway から Lambda 関数を呼び出そうとした際に、実行権限がないため呼び出しに失敗し、Internal Server Error が発生します。
API を Lambda 関数と統合する場合、マネジメントコンソールからメソッド作成を行う際には Lambda 関数のリソースベースのポリシーを自動で更新してくれます。
しかしながら、クローンで作成したメソッドに対しては Lambda 関数のリソースベースのポリシーは自動では更新されません。
今回、 API 名 MyAPI をクローン元としてPrivateMyAPIを新たに作成しました。
作成後 Lambda 関数のトリガーを確認してみると、作成した PrivateMyAPI のトリガーが設定されていないことがわかります。
対処方法
Lambda 関数のリソースベースのポリシーを設定する方法には以下のような手段があります。
自動でポリシーを付与する
統合リクエストを再設定してデプロイすることで、ポリシーを自動的に更新できます。
-
API Gateway サービスのナビゲーションペインから [API] を選択します。
-
クローンで作成された API を選択します。
-
ナビゲーションペインから リソース を選択します。
-
リソースパスから Lambda 統合しているメソッドタイプ（例：GET、POST など）を選択します。
-
統合リクエストタブより、[編集]を選択します。
-
何もせずそのまま保存を選択します。
-
[API をデプロイ]を選択します。
-
ステージを選択の上、[デプロイ]を選択します。
手動でポリシーを付与する
以下の AWS CLI コマンドを利用して設定できます。
aws lambda add-permission \
--function-name {FunctionName} \
--statement-id apigateway-access \
--action lambda:InvokeFunction \
--principal apigateway.amazonaws.com \
--source-arn arn:aws:execute-api:ap-northeast-1:XXXXXXXXXXXX:{rest-api-id}/*/{methodtype}/{path}
リソースベースポリシー設定の確認
Lambda 関数のリソースベースのポリシーが設定されたことを確認します。
- Lambda サービスのナビゲーションペインから [関数] を選択します。
- 関数一覧から API Gateway に統合リクエスト設定している Lambda 関数を選択します。
- 設定タブよりトリガーを選択します。
- リソースベースのポリシーに、対象の API Gateway の API 名、エンドポイント、ステージ、メソッド、リソースパスが含まれていることを確認します。
動作確認
リソースベースのポリシーを設定後、APIリクエストを行い、動作確認を行います。
curl -X GET -I https://{rest-api-id}.execute-api.ap-northeast-1.amazonaws.com/dev/data?id=111
HTTP/1.1 200 OK
Server: Server
Date: Mon, 19 May 2025 05:02:22 GMT
Content-Type: application/json
Content-Length: 36
Connection: keep-alive
x-amzn-RequestId: XXXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXX
x-amz-apigw-id: XXXXXXXXX
X-Amzn-Trace-Id: Root=1-XXXXXXX-XXXXXXXXXXXXXXXXXX;Parent=5054033626daaa1a;Sampled=0;Lineage=1:7bc52c8e:0
500 Internal Server Error は解消され、200 OK が返るようになりました。
Lambda の管理コンソールから既存 API をトリガー追加するとどうなるか？
AWS Lambda の管理コンソールで[トリガーを追加]を選択すると API Gateway をトリガーとして追加するオプションが表示されます。
既存の API を指定してトリガーを追加することも可能なため、この方法で問題が解決できるように思えるかもしれません。
しかし、既存の API に Lambda 関数をアタッチした場合、API Gateway は Lambda 関数の名前に基づいて新しいリソースパスを作成します。
さらにそのパスに ANY メソッドが追加され、Lambda 関数を呼び出すように設定されます。
API をクローンする場合は既存のリソースパスを変更せずにそのまま利用するケースが一般的です。
そのため、この方法では問題の根本的な解決にはならない可能性があり、注意が必要です。
まとめ
Lambda 統合を含む既存 API をクローンした場合、Lambda 関数のリソースベースのポリシーは自動的には設定されません。
統合リクエストの再設定した上でデプロイもしくは AWS CLI コマンドを利用して Lambda 関数のリソースポリシーを付与する必要があります。
AWS Lambda の管理コンソールで対処では根本的な解決にならない場合があるので注意しましょう。
参考
