Last time we covered some of the basics of AWS Lambda, so you should know what the service is, what it promises to do, and a little about how well it meets those promises. If not, check out the last post. Now let’s talk about pricing!
Lambda pricing is based on two fairly simple charges: $.20 per million executions of your function plus $0.00001667 per GB-second of processing. That means that if you specify 2 GB of RAM, the second part of the price will be twice as high as it would be if you specified only 1 GB of RAM. The good news is that the first 1 million executions of your function and 400,000 GB-sec of processing time per month are free. This is great for development, since before you’ve put your functions in production you generally need to do fewer executions than you do after the application goes live, and those test executions won’t cost you anything. This doesn’t include data transfer and storage charges that your application might incur when it uses other Amazon services, however.
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. This isn’t completely realistic since your function probably won’t take the same time to execute every time, but it should help you to visualize approximately how your charges will behave. By the way, Microsoft’s pricing for Azure Functions is virtually identical to Lambda’s and has the same 100 ms minimum charge, so this analysis applies there as well. As I write this, Google’s Cloud Functions service is still in alpha test, and I haven’t seen any published pricing yet.
Note that the red line for 50 ms functions is completely hidden underneath the purple line for 100 ms functions due to the 100 ms minimum charge. 200 ms functions cost twice as much as 100 ms, as would anything between 100ms and 200ms. If I added 150 ms functions to this chart, the line would be hidden under the orange line for 200 ms. That’s because execution times are always rounded up to the nearest 100 ms. for purposes of billing. That’s very important to understand if you want to avoid surprises on your bill, and, personally, I’m not a big fan of it. Come on, Amazon – just offer simple per-ms pricing with no minimum duration, and charges will be a lot more predictable.
Now, what about EC2? Since Amazon assigns resources to your function in the same proportion as a general-purpose compute instance, let’s use one of those as a hypothetical comparison. An on-demand m4large with 8 GB RAM currently costs $.108 per hour, which is $.0000037 per GB-second. If you reserve the instance for 3 years and pay up-front, it only costs $.04 per hour, or $.0000013 per GB-second. Let’s just assume that your functions execute sequentially as quickly as possible for an entire month (not real-world I know, but stay with me – this is just a hypothetical), and that once you’ve filled up a month of execution time you would need an additional instance to process any more. That tells us how many executions you can process per month on an EC2 instance and gives us a comparison that looks like this:
At very high loads on your EC2 instances, which corresponds to very high numbers of executions, Lambda is 4.5 times the cost of the on-demand instance and 11.4 times the cost of the reserved instance. So it’s a terrible deal, right? Well no, not really, and here’s why:
- On-demand instances won’t work. Lambda is designed for functions that must execute rapidly after being triggered by events. To get the benefit of on-demand EC2 pricing you would have to spin up that instance each time the function was called, and that’s the assumption that underlies the orange line in the chart. Unfortunately, that would add a tremendous amount of processing overhead, and your function would be dog slow. To use EC2 at all you would need your instance to be already available and waiting for a triggering event, and that means 100% instance usage per month. Reserved instances are always cheaper than on-demand at 100% usage.
- Your functions are very likely not going to run 100% of the time, and that’s the assumption that appears to be built into Lambda’s pricing. In this hypothetical scenario, Lambda’s sweet spot is on the left side of the chart, below 3 million function executions per month. Your mileage will vary a bit because your functions won’t take exactly this much time to execute (the further they are from a multiple of 100 ms, the less attractive Lambda will be), and you’ll want to be operating in the range where the free executions that come with Lambda still have a noticeable impact on your bill. That’s also where a reserved instance would still be very underutilized. If your traffic starts pushing you to the right side of the chart, consider using reserved instances to save money. Just make sure you take the next point into account as well.
- Lambda and EC2 can’t be directly compared without any adjustments, which is why I added the note at the bottom of the chart. We have an apples and oranges issue. Lambda is far closer to being a fully managed service than EC2 is. It includes things like patching, disaster recovery, backup and pretty much all standard IT management tasks that go with having a server other than security, as I mentioned in my last post. I estimate that to be worth about twice what you get from an EC2 instance in terms of reducing your internal IT costs. So, in our example, instead of switching to a reserved instance at just under 3 million executions per month, you should probably wait until about 6 million if you care about optimizing TCO for your infrastructure long-term. And that doesn’t include savings in the development cycle. Lambda is designed to trigger your functions in response to events that occur in social media streams, stored data, monitored states and other event sources. That should mean less coding for you. It’s also designed to auto-scale by default, without making you build that intelligence into your application. I’m not sure how much time this saves, but I’d love to hear from any developers out there with experience that can provide some input.
Hopefully that will help with decision making around when to use Lambda and other FaaS offerings, and when not to. Use them for event-triggered processes that need fast response times but that aren’t going to run in such high volumes that they would justify reserving an entire instance. Test your functions so that you can generate appropriate charts like the ones above and predict your costs. If you try out FaaS knowing what to expect, on applications for which it is well suited, I believe you will be very pleased with the results.