[jvanvleet]

https://github.com/awslabs/aws-lambda-cpp makes claims of millisecond cold start.

[nostrebored]

That's not for in-VPC functions, although if the underlying instance changes with firecracker migration users might see ENI start improvements. Currently your ENI usage is roughly floor(3GB/Memory Allocation)*(Concurrent Executions). If the 3GB changes users will see huge gains as each ENI creation can take around 9s.

[k__]

Why would you use VPC functions?

[Wintereise]

Mostly due to being forced. For example: serverless aurora forces a VPC on you.

With delays as bad as 8+ seconds for ENI attachment, this is a significant holdback (https://medium.freecodecamp.org/lambda-vpc-cold-starts-a-lat...)

[zwily]

I believe you can now use Aurora Serverless outside of a VPC by using the new Data API endpoint.

[Wintereise]

You indeed can, but it's beta (us-east-1 only at the moment) and leaves a lot to be desired (https://www.jeremydaly.com/aurora-serverless-data-api-a-firs...)

[k__]

Ah okay, I never thought about using an SQL DB.

[jvanvleet]

True. In-VPC has extra costs.

[hn_throwaway_99]

I'm wondering how that's even possible if it includes the time for downloading your code from S3. I.e. normal cold starts (as I understand it) involve fetching the code from S3 to install on a VM. Perhaps they aren't including that time when claiming single milli cold start times?