AWS Lambda is a powerful serverless compute service that allows you to run code without provisioning or managing servers. However, like any cloud service, it comes with its own set of limitations and constraints.
Soft vs Hard Limitations
Before getting into the specifics, you should understand the difference between soft & hard limitations. Soft limits can be increased through AWS Support, while hard limitations cannot be increased and require mitigation strategies.
The limitations are:
- Concurrent execution limits (default 1,000)
- Storage capacity limits for code and temporary storage
- Function size limits (250MB unzipped)
- Network connectivity restrictions unless using a VPC
- Unsupported programming languages
- Limits on Elastic Network Interfaces per VPC when using a VPC
- Maximum execution time limit (15 minutes)
- Memory and compute constraints (max 10GB memory)
- Cold start latency when provisioning new execution environments
- Challenges with debugging Lambda functions integrated with other AWS services
1. Concurrent Executions
By default, AWS accounts have a soft limit of 1,000 concurrent executions for Lambda functions. New accounts may have fewer concurrent executions initially. If you need to increase this limit, you can request an increase from AWS Support.
2. Storage Capacity
Your overall code storage capacity is capped at a hard limit of 75 GB. This includes your deployment packages and any attached Lambda Layers.
3. Function Size Limitations
The size of your unzipped Lambda function deployment package and all attached Layers cannot exceed a hard limit of 250 MB. If your function exceeds this limit, you may need to mitigate by avoiding unnecessary packages or splitting your processes into different functions.
4. Ephemeral Storage Restrictions
Your Lambda function's /tmp directory, which provides ephemeral storage during execution, cannot exceed a hard limit of 10 GB of storage. If you need more temporary storage, you can mitigate by using storage services like Amazon S3 or Amazon Elastic File System (EFS).
5. Limited Network Capabilities
Lambda functions have limited outbound network connectivity by default, meaning you cannot simply restrict outgoing network traffic or use an Elastic IP address. To gain more control over networking, you can mitigate by attaching your Lambda function to an Amazon Virtual Private Cloud (VPC), which provides features like security groups, network access control lists, and NAT gateway access.
6. Unsupported Languages
AWS Lambda supports a limited set of programming languages natively. If your desired language is not supported, you can mitigate by bringing your own runtime environment.
7. Elastic Network Interfaces (ENIs) per VPC
If your Lambda function is attached to a VPC, it needs an Elastic Network Interface (ENI). While AWS introduced Hyperplane support to allow functions to share ENIs, there is still a limit on the number of ENIs per VPC. If you reach this limit, you may need to mitigate by creating additional VPCs or exploring alternative architectures.
8. Maximum Execution Time
Lambda functions have a hard limit of 15 minutes of execution time. If your workload exceeds this limit, you can mitigate by parallelizing your workloads across multiple functions or exploring alternative architectures.
9. Memory and Compute Constraints
AWS Lambda imposes a hard limit of 10,240 MB (10 GB) of memory for your functions. The amount of memory you allocate to your function also determines the amount of compute power (vCPUs) available. If you require more memory or compute power, you can mitigate by parallelizing your workloads across multiple functions.
10. Cold Starts
When a Lambda function is invoked, AWS needs to provision a micro-container in the background to execute your function's code. This process, known as a cold start, can introduce latency before your code starts running. To mitigate cold starts, you can use AWS Lambda's Provisioned Concurrency feature, which maintains a fixed number of micro-containers in an always-available state.
11. Debugging Capabilities Limits
Debugging Lambda functions can be challenging because they are integrated with other AWS services and executed in the cloud. To mitigate this limitation, you can leverage third-party tools like Serverless Stack (SST) that allow you to debug your functions even when executed in the cloud.
AWS Lambda is a powerful serverless compute service, but it comes with its own set of limitations and constraints.
Top comments (0)