> Reduce the amount of code in your function artifact From my observations, this is the tip that is discovered far too late in a Lambda development process. A

> Reduce the amount of code in your function artifact From my observations, this is the tip that is discovered far too late in a Lambda development process. A team that already does Java makes assumptions about the codebase, project structure, and will add in the usual dozens of imports or attempt to reuse several existing projects to save on effort. I've seen cold starts of up to 50 seconds when this advice is ignored and a team tries to treat a Lambda project as just another Java project. And by the time it's too late, it's too late in the project... so the team will not want to optimize the codebase and instead start hunting for bandaids such as provisioned concurrency which can have an impact on others in a crowded account. Lambda and Java shouldn't be entertained without knowing about these problems up front, importantly it's the mind-shift required to ensure that the codebase is as lean as possible. So for that reason I still don't recommend Java and Lambda together, I'll point a team towards Python or NodeJS, even .NET Core where I've not seen the problem to such an extent. Inculcating the leanness of a codebase is much easier with a new language (that is, a change of scene).