Monitoring platform for keeping systems up and running at all times.
Full stack visibility across the entire stack.
Detect and resolve any incident in record time.
Conform to industry best practices.
Serverless is a great new technology, allowing teams to save time and money, and release features more often. However, there are certain limits to AWS services. In this article, we’ll be taking you through the AWS Lambda limits you should bear in mind when developing serverless applications.
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.
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.
Runtime Environment limitations:
The reason for defining the limit of 50 MB is that you cannot upload your deployment package to Lambda directly with a size greater than the defined limit. Technically the limit can be much higher if you let your Lambda function pull the deployment package from S3. AWS S3 allows for deploying function code with a 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 requests.
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.
We’ll be working with a Machine Learning model as our deployment package, creating random data of specified size to test the AWS Lambda limits 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:
This model was created specifically for this project. However, Machine Learning models can be downloaded from the following sources.
Keras: https://github.com/fchollet/deep-learning-models
TensorFlow: official release, performance models, tensornets
2. Let’s call our package as MachineLearning.zip.
zip MachineLearning.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 MachineLearning.zip
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://./MachineLearning.zip
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 "MachineLearning.zip"
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 MachineLearning.zip
This time it shows no error even after updating our Lambda function and we’re able to upload our package successfully. This 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 "sample300.zip"
aws lambda update-function-code --function-name mlearn-test --region ap-south-1 --s3-bucket mlearn-test --s3-key sample300.zip
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 are 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 a 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.
Built by serverless developers with specifically serverless technologies and AWS Lambda in mind. So if you’re developing your application on AWS, Dashbird is here to make sure you’re running smoothly: save you hours..even days – on average, Dashbird users have seen their discovery time of an error reduce by 80% – on debugging, give you customized and actionable insights based on the AWS Well-Architected Framework to further improve your infrastructure, and provide a quick and easy to understand real-time overview of the health and performance of your serverless infrastructure.
Sign up now
You can give Dashbird a try for free:
* The maximum execution time was increased from 5 minutes to 15 in October 2018.
In this article, we’re covering 4 tips for AWS Lambda optimization for production. Covering error handling, memory provisioning, monitoring, performance, and more.
In this article we’ll go through the ins and outs of AWS Lambda pricing model, how it works, what additional charges you might be looking at and what’s in the fine print.
Dashbird was born out of our own need for an enhanced serverless debugging and monitoring tool, and we take pride in being developers.
Dashbird gives us a simple and easy to use tool to have peace of mind and know that all of our Serverless functions are running correctly. We are instantly aware now if there’s a problem. We love the fact that we have enough information in the Slack notification itself to take appropriate action immediately and know exactly where the issue occurred.
Thanks to Dashbird the time to discover the occurrence of an issue reduced from 2-4 hours to a matter of seconds or minutes. It also means that hundreds of dollars are saved every month.
Great onboarding: it takes just a couple of minutes to connect an AWS account to an organization in Dashbird. The UI is clean and gives a good overview of what is happening with the Lambdas and API Gateways in the account.
I mean, it is just extremely time-saving. It’s so efficient! I don’t think it’s an exaggeration or dramatic to say that Dashbird has been a lifesaver for us.
Dashbird provides an easier interface to monitor and debug problems with our Lambdas. Relevant logs are simple to find and view. Dashbird’s support has been good, and they take product suggestions with grace.
Great UI. Easy to navigate through CloudWatch logs. Simple setup.
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.