Troubleshoot execution issues in Lambda
When the Lambda runtime runs your function code, the event might be processed on an instance of the function that's been processing events for some time, or it might require a new instance to be initialized. Errors can occur during function initialization, when your handler code processes the event, or when your function returns (or fails to return) a response.
Function execution errors can be caused by issues with your code, function configuration, downstream resources, or permissions. If you invoke your function directly, you see function errors in the response from Lambda. If you invoke your function asynchronously, with an event source mapping, or through another service, you might find errors in logs, a dead-letter queue, or an on-failure destination. Error handling options and retry behavior vary depending on how you invoke your function and on the type of error.
When your function code or the Lambda runtime return an error, the status code in the response from Lambda is 200
OK. The presence of an error in the response is indicated by a header named X-Amz-Function-Error. 400
and 500-series status codes are reserved for invocation
errors.
Lambda: Execution takes too long
Issue: Function execution takes too long.
If your code takes much longer to run in Lambda than on your local machine, it may be constrained by the memory or processing power available to the function. Configure the function with additional memory to increase both memory and CPU.
Lambda: Logs or traces don't appear
Issue: Logs don't appear in CloudWatch Logs.
Issue: Traces don't appear in AWS X-Ray.
Your function needs permission to call CloudWatch Logs and X-Ray. Update its execution role to grant it permission. Add the following managed policies to enable logs and tracing.
-
AWSLambdaBasicExecutionRole
-
AWSXRayDaemonWriteAccess
When you add permissions to your function, perform a trivial update to its code or configuration as well. This forces running instances of your function, which have outdated credentials, to stop and be replaced.
Note
It may take 5 to 10 minutes for logs to show up after a function invocation.
Lambda: Not all of my function's logs appear
Issue: Function logs are missing in CloudWatch Logs, even though my permissions are correct
If your AWS account reaches its CloudWatch Logs quota limits, CloudWatch throttles function logging. When this happens, some of the logs output by your functions may not appear in CloudWatch Logs.
If your function outputs logs at too high a rate for Lambda to process them, this can also cause log outputs not to appear in CloudWatch Logs. When Lambda can't send logs to CloudWatch at the rate your function produces them, it drops logs to prevent the execution of your function from slowing down. Expect to consistently observe dropped logs when your log throughput exceeds 2 MB/s for a single log stream.
If your function is configured to use JSON formatted logs, Lambda tries to send a logsDropped event to CloudWatch Logs when it drops logs. However, when CloudWatch throttles your function's logging, this event might not reach CloudWatch Logs, so you won't always see a record when Lambda drops logs.
To check if your AWS account has reached its CloudWatch Logs quota limits, do the following:
-
Open the Service Quotas console
. -
In the navigation pane, choose AWS services.
-
From the AWS services list, search for Amazon CloudWatch Logs.
-
In the Service quotas list, choose the
CreateLogGroup throttle limit in transactions per second,CreateLogStream throttle limit in transactions per secondandPutLogEvents throttle limit in transactions per secondquotas to view your utilization.
You can also set CloudWatch alarms to alert you when your account utilization exceeds a limit you specify for these quotas. See Create a CloudWatch alarm based on a static threshold to learn more.
If the default quota limits for CloudWatch Logs aren't enough for your use case, you can request a quota increase.
Lambda: The function returns before execution finishes
Issue: (Node.js) Function returns before code finishes executing
Many libraries, including the AWS SDK, operate asynchronously. When you make a network call or perform another operation that requires waiting for a response, libraries return an object called a promise that tracks the progress of the operation in the background.
To wait for the promise to resolve into a response, use the await keyword. This blocks your handler
code from executing until the promise is resolved into an object that contains the response. If you don't need to
use the data from the response in your code, you can return the promise directly to the runtime.
Some libraries don't return promises but can be wrapped in code that does. For more information, see Define Lambda function handler in Node.js.
AWS SDK: Versions and updates
Issue: The AWS SDK included on the runtime is not the latest version
Issue: The AWS SDK included on the runtime updates automatically
Runtimes for scripting languages include the AWS SDK and are periodically updated to the latest version. The current version for each runtime is listed on runtimes page. To use a newer version of the AWS SDK, or to lock your functions to a specific version, you can bundle the library with your function code, or create a Lambda layer. For details on creating a deployment package with dependencies, see the following topics:
Python: Libraries load incorrectly
Issue: (Python) Some libraries don't load correctly from the deployment package
Libraries with extension modules written in C or C++ must be compiled in an environment with the same processor architecture as Lambda (Amazon Linux). For more information, see Working with .zip file archives for Python Lambda functions.
Java: Your function takes longer to process events after updating to Java 17 from Java 11
Issue: (Java) Your function takes longer to process events after updating to Java 17 from Java 11
Tune your compiler using the JAVA_TOOL_OPTIONS parameter. Lambda runtimes for Java 17 and later
Java versions change the default compiler options. The change improves cold start times for short-lived functions, but the
previous behavior is better suited to computationally intensive, longer-running functions. Set
JAVA_TOOL_OPTIONS to -XX:-TieredCompilation to revert to the Java 11 behavior. For more
information about the JAVA_TOOL_OPTIONS parameter, see Understanding the JAVA_TOOL_OPTIONS environment variable.
