This covers you straight through 4.
Now it's possible that your execution environment could be sitting for sometime waiting for any action and so pre-handler DB connections and things like that might need to be tweaked in this model.
Thanks, - munns
But since the APIs that I moved over to Fargate are now automatically being deployed to both lambda and Fargate with separate URLs, we can A/B test both and see if we will move to lambda in cases where the request/response limit isn’t a problem.
Btw, I didn’t think using a NAT instead of an ENI had rolled out completely. I tried to delete a stack recently and it still took awhile to “cleanup” resources. I thought that was caused when it was deleting the ENI. I’ll be on the look out for it next time I need to delete a stack.
1. the time to initialize the VM
2. the time to create an ENI if you are connecting to a VPC[1](until the NAT alternative rolls out globally)
3. the time to initialize your language runtime (Java seems to be the worse, scripting languages the best)
4. any program initialization done outside of your handler that runs once per cold start of your lambda runtime.
A fully “warm” instance avoids all four when run.
Is my understanding correct that a “provisioned” runtime that isn’t “warm” will only avoid the first two?
What state is a “provisioned” instance in?
[1] I refuse to use the colloquial but incorrect statement that the lambda is “running inside your VPC”.