How do I troubleshoot HTTP 502 and HTTP 500 status code (server-side) errors from AWS Lambda?
Last updated: 2021-09-09
When I try to invoke my AWS Lambda function, the request fails with a 502 or 500 server-side error. How do I troubleshoot these errors?
First, identify the specific Lambda Invoke API error that you receive. Then, follow the troubleshooting steps listed for that error.
Note: For a list of possible errors and their descriptions, see Errors in the Lambda Invoke API reference.
Make sure that invocations and other API actions that operate on your function occur when the function is in the Active state only. For more information, see Monitoring the state of a function with the Lambda API and Tracking the state of AWS Lambda functions.
Confirm that you specified the correct Amazon VPC security group ID in your Lambda function configuration. For more information, see Configuring a Lambda function to access resources in a VPC.
Check the permissions on your Lambda deployment package. For more information, see How do I troubleshoot Lambda "permission denied" or "unable to import module" errors when uploading a deployment package?
Also, confirm that you created the deployment package file correctly. For more information, see Lambda deployment packages.
The KMSAccessDeniedException error usually occurs when a Lambda function's IAM role is deleted and then recreated with the same name. If this is what happened, configure a new IAM role for the function. Then, deploy the function again and reconfigure the previous IAM role.
For more information, see Using key policies in AWS KMS.
Verify that the KMS key is enabled. For more information, see Enabling and disabling keys.
For more information, see How key state affects use of a customer managed key.
The KMS key specified in your request must be in the same AWS Region and account as your Lambda function. If the Region is different, then use another KMS key (or create a new KMS key) in the same Region.
Lambda reclaims network interfaces that aren't in use. This action can place a function in an inactive state. When a function that is inactive is invoked, the function enters a pending state while VPC network access is restored. The first invocation and all others that occur while the function is in a pending state fail and then produce a ResourceNotReadyException error.
To resolve the error, wait until the VPC connection is restored. Then, invoke the Lambda function again.
Sometimes the Lambda service itself can encounter an internal error. If you get a 500 error, check the AWS Service Health Dashboard to determine if Lambda is unavailable. For more information, see Is AWS down?
If Lambda is available, retry the request to invoke your Lambda function.
A subnet's size is defined by its CIDR block. Be sure that the CIDR blocks that you specify in your Amazon VPC have enough free IP addresses for your Amazon VPC-enabled Lambda function's requirements. For more information, see VPC and subnet sizing.
You have exceeded the maximum limit for Hyperplane elastic network interfaces for your account
The default maximum number of Hyperplane elastic network interfaces or each virtual private cloud (VPC) is 250. For information on how to request a limit increase, see Service Quotas.