A Simple AWS Lambda Pricing Guide
In this post, we'll take a look at some of the trickier aspects of Lambda pricing and provide you a detailed aws lambda pricing guide.
In this post, we'll take a look at some of the trickier aspects of Lambda pricing and provide you a detailed aws lambda pricing guide.
If you go to AWS's Lambda pricing page, it looks like the cost of running a lambda is fairly straightforward. You find how much memory you're using in the pricing chart and multiply it by the number of milliseconds that your function will be running. Then, you add a small fee for the number of executions and you have your estimate. But the reality is that there are a lot of factors that play into the final cost of your bill.
In this post, we'll take a look at some of the trickier aspects of Lambda pricing. You'll leave armed with enough knowledge to effectively reduce your bill before you even deploy your first function.
When you use lambdas, you have to adopt a serverless mindset, which can be difficult at first. When it comes to billing, the biggest difference from other AWS compute services is that you aren't paying to have something run all month long; you're paying per request and the number of milliseconds it takes to handle that request.
If you're already developing on AWS with services like EC2, then you'll be used to having different pricing tiers to choose from
If you're already developing on AWS with services like EC2, then you'll be used to having different pricing tiers to choose from. For example, you can get huge price reductions if you commit to using an EC2 instance for a few years. Or, conversely, you can bid for high-performance machines with spot instances.
Lambda originally didn’t have any of those options to adjust your bill and then Savings Plans were expanded to cover Lambda compute. This said, the main lever to adjust Lambda pricing is to adjust the resources allocated to a lambda (similar to selecting an EC2 instance type).
Even so, while you can't reduce your bill with pricing tiers as heavily as with EC2 instances, serverless does reduce time and money expenses that don't show up on your bill. By taking advantage of serverless methodologies, you can offload a lot of work to AWS engineers. For example, if your app is running on EC2, then you're responsible for patching and updating all of the software running on that instance. With a lambda, that's handled for you. This means your employees can focus on business-specific development tasks.
For more information about serverless and total cost of ownership, see this article.
Another gotcha with lambdas is that since you pay by the millisecond, idle time is a waste of money. In other words, when your lambda calls an API and waits for the result, you'll be paying for all of that time. If the latency is bad enough on an API being called by a web app, the end user can get impatient and start hitting refresh. Now you have even more of these slow executions showing up on your bill, all of which you have to pay for.
And since Lambda pricing is directly tied to the number of events that it handles, the cost can be a lot less predictable than EC2. This can be especially painful if you accidentally create an infinite loop of events.
EC2's on-demand instances have a bit of a misleading name when you're coming from a serverless mindset. In the case of EC2, it means spinning up an instance on demand without agreeing to keep it around for any period of time. Lambda, on the other hand, is based on the demand of your users. If they aren't sending requests, then you don't get billed.
With this knowledge of Lambda's pricing, you're probably wondering if there are ways to reduce Lambda costs. Luckily, there are!
There are four categories of ways to reduce your Lambda costs:
Let's take a look at each of those categories and the different strategies you can use to achieve lower Lambda costs.
The first thing you should do when creating an event-driven application is set up some alerts to let you know when something is eating up your budget. This can help mitigate the issue mentioned above where you accidentally introduce an event loop into your system.
Once you have alerts set up, it's a good idea to enable cost allocation tags for all of your projects. If you tag all of your resources with their project name, then you'll be able to generate a report at the end of the month that shows exactly how much you spend on each resource for a specific project. For more details, see A Complete Introductory Guide to AWS Cost Allocation Tags.
Since AWS bills for lambda execution by the gigabyte-second, the easiest way to lower costs is to reduce the length of time that your lambda runs
Since AWS bills for lambda execution by the gigabyte-second, the easiest way to lower costs is to reduce the length of time that your lambda runs. There are a few strategies for this, one of which is a little counterintuitive.
The first suggestion comes straight from AWS's Lambda best practices. The idea is that when your lambda already has a warm instance, its global variables will stay set between executions. You can take advantage of this by keeping a cache in global variables to reduce the number of requests that you have to wait for.
In September 2021, AWS introduced a new processor option for Lambda. You can now use its ARM-based Graviton2 processors. AWS claims this processor will improve the speed of your lambda's execution by up to 34%. So, even though you probably won't get that big of a performance improvement, what you will get is a 20% reduction in price for the same resources.
This one may seem a little counterintuitive, but stay with me. You may be able to decrease your Lambda costs by increasing the memory that you assign to it. This works because the number of vCPU cores you get is tied to how much memory you assign to your lambda. So, to find out how many vCPU cores your lambda will get, divide the memory by 1706 MB.
If your lambda does a lot of I/O that it has to wait for, then this method may not work. But if you're running calculations, you should see a linear increase in speed as you increase the memory assigned. However, it will top out at 1706 MB unless you developed your lambda to run on multiple cores.
Once you've optimized your lambda and it's executing quickly, reduce the number of times that it's called. Calling your lambda fewer times is an indirect way of reducing execution time. There are a few ways to go about this—including replacing the lambda entirely.
If you're using a lambda to respond to requests from API Gateway, AppSync, or CloudFront, you can enable caching on that service. This gives two advantages: it reduces the number of times the lambda is called, and it reduces the overall latency of your endpoint.
You can configure event sources only to call the lambda when needed. For example, the S3 event source can filter based on keys. Configuring these filters means you only have to pay to process the events you actually care about. Doesn't that sound like an ideal solution?
If your lambda is making simple requests to other AWS services and requires minimal processing, then you should look into replacing your lambda with a VTL resolver. You can do this for AppSync and API Gateway. While VTL resolvers are a pain to develop, once you get them working you don't have to pay any fees to run them, and they don't suffer from cold start times. In fact, they are surprisingly quick.
If you don't have a lambda instance already running from a previous request, then AWS has to start one up for you. Depending on how large your code is, this can take a while since AWS has to unzip all of your code and then start execution.
Since the AWS Lambda pricing page states that AWS only charges you from the time your code starts running, you may be wondering why you should care about cold start times. While they don't have a direct effect on your bill, cold starts will cause latency, which can indirectly increase your costs.
Suppose you have a path in API Gateway that uses a lambda with a long cold start time. If you have a second lambda that sends a request to that path, it'll have to wait for the first lambda's cold start. That means you'll have to pay for it in the calling lambda. Also, if you have an impatient user calling that same path from a web app, they may start hitting the refresh button, spamming you with requests that you have to pay for.
The best way to reduce cold start times is to keep your lambdas focused on one specific task. This will minimize the amount of code they need to unzip during a cold start. You can speed up cold starts even more by using a bundler like ESBuild. ESBuild will minimize the disk size of your code and the code of your dependencies.
If your lambda is processing messages off of an SQS queue, then take advantage of batching to reduce cold starts. Since AWS will use up to five lambda executions in parallel, you need to configure your queue visibility timeout to six times your function's timeout plus your batching time window.
CloudThread combines billing and performance data to help you identify areas that can be optimized to reduce costs
If you're trying to optimize your lambda costs using a third-party tool, you can't use one that's focusing on EC2 rate optimization. As you've seen, when you make your code more efficient, it reduces your Lambda bill and unit metrics are the foundation for tracking cost efficiency. CloudThread combines billing and performance data to help you identify areas that can be optimized to reduce costs.
In this post, you've seen several ways your lambda costs can add to your bill. The most important way to fight costs is to know their cause. In that light, make sure you set up some observability in your lambdas.
Once you know what your lambda is doing, start optimizing it. Find the right amount of memory to balance speed and cost. Next, optimize methods to run faster. Finally, find ways to call the lambda fewer times.
You should now be able to confidently deploy a serverless application with lambdas and not be worried about astronomical costs for your functions.
