Over the past few years, Lambda and Serverless have been mentioned more and more in the technology world. If you haven’t heard about it yet, a good primer is my most recent blog on the subject: What We Thought Cloud Computing Was All Along? To summarize, Lambda is solely about running code, thus eliminating as much of the infrastructure management and planning tasks as possible. This simplifies disaster recovery, as you won’t need redundancy across availability zones, and automated code backups.
Now that we know what Lambda is, we can move onto pricing. Lamba pricing is based on two factors: the number of executions of a function (priced at $.20 per million executions) plus the total GB seconds of processing (priced at $0.00001667 per Gbps). What this pricing model means is if you have 1GB of RAM allocated for processing, increasing your processing power to 2GB of RAM will double the second factor of the price. On the plus side, the first 1 million executions of your function and 400,000 GB-sec of processing time per month are free. However, you will also have to cover data transfer and storage charges that your application incurs if you use other Amazon services.
So, let’s take a look at what Lambda will cost you if your executions are 50 ms, 100 ms or 200 ms in length:
Since there is a minimum of 100 ms, you’ll notice that the red line for 50 ms functions is completely hidden underneath the purple line for 100 ms. If we look at the yellow line for 200 ms, we see that it’s double the cost of 100 ms. Anything between 100 and 200 ms would also cost double because Amazon rounds execution times to the nearest 100 ms to streamline billing. This is a very critical point, as you could get surprises on your bill this way.
So what about EC2? Let’s hypothetically compare EC2 with Lambda since Amazon designates resources to functions in a similar way to a general-purpose compute instance. If you have an On-Demand m4.large with 8 GB RAM, it will cost $.108/hour, or $.0000037 per GB-second. An upfront reservation for this instance with a 3 year term would cost us $.04/hour or $.0000013 per GB-second. For the purposes of this example, let’s consider functions that execute in sequence and as fast as possible for a whole month (I know this isn’t a real-world example - but bear with me) and that once the month of execution time is full you’ll need another instance to be able process more. This example tells us how many executions you’ll be able to process every month on an EC2 instance and will give us the below comparison:
By using the comparison above, it appears that Lambda is 4.5 times more costly than the On-Demand instance and 11.4 times pricier than a Reserved Instance at very high loads on your EC2 instances, which correspond to the larger amounts of executions. That looks like a horrible deal! Here’s why it’s not as bad as you think:
I hope this post helps you make more informed decisions about when to use Lambda and other function-as-a-service/serverless offerings. Definitely use Lambda for event-triggered processes that need quick response times but don’t run in high volumes that will make you reserve an entire instance. Make sure you test functions so you can generate your own charts like the ones above to better predict your bill. If you go into trying function-as-a-service/serverless with the knowledge of what to expect and use the best applications that are suited for the offering, I think you’ll enjoy the results.