1

I have an AWS Lambda within VPC (connects to RDS) which suffers from a typical cold start issue. I have read a couple of articles on how to make things faster so I deployed Provisioned concurrency

Details: .NET Core 3.1 environment, ASP.NET Core project running in AWS Lambda, connecting PostgreSQL RDS dbo, VPC environment.

During the testing phase, to keep costs as low as possible, I have just 3 Provisioned Concurrency ($10)

Before Provisioned Concurrency, the first request after few hours of inactivity took between 15 to 20 seconds. Next requests, fired shortly after, took less than a second. Some of the requests then randomly took again 15 seconds (I think due to parallel invocation).

After Provissioned Concurrency first requests after a day of inactivity took 14 seconds.

My expectations of Provisioned Concurrency was to get rid of the Cold Start. AWS Blogs or other Blogs have supported my wishes, however, there is still a gotcha. I think this is due to VPC.

Thanks for any hints or experience sharing!

Improve this question

1 Answer 1

Reset to default
0

I personally prefer using Cloudwatch to ping the lambda every 5-10mins. Works an absolute treat and at minimal cost. Plus you are logging what is happening by default, so it is easy to manage.

There is a great guide on it here:

https://read.acloud.guru/how-to-keep-your-lambda-functions-warm-9d7e1aa6e2f0

I should add I usually have the lambda across two AZs in one VPC for this as per the AWS recommendation for availability.

Improve this answer
Sign up to request clarification or add additional context in comments.

7 Comments

Thanks Johnny for your reply! Unfortunately, Lambda warming using CloudWatch does not work. It looks like underlying network interface for VPC is provisioned only when Lambda try to connect to DBO (which is not invoked by ping)
The Lambda ENI should be provisioned when the cloudwatch ping happens. As the lambda needs an elastic Network face to be called. Having said that, the cloudwatch service i use is via a VPC endpoint so everything is being routed via the VPC and therefore the lambda must have an ENI attached to the VPC to be called.
Yeah I understand what you are saying. Have u any idea what is wrong with my setup? I have CloudWatch ping (I see it is happening every 5 minutes in log) however requests are still taking randomly from 30ms to 19seconds.
Considering your cloudwatch, lambda and postgres are all VPC end points the only thing that jumps out is the .net environment. If the lambda container is being kept warm there is still a chance your code needs to compile if it's not being used constantly. Lambda work best/quickest with either python or node.js as there is no compile time. I have saw lags when I use Java, so I tend to use python now for everything. However, you have provision concurrency on? But there are reported cases even with that .net can take twice as long as python especially with larger memory requirements.
I suppose the one think I have now started to ask clients is why do you need a lambda in a VPC, and usually it's for security purposes. However, I find this reasoning is due to a gap in knowledge, so we go through all the security constraints placed on a lambda outside of VPC and in the majority of cases, if configured correctly l they are fine to leave the lambda outside of the VPC... However, I know this isn't always possible... But it does removed a lot of the headaches.
|

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.