Node.js and Lambda deployment size restrictions
AWS Lambda has a 250 Megabyte limit on the size of the deployable asset. It is a generous limit that is easy to exceed with Node-based Lambda functions.
The underlying issue with Node is that JavaScript is an interpreted language. Third-party modules included as part of the code are all plain-text and verbose.
JavaScript is dynamically linked. You might use one function from, say, AWS SDK, but you need to include the entire AWS SDK module in your
By its nature, Node is a suboptimal platform for Lambda. It is slow, bloated, takes a long time to load, and a disproportionally long time to execute. Yet, JavaScript has a religious following and is, sadly, a reality we have to endure.
Here are the top few reasons for a Node-based Lambda to exceed the 250 Megabyte limit and remedy it.
The first step should be to check whether some dependencies that are included in the final package are needed for development but not needed at runtime.
For example:
Separate production dependencies from development dependencies in your
If excluding development dependencies from the production package didn’t help, check whether you are actually using all of the modules you listed in
Copy/pasting dependencies from other projects without thinking happens to the best of us, though we potentially end up with unnecessary modules included.
I ran into this issue at work where a Lambda function used a few modules that we maintain within the team.
The Lambda function was using version X of AWS SDK for its internal workings.
But each dependency was also using a slightly different minor version of AWS SDK.
As a result, the Lambda function shipped with multiple different versions of AWS SDK. The final package size well exceeded the 250 Megabyte limit five-fold.
Using
I doubt that I covered all possible scenarios here. I would not use Node.js at all for a new application. It’s a horrible language and an awful platform. Given Node.js' popularity, though, we have to work with what we have — and that includes finding ways to keep the deployable size small, so it fits within the AWS Lambda limits.
The underlying issue with Node is that JavaScript is an interpreted language. Third-party modules included as part of the code are all plain-text and verbose.
JavaScript is dynamically linked. You might use one function from, say, AWS SDK, but you need to include the entire AWS SDK module in your
package.json. AWS SDK alone can be around 50 Megabytes in size.By its nature, Node is a suboptimal platform for Lambda. It is slow, bloated, takes a long time to load, and a disproportionally long time to execute. Yet, JavaScript has a religious following and is, sadly, a reality we have to endure.
Here are the top few reasons for a Node-based Lambda to exceed the 250 Megabyte limit and remedy it.
Development dependencies
The first step should be to check whether some dependencies that are included in the final package are needed for development but not needed at runtime.
For example:
- Typescript compiler,
- Unit-testing frameworks (i.e.
mocha), - Linter
Separate production dependencies from development dependencies in your
package.json file using dependencies vs. devDependencies and make sure to use npm install —prod-only when building your deployable zip file.Unnecessary modules
If excluding development dependencies from the production package didn’t help, check whether you are actually using all of the modules you listed in
package.json.Copy/pasting dependencies from other projects without thinking happens to the best of us, though we potentially end up with unnecessary modules included.
Multiple versions of the same module
I ran into this issue at work where a Lambda function used a few modules that we maintain within the team.
The Lambda function was using version X of AWS SDK for its internal workings.
But each dependency was also using a slightly different minor version of AWS SDK.
As a result, the Lambda function shipped with multiple different versions of AWS SDK. The final package size well exceeded the 250 Megabyte limit five-fold.
Using
npm ls, I found all of the duplicated nested dependencies on AWS SDK. Since we control all of the modules at issue, I moved AWS SDK to dev dependencies and listed it under peer dependencies section, such that in the end only one version of AWS SDK was installed in Lambda.Some last thoughts
I doubt that I covered all possible scenarios here. I would not use Node.js at all for a new application. It’s a horrible language and an awful platform. Given Node.js' popularity, though, we have to work with what we have — and that includes finding ways to keep the deployable size small, so it fits within the AWS Lambda limits.