Cost efficiency for AWS Lambda Provisioned Concurrency

Question

I'm running a system with lots of AWS Lambda functions. Our load is not huge, let's say a function gets 100k invocations per month.

For quite a few of the Lambda functions, we're using warmup plugins to reduce cold start times. This is effectively a CloudWatch event triggered every 5 minutes to invoke the function with a dummy event which is ignored, but keeps that Lambda VM running. In most cases, this means one instance will be "warm".

I'm now looking at the native solution to the cold start problem: AWS Lambda Concurrent Provisioning, which at first glance looks awesome, but when I start calculating, either I'm missing something, or this will simply be a large cost increase for a system with only medium load.

Example, with prices from the eu-west-1 region as of 2020-09-16:

Consider function RAM M (GB), average execution time t (s), million requests per month N, provisioned concurrency C ("number of instances"):

Without provisioned concurrency

Cost per month = N⋅(16.6667⋅M⋅t + 0.20)

= $16.87 per million requests @ M = 1 GB, t = 1 s

= $1.87 per million requests @ M = 1 GB, t = 100 ms

= $1.69 per 100.000 requests @ M = 1 GB, t = 1 s

= $1686.67 per 100M requests @ M = 1GB, t = 1 s

With provisioned concurrency

Cost per month = C⋅0.000004646⋅M⋅60⋅60⋅24⋅30 + N⋅(10.8407⋅M⋅t + 0.20) = 12.04⋅C⋅M + N(10.84⋅M⋅t + 0.20)

= $12.04 + $11.04 = $23.08 per million requests @ M = 1 GB, t = 1 s, C = 1

= $12.04 + $1.28 = $13.32 per million requests @ M = 1 GB, t = 100 ms, C = 1

= $12.04 + $1.10 = $13.14 per 100.000 requests @ M = 1 GB, t = 1 s, C = 1

= $12.04 + $1104.07 = $1116.11 per 100M requests @ M = 1 GB, t = 1 s, C = 1

There are obviously several factors to take into account here:

• How many requests per month is expected? (N)
• How much RAM does the function need? (M)
• What is the average execution time? (t)
• What is the traffic pattern, few small bursts or even traffic (might mean C is low, high, or must be dynamically changed to follow peak hours etc)

In the end though, my initial conclusion is that Provisioned Concurrency will only be a good deal if you have a lot of traffic? In my example, at 100M requests per month there's a substantial saving (however, at that traffic it's perhaps likely that you would need a higher value of C as well; break-even at about C = 30). Even with C = 1, you need almost a million requests per month to cover the static costs.

Now, there are obviously other benefits of using the native solution (no ugly dummy events, no log pollution, flexible amount of warm instances, ...), and there are also probably other hidden costs of custom solutions (CloudWatch events, additional CloudWatch logging for dummy invocations etc), but I think they are pretty much neglectible.

Is my analysis fairly correct or am I missing something?

Answer 1

I think about provisioned concurrency as something that eliminates the cold starts and not something that saves money. There is a bit of saving if you can keep the lambda function running all the time (100%) utilization, but as you've calculated it becomes quite expensive when the provisioned capacity sits idle.