Start free trial

Central data platform for your serverless environment.

Get full access to all premium features for 14 days. No code changes and no credit card required.

Password: 8+ characters, at least one upper case letter, one lower case letter, and one numeric digit

By signing up, you agree to our Privacy policy and
Terms and Conditions.

Exploring AWS Lambda Deployment Limits


We have explored how we can deploy Machine Learning models using AWS Lambda. Deploying ML models with AWS Lambda is suitable for early-stage projects as there are certain limitations in using Lambda function. However, this is not a reason to worry if you need to utilize AWS Lambda to its full potential for your Machine Learning project. When working with Lambda functions its a constant worry about the size of deployment packages for a developer.

Let’s first have a look at the AWS Lambda deployment limits and address the 50 MB package size in the AWS official documentation which is kind of delusive as you can make larger deployments of uncompressed files.

AWS Lambda has the following limitations.

Runtime Environment limitations:

  • The disk space (ephemeral) is limited to 512 MB.
  • The default deployment package size is 50 MB.
  • Memory range is from 128 to 3008 MB.
  • Maximum execution timeout for a function is 15 minutes*.
    Requests limitations by Lambda:
  • Request and response (synchronous calls) body payload size can be up to to 6 MB.
  • Event request (asynchronous calls) body can be up to 128 KB.

The reason for defining the limit of 50 MB is that you cannot upload your deployment package to Lambda directly with size greater than the defined limit. Technically the limit can be much higher if you let your Lambda function pull deployment package from S3. AWS S3 allows for deploying function code with substantially higher deployment package limit as compared to directly uploading to Lambda or any other AWS service. As a matter of fact, most of the AWS service default limits can be raised by AWS Service Limits support request.

Still, it is a matter of doubt for many developers as to what is the actual limit. So to find an answer to that very question we are going to test by uploading deployment packages of different sizes.

Deployment Packages

We’ll be working with a Machine Learning model as our deployment package, creating a random data of specified size to test the limit with varying sizes. We’ll test the following limits as described in the documentation:

50 MB: Maximum deployment package size 250 MB: Size of code/dependencies that you can zip into a deployment package (uncompressed .zip/.jar size)

For this test, we’ll be using our machine learning model that we created in this article. It’s an image recognition deep learning model based on TensorFlow Inception-v3 model. Although our data is not so compressed. The overall file size is about 150 MB which is much beyond the specified limit of 50 MB.


Let’s test it by directly uploading to Lambda function. Here are the main steps to be followed: 1 First we’ll zip our package. This zip package will contain all our files such as:

  • classify_image_graph_def.pb

This model was created specifically for this project. However, Machine Learning models can be downloaded from the following sources.


TensorFlowofficial releaseperformance modelstensornets

2 Let’s call our package as

zip MachineLearning 

3 Now check whether we could compress the file or not.

$ ls -lhtr | grep zip
-rw-r--r-- 1 john staff 123M Nov 4 13:05

Even after compressing and zipping the overall package size is about 132 MB.

4 In order to create a Lambda function, we need to create IAM role. Since our primary objective is to test the limits we’ll skip over the role creation process. Login to IAM Management Console with your credentials and create a Test-role and attach AWSLambdaRole policy.

5 Next, we’ll create a Lambda function via AWS CLI and upload our deployment package directly to the function.

aws lambda create-function --function-name mlearn-test --runtime nodejs6.10 --role arn:aws:iam::XXXXXXXXXXXX:role/Test-role --handler tensorml --region ap-south-1 --zip-file fileb://./

Replace XXXXXXXXXXXX with your AWS account id. Since our package size is greater than 50 MB specified limit it throws an error.

An error occurred (RequestEntityTooLargeException) when calling the UpdateFunctionCode operation: Request must be smaller than 69905067 bytes for the UpdateFunctionCode operation

6 Since our deployment package is quite large we will load it again during AWS Lambda inference execution from Amazon S3. For this we need to create AWS S3 bucket from AWS CLI:

aws s3 mb s3://mlearn-test --region ap-south-1

This will create an S3 bucket for us. Now we’ll upload our package to this bucket and update our Lambda function with the S3 object key.

aws s3 cp ./ s3://mlearn-test/ --recursive --exclude "*" --include ""

Once our package is uploaded into the bucket we’ll update our Lambda function with the package’s object key.

aws lambda update-function-code --function-name mlearn-test --region ap-south-1 --s3-bucket mlearn-test --s3-key

This time it shows no error even after updating our Lambda function and we’re able to upload our package successfully. Which means that the package size can be greater than 50 MB if uploaded through S3 instead of uploading directly. Since our package size is about 132 MB after compression we are still not clear what is the maximum limit of the package to be uploaded.

In order to get the maximum limit, we’ll create a random data of about 300 MB and upload it through S3 and update our Lambda function.

fsutil file createnew sample300.txt 350000000

This will create a sample file of about 300 MB. We’ll zip the file and upload it again through S3.

aws s3 cp ./ s3://mlearn-test/ --recursive --exclude "*" --include ""

aws lambda update-function-code --function-name mlearn-test --region ap-south-1 --s3-bucket mlearn-test --s3-key

After updating our Lambda function we get the following error:

An error occurred (InvalidParameterValueException) when calling the UpdateFunctionCode operation: Unzipped size must be smaller than 262144000 bytes

The error describes that the size of the unzipped package should be smaller than 262144000 bytes which is about 262 MB. We can notice here that this size is just a little greater than the specified limit of 250 MB size of code/dependencies that can be zip into a deployment package (uncompressed .zip/.jar size). So we discovered that the maximum limit of the size of the uncompressed deployment package is 250 MB when uploaded via S3. However, we can’t upload more than 50 MB package while uploading directly into Lambda function.

The important thing to notice here is that your code and its dependencies should be within 250 MB size limit when in an uncompressed state. Even if we consider a larger package size it may seriously affect Lambda function’s cold start time. Consequently, the Lambda function will take a longer time to execute with larger package size.

If you’re looking to get a quicker and easier understanding of the performance of your serverless website or application, check out Dashbird’s monitoring, insights and alerts features or hit the ground running and get your free account now.

* The maximum execution time was increased from 5 minutes to 15 in October 2018.

Made by Developers for Developers

Our history and present are deeply rooted in building large-scale cloud applications on state-of-the-art technology. Dashbird was born out of our own need for an enhanced serverless debugging and monitoring tool, and we take pride in being developers.

Trusted by hundreds

Gus Gordon

Dashbird helped us refine the size of our Lambdas, resulting in significantly reduced costs. We have Dashbird alert us in seconds via email when any of our functions behaves abnormally. Their app immediately makes the cause and severity of errors obvious.

Gus Gordon

Dashbird helped us refine the size of our Lambdas, resulting in significantly reduced costs. We have Dashbird alert us in seconds via email when any of our functions behaves abnormally. Their app immediately makes the cause and severity of errors obvious.

Read our blog

AWS Well-Architected Framework in Serverless: Reliability Pillar

In this article, we will focus on the AWS WAF Reliability (REL) pillar: the Foundations, Failure and Change Management.

AWS Well-Architected Framework in Serverless: Operational Excellence

This article will discuss the second most crucial pillar of the AWS Well-Architected Framework: Operational Excellence (OPS).

AWS Well Architected Framework in Serverless Part I: Security

In this article, we’ll give you a short introduction to the AWS Well-Architected Framework and dive deeper into the Security pillar.

What Is Lambda Expression?

Lambda expressions have often been the subject of mystery for developers. Here’s a short explanation on what they actually are.

Microservices and Serverless: Winning Strategies and Challenges

In this article, we’ll deep dive into the benefits, challenges, and best practices of using microservices in serverless.

Go to blog