AWS Lambda Limits

Understanding hard limits, soft limits and best practices

Serverless application architecture is the cornerstone of cloud IT applications. AWS Lambda has made it possible for developers to concentrate on business logic and set aside the worry of managing server provisioning, OS patching, upgrades, and other infrastructure maintenance work.

However, designing serverless applications around AWS Lambda requires care, especially finding workarounds for AWS Lambda limitations. AWS Lambda limits the amount of compute and storage resources that you can use to run and store functions. AWS has deliberately put several Lambda limits that are either soft or hard to prevent misuse or abuse. It also provides guardrails so that you follow best practices of the Lambda function design.

In this article, we will take a closer look into all types of Lambda limits defined by AWS and understand their effect in different use cases. Also, we’ll examine workarounds and solutions available to overcome these limits for valid use cases.

AWS Lambda limitations come in two forms: Soft Limits and Hard Limits.

Soft Limits

Soft limits are defined with default values. Lambda soft limits are per-region and can be increased by putting requests to the AWS support team.

Concurrent Executions Limit

In Lambda, scaling is achieved using the concurrent execution of Lambda instances. If a Lambda execution environment cannot fulfill all the requests for a given time, it spins up another instance to handle the remaining requests. However, spinning up new instances infinitely may cause high costs and can be misused, so a default AWS Lambda limit concurrency of 1,000 was put in place by AWS.

This limit is configured at the account level and shared with all the functions in the account. Having this limit protects against the unintentional use at the account level but a function inside an account may also overuse the concurrency and affect the execution of other function instances. We’ll discuss overcoming that in the best practices section.

Function and Layer Storage

When you deploy a function in the Lambda service, it uses storage to keep the function code with dependencies. Lambda services keep the code for every version. When you update this function with a newer version, it adds the new version code to the storage.

AWS has kept the storage limit to 75 GB so ensure you follow the best practice of cleaning up the old version code. 75 GB seems to be a very high limit but over the years, it might be exhausted with the frequent updates to the code.

Elastic Network Interface per VPC

There are use cases where a Lambda function needs VPC resources such as RDS -mysql. In that case, you need to configure the VPC subnet and AZs for the Lambda function. The Lambda function connects to these VPC resources through the Elastic Network Interface (ENI).

In the past, each Function instance used to need a new ENI to connect to a VPC resource so there was a chance of hitting the threshold of 250 (the default configured by AWS) very easily. But, with the latest feature of Hyperplane, VPC networking has improved and requires less ENIs for the communication between a function and VPC resources. Mostly, this threshold is rarely hit in most use cases.

Hard Limits

Hard limits are ones that cannot be increased, even if you make a request to AWS. These Lambda limits apply to function configuration, deployments, and execution. Let’s review a few of the important limits in detail.

AWS Lambda Memory Limit

AWS Lambda is meant for short functions to execute for short durations so the AWS Lambda memory limit has been kept to a max of 3GB. It starts at 128 MB and can be increased by 64 MB increments.

This memory is mostly sufficient for event-driven business functions and serves the purpose. However, there are times when you need CPU-intensive or logical calculation-based workloads and may cause timeout errors due to not being able to complete the execution in time. There are several solutions available to overcome this and we will talk about those in the best practices section.

AWS Lambda Timeout Limit

As discussed in the AWS Lambda memory limit section above, a function might time out if it doesn’t finish the execution within the allotted time. That time is 15 mins (900 seconds). This is a hard limit in which a function has to complete the execution or it will throw a timeout error.

This limit is very high for synchronous flows, as by nature they are supposed to be completed within a few seconds (3-6 seconds). For asynchronous flows, you need to be careful when designing the solution and ensure each function can complete the task within this period. If it cannot, the logic should be broken into smaller functions that complete within the limits.

AWS Lambda Payload Limit

AWS has kept the payload max limit to 6 MB for synchronous flows. That means you cannot pass more than 6 MB of data as events. So when designing the Lambda function, you need to ensure that consumer and downstream systems are not sending very heavy payload requests and responses, respectively. If there’s no way to avoid that, Lambda might not be the right solution for that use case.

AWS Lambda Deployment Package

AWS Lambda size limit is 50 MB when you upload the code directly to the Lambda service. However, if your code deployment package size is more, you have an option to upload it to S3 and download it while triggering the function invocation.

Another option is to use Lambda Layers. If you use layers, you can have a maximum of 250MB for your package. You can add up to five layers per function. However, if you are uploading so much code, there might be a real problem in your design that you should look into. A function is meant to contain short logical code. So much code may cause high cold start times and latency problems.

Lambda Design Best Practices around Lambda Limits

We reviewed some of the most common Lambda limits. Now, let’s discuss workarounds, tips, and best practices for designing Lambda functions around these limits.

• Although AWS put the concurrent execution limit at 1000 at the account level. You must define the concurrency limit for each function individually so that overuse by one function overuse doesn’t affect other functions running in the account (see Bulkhead pattern).
• Lambda version is a very important feature but the continuous updating of the function increases the storage requirement and may hit the threshold limit (75 GB), something you may be unpleasantly surprised to learn while deploying to production. So plan ahead with an automation script that will clean up the old versions of the function. You may decide a number (say, 5 to 10) of versions to support.
• For synchronous flows, keep the timeout limit of functions very low (3-6 seconds). It ensures that resources are not unnecessarily clogged for a long time and saves costs. For asynchronous flows, based on the monitoring metrics, decide the average time of execution and configure the timeout with some additional buffer. While deciding timeout configuration, always keep in mind the downstream system’s capacity and SLA for the response.
• For CPU-intensive logic, allocate more memory to reduce the execution time. But keep in mind that having more than 1.8 GB memory along with a single-threaded application won’t give better performance beyond a limit. You need to design the logic to use a multi-threaded strategy to use the second core of the CPU.
• For Batch processes that need more than 15 minutes to execute, break the logic into multiple functions, and use the Lambda Destination or  Step Functions to stitch together the events.
•  Lambda Function has a temporary instance storage /tmp with 512 MB capacity. This will go off once execution is completed and the instance is automatically stopped after a certain time period. Don’t use this capacity as the function should be designed for stateless flow.

Summary

There are quite a few AWS Lambda limits, but have some thought behind them. They are not meant to restrict your use of Lambda, but to protect you from unintentional behavior and things like DDoS attacks. You just need to make yourself aware of these limits and follow the best practices discussed above to get the most out of AWS Lambda.