If you have ventured into serverless computing, you must have come across the dreaded “cold starts”. That’s when a request has come in for your serverless function, but there’s no instance of it to serve the request. This means that Lambda has to create one right away. This could take up to 10s of seconds if you’re running something like Java Lambdas inside a VPC!

If you’re using Lambdas as the REST API based, microservices backend for a mobile or web app, cold starts are simply unacceptable. Up until now, the only way around this was to implement some kind of a warmup strategy of your own, like using a scheduler like CloudWatch Events to regularly invoke your Lambdas to keep them warm. But we don’t need to do that anymore!

Provisioned Concurrency

AWS recently announced Provisioned Concurrency for AWS Lambda. It’s a feature designed to deliver consistently low start-up latency for Lambda functions, which makes it indispensable for the use case described above.

The way it works is pretty straight-forward. As the name implies, functions using Provisioned Concurrency are pre-provisioned in advance and ready to serve requests as they come in. Instead of Lambda provisioning the container for a function when a request is received, it’s provisioned when the function is created!

Provisioned Concurrency vs Custom Warmup

There are numerous advantages of Provisioned Concurrency over any custom warmup solution you build:

• You can do away with whatever custom code or third-party dependency you use for warmup, thus making your Lambdas lighter!
• A warmup mechanism built into the infrastructure is obviously more reliable than any custom-built solution.
• It’s just as easy to keep multiple instances of a function warm, as it is in most third-party solutions.
• There’s no need to put in additional code at the beginning of each of your functions to detect whether the incoming call is legit or is it just a dummy call from the warmer.
• Every call to your function will log at least 3 statements to CloudWatch Logs, the ones for START, END & REPORT. If you’re making the warming call frequently enough, that’s a lot of unnecessary logs.
• Provisioned Concurrency also publishes additional metrics to CloudWatch indicating how many executions used the provisioned quota & the spillover if any.
• You probably have an entirely separate function whose sole purpose is to get called by a CloudWatch Events schedule & invoke all other Lambdas in your fleet to warm them up. With Provisioned Concurrency, you need neither the function nor the CloudWatch Events schedule. It also takes away the overhead of having to remember to add any new functions you create, to the warmer’s list.

Conclusion

All-in-all, Provisioned Concurrency is a great replacement for warmup solutions, especially when you take into consideration, all its sub-features, like scheduled warming, wherein you can schedule your Lambdas to stay warm only for the period when you’re expecting traffic. Read more about Provisioned Concurrency in the official documentation.