Mar 25 2019
AWS Lambda has a soft limit of 75GB for deployment packages for all your functions (including the layers you use).
This might seem a lot, but a team that has fully embraced serverless can reach this limit very quickly, because:
- Every deployment would need to upload new artefacts, which count towards the limit.
- Deployment is so easy and quick so you tend to deploy often.
- For JVM and .NetCore functions, one of the ways to improve cold start performance is to split up the deployment package. Each function gets its own JAR/DLL and deployment artefact, which has a multiplying effect on storage space you use.
Since it’s a soft limit, it’s possible for you to request a raise (thanks AWS for changing this into a soft limit!). However, limit raises usually take hours to get approved. You have little choice but to wait, or to manually delete old versions of your functions to free up space.
Given that older versions of your functions are almost never used, a lot of the storage space actually goes to waste. In fact, since I have been working with Lambda, I have only once had to roll back a function to a previous version. And that was in production and due to intense time pressure. In the non-production environments, it’s always easier to fix forward than to roll back.
This means the older versions of your functions are literally a waste of space! Fortunately, there’s a simple solution to this problem.
When I first wrote about this problem back in 2016, I described a cron Lambda function to look for and delete old versions of your functions that are no longer referenced by aliases.
Today we’re making it easy for you to deploy this solution to your own AWS account by making it available in the Serverless Application Repository (SAR)!
To deploy it to your AWS account, head over to the SAR console and search for “lambda-janitor”. Make sure you tick the box “Show apps that create custom IAM roles or resource policies”.
Click on the “lambda-janitor” application, and click “Deploy” in the next screen.
The next screen gives you a summary of what will be deployed into your account.
If you expand the “Template” tab you will see that we will deploy a “Clean” function into your AWS environment. This function would run every hour, and for up to 15 minutes. It’s important to note that the function will be given the IAM permissions to:
- List functions, versions and aliases.
- Delete function versions (there’s no separate IAM action that distinguishes deleting a function vs a particular version).
If you’re happy to proceed, then scroll down and tick the box “I acknowledge that this app creates custom IAM roles.”. Click “Deploy” and we’re done!
The very last screen shows you the resources that have been deployed. You can also follow the shortcut to see the CloudFormation stack itself.
Once deployed, you will find a function like the one below.
What happens when we publish a new version?
When a new version of the lambda-janitor application is published, the function that has been deployed in your account remain unchanged. To get the latest version, you have to follow the steps in this post and deploy the latest version of the application again.
Doing so will trigger a CloudFormation update against the existing stack and update the resources accordingly.
How can you contribute to this project or raise feature requests?
The code for this application is available on Github. You can contribute towards the project via pull requests and you can raise feature requests via Github issues.
So that’s it! I hope you find this serverless application useful. We look forward to hearing your feedback and any other chores that you’d like us to help you automate away through serverless applications.