The content in this blog is outdated and we cannot reliably say it is still accurate with the speed in which the cloud industry moves. But don’t worry—below are more recent, up-to-date blogs.
The original version of this post was contributed by Scott Feuless and featured on the Cloud Service Evaluation blog. Scott is a leading cloud industry author and analyst and one of the world’s foremost experts on cloud service measurement and evaluation.
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:
- Since Lambda shines for functions that need to execute rapidly after events trigger them, On-Demand instances just won’t work. In order to take advantage of the On-Demand EC2 pricing you would need to spin up that instance every time we call the function, which is the underlying presumption of the orange line on the graph. This need would add a huge amount of overhead with processing, and your function would be painfully slow. In order to overcome the processing overhead, we would need our EC2 instance already available and waiting for an event to trigger the function, requiring 100% instance usage per month. Reserved Instances will always cost less money than On-Demand if they’re being used all the time.
- Most likely, your functions will not be running 100% of the time, which is the hypothesis that seems to be accounted for in Lambda's pricing model. In our scenario above, the left side of the chart is where Lambda truly shines, with a limit of 3 million executions/month. Your exact numbers will vary since your functions won’t take exactly this long to execute (the closer they are to a multiple of 100 ms the more attractive Lambda will be) and you want to stay within the limits of where the free executions that come with Lamda still noticeably impact your bill. This range is where Reserved Instances will also be underutilized. If traffic brings you to the right side of the cart, think about using Reserved Instances to save on costs, as long as you consider the next point.
- We should acknowledge that Lambda and EC2 can’t be exactly compared without any alterations, which is why I have a note at the bottom of the chart. We have an apples and oranges situation. Lambda resembles a managed service more than EC2 does, since it consists of patching, disaster recovery, backup and almost all standard IT management tasks that go with having a server other than security, as I went over in my last blog. In my opinion, the support you get with Lambda has about half the value of what EC2 gives you in relation to lowering your internal IT costs. Going back to our scenario, instead of moving to Reserved Instance at approximately 3 million executions per month, you should think about delaying the switch until about 6 million if you want to optimize the TCO for your infrastructure long term. And that doesn’t even take the savings from your development cycle into account. Lambda is meant to trigger functions in response to events that happen on social media, data, monitored states and other sources, which equates to less coding for you. It also defaults to auto-scaling without causing you to build that intelligence into your app. I’m not confident of the amount of time it saves but I’d love to get feedback from your experiences.
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.