Repository navigation
Add layer support #19
Description
Hi @tmokmss,
Thanks for creating this construct, it's much appreciated.
Have you considered supporting packaging the LLRT runtime as a layer? It seems like the performance penalty is pretty minimal according to this article and I think it would be nice option to have where someone has lots of LLRT based functions.
I'm going to take a shot at making this work, if I'm successful then please let me know if you'd like me to make a PR.
Regards
Mark
Activity
mrhornsby commentedon Nov 17, 2025
I have a version here where testing works locally but I've got an error in my build action that I'm investigating.
Mark
mrhornsby commentedon Nov 19, 2025
I have this fully working now. Please let me know if you'd accept a PR.
Thanks
Mark
tmokmss commentedon Nov 20, 2025
Hi @mrhornsby, thank you for the request! I'd like to confirm, what is the motivation to use Lambda layer for this purpose? Is it to reduce code storage (75GB soft limit)?
mrhornsby commentedon Nov 20, 2025
Hi @tmokmss, the code storage limit isn't really a concern, it's more the need to upload the assets with each build. Most of my lambdas are no more than 100-200kb but adding in the LLRT runtime increases this 10-20x fold. My intention is to keep the lambda bundle nice and small which is particularly helpful when iterating on a particular function or in a continuous integration environment where we deploy / re-deploy all the lambdas regularly while the runtime layer won't change often. Mark
tmokmss commentedon Nov 20, 2025
@mrhornsby Thanks for the clarification! I basically agree with the idea, but let me think about it some more 🙏
Given that the LLRT binary is only a few MB, is it really that much of a problem? I'm still not sure whether it's worth the additional complexity of the Lambda layer. Could you provide some concrete metrics on the improvements to your use case?
mrhornsby commentedon Nov 21, 2025
It really comes down to your network speed. The average UK upload speed is about 18 Mbps so this equates to a saving of 1-2 seconds per lambda (depending on which SDK type it uses). I'll publish a forked package for now and gather some more real world data.
mrhornsby commentedon Nov 26, 2025
Hi @tmokmss, I've been using my fork for the last few days and real world testing matches up to my calculations above. I built an example stack with 10 lambdas (I have work with projects with as many as 70 lambdas) and deployment without the layer took between 66 and 75 seconds. The same stack with the layer took between 41 and 46 seconds. This was all tested with a network upload speed of 18 Mbps. Let me know if you've had any more thoughts about possibly merging this in. Thanks.
tmokmss commentedon Nov 26, 2025
@mrhornsby Cool! And there is no degradation on the cold start time?
mrhornsby commentedon Nov 26, 2025
In my limited testing I'm not seeing any appreciable difference although I've not done the same level of testing as they did in the article. Given that the feature can be enabled lambda by lambda the user should be able to decide if the improved deployment time is beneficial in their use case?
tmokmss commentedon Nov 27, 2025
Sounds great! Yes, I'll review your PR 🙏
mrhornsby commentedon Nov 27, 2025
Thanks @tmokmss, I've opened the PR, I'll close this issue as we can continue any discussion there 🙏
tmokmss commentedon Nov 29, 2025
Let's close this after the PR is merged 👍
feat: Add ability to package LLRT as a layer (#20)