> The point is pretty moot though, because you can schedule Cloudwatch Events every 4 minutes to keep a lambda warm, if necessary.
I encourage you to read this article, https://theburningmonk.com/2018/01/im-afraid-youre-thinking-... , because if you're running a web API with Lambdas, keeping one instance warm with the "cloudwatch event every 4 minutes" trick will most definitely not solve your cold start issues.
> I think many still repeat the "conventional wisdom" about the cold start, and never get past that point.
First comment on your article nails it. At the end of the day lambdas scheduling is a black box. People have deduced certain behavior, but AWS is explicit about not relying on undocumented behavior.
I would be loath to recommend lambda for any application where business performance is sensitive to the services latencies.
It is somewhat arbitrary though, isn't it? If AWS adds the ability to use security groups without a VPC, a lot of these issues go away wrt vpc or siloed infrastructure limits (cold starts).
There are still reasons to be in a private network - Being "one typo away" from exposing your services/db to the world is scary. But that seems like a solveable problem as well...
For many years now, essentially all AWS services are tied to a VPC.
Each account gets 5 VPCs per region, by default.
Whether you use RDS or EC2 to setup a database server, it will be tied to a VPC for networking isolation purposes.
As such you then would need the Lambda in the VPC, or to allow public internet access to the database.
The point is pretty moot though, because you can schedule Cloudwatch Events every 4 minutes to keep a lambda warm, if necessary.
Frameworks like Zappa even do this for you automatically.