sls-mentor VS serverless-analyze-bundle-plugin

This compilation is based on 🛡 sls-mentor 🛡, my free open-source tool that automatically checks 30 serverless best practices on your AWS serverless projects (no matter the framework). Feel free to check it out!

I recently packaged my awesome, open-source, AWS stack auditing tool SLS-mentor into a github action. On this occasion, I was confronted with the question of reproducibly configuring AWS authentication on a remote CI/CD job. In this article, I will explain to you how to proceed.

It is considered best-practice to use failure destinations on all your asynchronous Lambda functions (for data retention and notification purposes). Remember sls-mentor? It automatically checks that you use failure destinations on all your asynchronous Lambda functions, so that you know where to put your efforts first.

Find sls-mentor on Github ⭐️

With my team we have been building sls-mentor, a free and open source tool to audit your serverless stack on AWSand to give you tips to improve it!

We've got existing issues waiting for contributors, and we are open to new ideas too! Feel free to join us on GitHub!

It is basically a big cloud linter, feel free to check it out to learn more about AWS!

Introducing sls-mentor: a new open-source tool allowing you to audit your AWS serverless infrastructure. Like linters, it is based on rules, and it implements a rule verifying that all your S3 Buckets have "Block public access" enabled.

But a problem persists: how do I simply now which Lambda functions are using these deprecated runtimes? This is where sls-mentor comes in. It is a CLI tool that allows you to audit your AWS serverless infrastructure. It can be used to find deprecated runtimes on your Lambda functions.

As I dived in this topic, I added a security check to the audit tool that I use in my team: sls-mentor. This is an open source audit tool that helps us enforce best practices on our projects. Don’t hesitate to try it and send feedback to the team via a GitHub issue, the project is actively maintained. 😉

Note that there is one minor drawback, though: Kysely will add 120KB in your Lambdas bundles (props to for serverless-analyze-bundle-plugin for helping me out with this 🙌). It is not a lot, but not negligible either as NodeJS Lambdas bundles above 5MB negatively impacts their cold starts. So you might want to re-evaluate adding Kysely to your bundles if your query is not changing often.

There are plenty of tools out there to optimize the size of your bundles. For instance the Serverless Analyze Bundle Plugin integrates with the Serverless Framework and helps you diagnose which of your NodeJS dependency is not properly tree-shaked.

One of the most important aspects of serverless development is keeping an eye on your bundle sizes and to reduce cold start times on Lambda. Keeping this in mind, the template utilizes serverless-esbuild and serverless-analyze-bundle-plugin to provide function analysis out-of-the-box. I opted for serverless-esbuild over serverless-bundle for a few reasons: