AWS Lambda Limits

AWS Lambda Limits

AWS Lambda limits are quotas that control how much compute, storage, concurrency, execution time, and data a Lambda function can use.

Some limits are fixed. For example, a standard Lambda function can run for a maximum of 15 minutes. Other quotas, such as account-level concurrent executions, can be increased through AWS Service Quotas.

Understanding these limits is important when designing serverless applications because exceeding a quota can result in throttling, failed requests, incomplete processing, or deployment failures.

AWS Lambda Limits at a Glance

Here are the key limits developers are most likely to encounter.

AWS also applies account-level and Region-level quotas that can differ depending on the account. New AWS accounts may initially receive lower concurrency and memory quotas that AWS can increase as usage grows.

Hard vs. Soft AWS Lambda Limits

Not every Lambda quota behaves the same way.

Hard limits

Hard limits cannot normally be increased.

Examples include:

• 15-minute function timeout
• 10,240 MB maximum function memory
• 6 MB synchronous request and response payload
• 1 MB asynchronous invocation payload
• 250 MB uncompressed ZIP deployment package
• 10 GB container image
• Five Lambda layers per function

When an application outgrows one of these limits, you generally need to change the application architecture rather than request a quota increase.

Adjustable quotas

Some account-level limits can be increased.

The most common example is Lambda concurrency.

AWS provides 1,000 concurrent executions per Region by default for standard accounts, although the exact quota for your account can vary. AWS allows concurrency quotas to be increased into the tens of thousands.

You can view account-specific quotas from AWS Service Quotas.

AWS Lambda Timeout Limit

The maximum execution time for a standard Lambda function is:

900 seconds, or 15 minutes.

The timeout can be configured anywhere up to that limit. AWS terminates an invocation if it has not completed before the configured timeout.

Short-running API functions may use timeouts of only a few seconds, while data processing functions might require several minutes.

A function consistently approaching its timeout can indicate:

• slow downstream APIs
• inefficient database queries
• large files being processed synchronously
• excessive retrying
• CPU-intensive processing
• workloads that should be split into multiple steps

For jobs that cannot reliably complete within 15 minutes, consider breaking the workflow into smaller asynchronous tasks instead of attempting to extend Lambda's execution time.

AWS Lambda Memory Limit

Lambda functions can be configured with:

128 MB to 10,240 MB of memory

in 1 MB increments.

Memory also affects the CPU resources allocated to the function. AWS states that at approximately 1,769 MB, a Lambda function receives the equivalent of one vCPU. Increasing memory therefore can improve CPU-bound workloads even when the application does not need the additional RAM.

The highest memory setting is 10,240 MB.

Choosing the right value requires balancing:

• execution duration
• memory consumption
• CPU requirements
• cost
• workload characteristics

A function using 90% of its allocated memory, for example, has very different scaling requirements from one consistently using 20%.

AWS Lambda Concurrency Limit

Concurrency represents the number of Lambda invocations running at the same time.

AWS provides a default account concurrency quota of:

1,000 concurrent executions per Region.

Functions in the same Region normally share this pool. When available concurrency is exhausted, additional invocations can be throttled.

AWS provides two important concurrency controls.

Reserved concurrency

Reserved concurrency dedicates part of the account's concurrency to a specific function while also limiting how far that function can scale.

For example:

Account concurrency: 1,000

checkout-function: 300 reserved
payment-function: 200 reserved

Remaining shared capacity: 500

Reserved concurrency can protect critical functions from other workloads consuming the entire concurrency pool.

It can also protect downstream systems. If a database can safely support only 100 concurrent Lambda connections, limiting Lambda concurrency can prevent the function from overwhelming the database.

Provisioned concurrency

Provisioned concurrency keeps execution environments initialized ahead of incoming requests.

Its primary purpose is not to increase your account limit. Instead, it reduces initialization latency for latency-sensitive workloads.

AWS recommends it particularly for interactive applications where predictable response times are important. Provisioned concurrency incurs additional charges.

Lambda Concurrency Scaling Limit

Available concurrency and scaling speed are separate concepts.

For an individual standard Lambda function, AWS currently allows scaling by up to:

1,000 execution environments every 10 seconds.

This matters for sudden traffic spikes.

Even when sufficient account-level concurrency remains available, an extremely sharp increase in traffic can temporarily exceed the rate at which Lambda creates additional execution environments.

Applications receiving bursty traffic should therefore monitor both throttling and concurrency utilization.

AWS Lambda Payload Limits

Payload limits depend on how the function is invoked.

Synchronous invocation

The maximum request payload is:

6 MB

The standard synchronous response limit is also:

6 MB.

Lambda streamed responses can be up to 200 MB, although bandwidth is limited after the first 6 MB.

Asynchronous invocation

The maximum asynchronous invocation payload is:

1 MB.

Large objects should generally be stored outside the Lambda invocation itself.

For example, an application can:

1. Store a file in Amazon S3.
2. Pass the S3 object reference to Lambda.
3. Let Lambda retrieve the object when processing begins.

This keeps invocation payloads small while allowing applications to work with much larger datasets.

Lambda Deployment Package Limits

ZIP-based Lambda functions have two important package limits.

Compressed package

The maximum ZIP size uploaded directly through the Lambda API or SDK is:

50 MB.

For larger packages, the deployment ZIP can be uploaded through Amazon S3.

Uncompressed package

The total uncompressed size cannot exceed:

250 MB.

This includes the function code, custom runtimes, and Lambda layers.

Developers approaching this limit can consider:

• removing unused dependencies
• using smaller libraries
• moving shared dependencies into layers
• downloading non-code assets at runtime
• packaging the function as a container image

Lambda Container Image Limit

Lambda functions packaged as container images can have a maximum uncompressed image size of:

10 GB, including all image layers.

Container images are useful when dependencies make the traditional ZIP package limits impractical, although large images can introduce their own deployment and operational considerations.

Lambda Temporary Storage Limit

Every execution environment includes temporary storage under:

/tmp

Lambda allows ephemeral storage between:

512 MB and 10,240 MB.

It can be configured in 1 MB increments. Data stored in /tmp is encrypted at rest and belongs to the execution environment.

Temporary storage is particularly useful for:

• file processing
• image manipulation
• ETL workloads
• machine-learning inference
• temporary downloads
• intermediate processing

Applications should not treat /tmp as persistent application storage.

Lambda Environment Variable Limit

The combined size of all environment variables associated with a Lambda function is limited to:

4 KB.

Large application configurations should therefore be stored in an appropriate configuration or secret-management service rather than packed into Lambda environment variables.

Lambda Layer Limit

A Lambda function can use a maximum of:

5 layers.

The contents of those layers also count toward the 250 MB uncompressed deployment package limit for ZIP-based Lambda functions.

Lambda Code Storage Quota

AWS currently provides 300 GB per Region of Lambda-managed storage for uploaded ZIP functions and layers.

Each function version and layer version consumes this storage.

Unlike many account quotas, AWS currently lists this quota as non-increasable and recommends self-managed S3 code storage when additional capacity is needed.

Old function versions and unused layers can therefore accumulate and consume meaningful storage over time.

What Happens When You Exceed a Lambda Limit?

The result depends on the quota.

You may encounter:

This is why Lambda limits should be monitored as operational constraints rather than treated only as deployment documentation.

How to Check Your AWS Lambda Quotas

To see the quotas that apply to your AWS account:

1. Open AWS Service Quotas.
2. Select AWS services.
3. Search for AWS Lambda.
4. Review the quota and current account value.
5. Request an increase where AWS allows one.

Account-specific values matter because some quotas can differ from the defaults documented by AWS.

Monitoring Lambda Limits in Production

A quota becomes operationally important before you actually reach it.

For example, consistently running at 950 concurrent executions in an account with a 1,000 concurrency quota leaves very little capacity for a traffic spike.

Useful Lambda signals to monitor include:

• concurrent executions
• throttles
• invocation count
• errors
• duration
• memory usage
• cold starts
• provisioned concurrency utilization
• downstream latency

Middleware's Serverless Monitoring brings serverless metrics, logs, and traces together so teams can investigate performance problems without treating each signal independently.

For a practical implementation walkthrough, see Middleware's AWS Lambda Observability With Middleware setup guide.