July 25, 2019
We share a few tips on how to drive down excessive costs associated with serverless in your organization
One of the main appeals of AWS Lambda is its pricing model - you only pay for what you consume. Still, if you are not careful, due to the ease of use and scalable nature, the costs can quickly add up. Read on to learn the best ways to lower your AWS Lambda bills.
The AWS Lambda pricing model is quite straightforward. Just a quick recap: there are three parameters that are used to set the AWS Lambda pricing:
Every time a function is run, these two values are multiplied to produce the GB-second number. After the monthly allowance of 400,000 free GB-seconds from the free tier, your billable compute cost will be calculated by the total GB-second across all function invocations, multiplied by a fixed GB-second rate of $0.0000166667.
Optimize Memory Size And Duration
Since both parameters equally act as multipliers, the slightest changes to either the memory size or the execution time can significantly impact the billable cost. For example, an invocation that runs for two seconds would cost twice as much as an identical invocation with the same memory allocation that runs for one second, and a function with 256MB of memory that runs for 110 ms would cost twice as much as a function with 128MB of memory running for the same time.
Make the 100ms blocks work to your advantage
The duration is measured in 100ms blocks. All other things being equal, invocations that run for 25ms, 50ms and 99ms would end up costing the same. And that is precisely where it gets interesting.
Consider a 128MB invocation with an average execution time of 110ms. Since the duration is charged in fixed increments, you will pay for 200ms of execution time, or $0.000000416. This means that you end up paying a premium for the execution time that you don’t even use!
But what happens if you allocate more memory to speed up the function and bring the average execution time down to under 100 ms? Sometimes with 192 MB of memory you can achieve just that, reducing the invocation cost by 25%.
Make sure to take full advantage of this optimization opportunity and optimize your settings. Here is a great automated tool, built specifically for this purpose.
Important Note: Do not forget to adjust the function settings
It is important to remember that the Maximum Memory Size parameter discussed above is not the actual memory used by the function, but rather the fixed parameter you set up in the configuration settings. So unless you adjust the settings accordingly, the reduced memory usage will not translate into cost savings by default.
Be Stingy With the Maximum Memory Size
If you are an old-school engineer, your first instinct may be to build a sizable safety buffer beyond what the minimum requirements dictate. For example, if a Lambda function normally executes in 200ms, you may be tempted to set the maximum execution time parameter and to adjust the corresponding memory usage with a safety margin way beyond that, let's say to around 10 seconds.
To reduce costs you need to aim for the smallest maximum memory size and the corresponding execution time that you can safely get away with.
Function Warm Up Isn’t Free
Many developers keep their functions “warm” to avoid cold starts (as much as possible). This is done by calling your functions every few minutes for a very short duration. While “warm up” invocations are usually cheap, at scale, the costs that are associated with function warming, can add up. Plan your warm-up mechanism wisely.
Realize that you are still paying for idle
It is often claimed that with serverless you don’t pay for idle. This is not entirely correct.
If for example, a Lambda function makes an outgoing API call, the time it spent idle while waiting for a response will still be counted in the function’s execution time. This problem is compounded in a microservices architecture, where you can actually end up paying for these wait times, multiple times.
One way to reduce the idle time on your bill is to leverage a coordination service, such as AWS Step Functions.
Utilize AWS Step Functions Sparingly
AWS Step Functions lets you coordinate multiple AWS services into serverless workflows. A significant benefit of AWS Step Functions is the ability to wait an arbitrary amount of time between states.
The problem is that this service is quite pricey. Step Functions charge per number of transitions, and at $25 per million state transitions, it is a comparatively expensive service. Step Functions can be a lifesaver for businesses, especially in complex or long-running workflows, but should be used sparingly to avoid driving the costs through the roof.
Monitor The Event Source Costs
Besides the direct AWS Lambda costs, the costs of the event sources also add up. In fact, an API Gateway is likely to cost you way more than Lambda itself. Given the costs involved, especially at scale, you need to be especially vigilant with high throughput APIs on Lambda.
Reduce Peripheral Costs
Monitoring serverless is a new territory. Traditional methods will not work, and you need solutions that are made specifically for this purpose. An often overlooked cost of using Lambda lies with the external services you must use when observing your functions.
These tools integrate with the serverless runtime platform to collect essential data for better visibility and debugging, to improve performance and application security. But the third party monitoring tools and security solutions for your functions create a sizable overhead that can completely change the equation of Lambda’s viability for your functions.
Understand the Costs of Add-Ons in Context
When using third-party vendor solutions to enhance your serverless architecture, beyond the direct costs of the services, make sure to examine the overhead while keeping both the duration and the memory usage in mind.
Consider Enabling API Gateway Caching
API Gateway caching comes at extra cost and is not offered in the free tier. However, for some use cases the extra expense can be justified, as it can dramatically reduce the amount of times your Lambda functions will execute, driving your overall costs down.
Compared to other Cloud services, AWS Lambda itself may be relatively cheap. But the costs quickly pile up. Since the cost of Lambda functions is dependent on both execution time and memory size, increasing or reducing both (even slightly) can significantly drive up (or down) the total billable cost.
To keep the costs under control, always optimize and adjust the maximum memory size and execution time parameters, pay close attention to peripheral costs, and utilize premium features such as AWS Lambda Step Functions only when you absolutely need them.
Serverless reduces applications TCO (Total Cost of Ownership), but it doesn't mean you should have an inflated FaaS bill. Nuweba can help you keep serverless costs under control, while still being ultra-fast and armed with enterprise-grade security.