Comparison of Cold Starts in Serverless Functions across AWS, Azure, and GCP
This article compares Function-as-a-Service offerings of Big-3 cloud providers in terms of cold starts. AWS Lambda, Azure Functions (Consumption Plan), and Google Cloud Functions are all dynamically scaled and billed-per-execution compute services. Instances of cloud functions are added and removed dynamically. When a new instance handles its first request, the response time increases, which is called a cold start.
Read more: Cold Starts in Serverless Functions.
When Does Cold Start Happen?
The very first cold start happens when the first request comes in after deployment.
After that request is processed, the instance stays alive to be reused for subsequent requests.
The strategy for reuse differs very between the cloud vendors:
|Service||Idle instance lifetime|
|AWS Lambda||Mostly, between 25 and 65 minutes|
|Azure Functions||20 minutes|
|Google Cloud Functions||Usually, several hours|
Only Azure has the policy to recycle an idle instance after a fixed period. AWS, and especially GCP, employ some other strategies to determine the threshold, potentially based on the current demand-supply balance of their resource pools.
How Slow Are Cold Starts?
The following chart shows the comparison of typical cold start durations across all generally available languages of the three clouds. The darker ranges are the most common 67% of durations, and lighter ranges include 95%.
AWS clearly leads with all languages but C# being well below 1 second. GCP start-up usually takes slightly more than 1 second, while Azure is considerably slower.
Does Package Size Matter?
The above charts show the statistics for tiny “Hello World”-style functions. Adding dependencies and thus increasing the deployment package size will further increase the cold start latency.