Provisioned Concurrency

[heythisisnate]

Any fresh insight into how to make provisioned concurrency work for Jets controllers?

I had some trouble with JetsPreheatJob permissions after the 4.x update and decided to take a crack at selectively implementing provisioned concurrency for a few of my controller functions that need to be always hot. The problem I’m running into is that AWS Lambda only lets you set provisioned concurrency for an alias or version of a function, but it can’t be an alias or version pointed to the $LATEST version.

Setting up a version was easy enough to test, but Jets still wants to call the $LATEST version of the function, so it’s not hitting my provisioned Lambdas at all.

Is there a way to tell Jets to call a specific function alias or version?
Is there a way to make jets use this AutoPublishVersion feature to automatically create a live alias pointing to a recent version of the deployed function?

Even if I can just hardcode the function version for now, it would be better than skipping my provisioned Lambdas entirely.

Really a question for @tung but if others have run into it I’m interested. I would be willing to take a crack at it a PR if you can give me some pointers on where this might go.

Thanks!

[tung]

Yup. Looked into provisioned concurrency a long time ago when it was first released.

RE: Is there a way to tell Jets to call a specific function alias or version?

Not currently.

RE: Is there a way to make jets use this AutoPublishVersion feature to automatically create a live alias pointing to a recent version of the deployed function?

Not currently.

Believe when I messed with it I did not implemented the Function Alias because the CloudFormation Limits were lower at 50 resources per template years ago.

The limits are much greater now, 500 for resources, and 200 for parameters and outputs. AWS CloudFormation quotas - AWS CloudFormation

Adding function alias is okay now. Then would be able to add and use provisioned concurrency.

Note: In Jets v5, we’ll be able to able to deploy one_lambda_for_all_controllers. This should help keep the function hotter. Then adding provisioned concurrency to it, will keep it hot all the time. Note, did the math a long time ago, and it was like $25/function/month It would be wise to only turn it on for specific functions or using the one_lambda_for_all_controllers in Jets v5.

Might give it a try and see if can squeeze this into Jets v5. Unsure though

[heythisisnate]

Ah bummer. Ok well I guess Provisioned Concurrency isn’t really viable at this point in time. Let me know if I can help in some way to get this into Jets 5!

Not sure if this is new or not, but AWS gives you a little estimate of how much the provisioned concurrency is going to add to your bill when setting it up in AWS Console:

I think there are probably a lot of variables that affect the cost, but probably the most impactful is the memory size allocation for the function. It looks like the default memory size is still 1536 MB per function. I recall posting a question about this years ago. On our production application, I have it set to 256MB and on our internal bot application we’re using 512MB (probably should lower that to 256 as well). Makes a huge difference on the AWS bill!

Regarding one_lambda_for_all_controllers, oh yes! This could really help with the cold-start problem and simplify some things.

Keep up the good work!