Get Hands-on with Amazon EKS - Workshop Event Series

Whether you're taking your first steps with Kubernetes or you're an experienced practitioner looking to sharpen your skills, our Amazon EKS workshop series delivers practical, real-world experience that moves you forward. Learn directly from AWS solutions architects and EKS specialists through hands-on sessions designed to build your confidence with Kubernetes. Register now and start building with Amazon EKS!

How do I troubleshoot Lambda function "Rate exceeded" and "TooManyRequestsException" throttling errors?

4 minute read

My AWS Lambda function returns "Rate exceeded" and "TooManyRequestsException" throttling errors.

Resolution

Verify which resource throttled

Throttle errors might not occur from your Lambda function. Throttles can occur on API calls across your function's invocation.

To confirm what resource throttled, check your Amazon CloudWatch Logs and metrics for throttling errors. If there are no Lambda Throttles metrics, then the throttling occurs on API calls in your Lambda function code.

Check your function logs and code for any throttled API calls

If API calls are throttled, then make sure that you use exponential backoff in your code to retry the API calls.

Note: If you need a higher transactions per second (TPS) quota for an API call, then request a service quota increase. Not all quotas are adjustable.

Check your functions concurrency CloudWatch metrics

Check the ConcurrentExecutions metric for your function in the AWS Region where throttling occurs.

View the Maximum statistic for ConcurrentExecutions and the Sum statistic for Throttles. Verify that the maximum ConcurrentExecutions are close to your account-level concurrency quota in the Region, along with the related data points in the Throttles graph.

Check the concurrency quota

Check if you've exceeded the concurrency scaling rate for your function's Region. Your concurrency scaling rate is 1,000 execution environment instances every 10 seconds. For more information, see Lambda scaling behavior.

On the Metrics page for Lambda in the CloudWatch console, reduce the graph's time range to 1 minute. If you're limited by burst concurrency limits, then you see a spike of Throttles that corresponds to a stair-step pattern of ConcurrentExecutions on the graph.

To avoid burst concurrency limits, you can configure provisioned concurrency. You can also request a concurrency limit increase for your Lambda function.

Check for spikes in duration metrics for your function

Concurrency depends on function duration. If your function code takes too long to complete, then there might not be enough compute resources.

Review the Max Memory Used field in your execution logs and compare the value with the function's configured memory setting. If the Max Memory Used is close to the configured memory, then your function is usually memory-bound. For more information, see Determining the appropriate memory setting for a Lambda function.

Configure reserved concurrency

Confirm that you configured reserved concurrency for your function. Reserved concurrency acts as a concurrency boundary for the function and also protects the function from other functions that might consume unreserved concurrency. While reserved concurrency can mitigate function throttling, it can also inadvertently throttle the function.

Use the Lambda console to check the setting for reserved concurrency. If reserved concurrency isn't configured, then the function uses unreserved concurrency. When invocations with functions exceed the unreserved concurrency, throttling occurs.

Note: If you configured a function with zero reserved concurrency, then the function throttled because it can't process any events. Make sure that you increase the value to a number greater than zero.

To configure or increase reserved concurrency, see Configuring reserved concurrency for a function. To troubleshoot reserved concurrency issues, see How do I troubleshoot Lambda reserved concurrency issues?

Use exponential backoff

To avoid throttling errors, use exponential backoff and retries when you make an API call. It's a best practice to use exponential backoff in your application that makes API calls for your Lambda function.

For more information, see Exponential backoff and jitter and Retry behavior. Make sure to distribute your API calls over time. Schedule actions with randomization so that they spread out over time.