A concise explanation on why increasing the memory amount of a AWS Lambda function might actually save you money.

Are you building a web app or API? Or do you need to run serverless code? AWS Lambda is a great option. You only pay for what you use and you can run code without provisioning or managing servers. Since it’s a pay-as-you-go kind of compute service, many people are hesitant to use higher memory to boost AWS Lambda’s cpu speed. They fear paying too much.

But those fears are unfounded. In actuality, increasing the memory usage of AWS Lambda will save you money because the faster it can perform a function, the less time it will take to run code.

Since AWS Lambda is a “Function as a Service” (FaaS), a category of cloud computing that lets customers run application functionalities without needing to maintain infrastructure, you pay only for the compute time you consume. This means there’s no charge if your code is not running.

A main parameter of a Lambda function is the amount of memory available. Lambda allocates CPU power linearly in proportion to the amount of memory configured. According to the docs, at 1,792 MB a function is equivalent to one full vCPU (one vCPU-second of credits per second). The more memory you allocate, the faster your function will execute.

This is one of the main selling points of Lambda, but it can also make some users wary. Higher memory means higher cost. For example, in the eu-west-1 region (Ireland) it costs $0.0000166667 for every GB of memory per second. As you can see in the chart below, pricing is linear.

Evidence seems to show that increasing the memory of a Lambda function will result in a higher bill. But what if I told you that’s not always the case? That increasing memory size could actually save you money?

Increasing AWS Lambda speed saves money for two reasons.

First, higher memory lambda functions are faster, which means you’ll pay more per second, but it will take less time to run your code. Previously, Lambda charged for the number of times your code was triggered (the requests) and for the time your code executed, rounded up to the nearest 100ms (the duration). But during Amazon’s Re:Invent 2020 conference, they announced Lambda would switch to rounding up duration times to the nearest millisecond, with no minimum execution time. Because of this, it’s easy to find a sweet spot with memory speeds that allows a faster execution time for a lower cost.

The chart below shows how I achieved the lowest cost for my lambda functions at 1024MB of memory. The result was a 10% drop in cost with 9x the execution time.

The second way higher memory can save you money is thanks to a bigger bandwidth and network performance. Like ec2 machines, a more powerful Lambda gets better internet speed. This means that any SQL queries, S3 access, or API calls will return data faster. The result is quicker execution of your Lambda functions.

The major drawback is finding the optimal memory size to provide the best ratio of AWS Lambda speed over cost. So far, I haven’t found a good systematic way to find the sweet spot. I still rely on trial and error. But, with a little experimenting, you can find what works best for you. Personally, a memory size of 1024MB does the trick for me for most functions.

While you can save money by increasing Lambda speeds with higher memory, there are a few things to be aware of that could cause a higher bill.

First, you need to understand the AWS Lambda cold start. The ‘cold start’ refers to how Lambda is executed. When a container is created, AWS needs extra time to load the code and set up the environment, versus just reusing an existing container. Depending on your function, it can take a few milliseconds to a few seconds.

Unfortunately, cold start times don’t decrease even with higher memory. If your lambda function suffers from a long cold start, increasing speeds will have a limited positive effect on your bill. You’ll save money with execution, but the longer cold starts will eventually add up to higher costs.

The second issue to be aware of is third party requests. These requests may be from an API, a database, or another resource needing access. Since third party requests are outside your control, increasing the speed of your lambda will not reduce the execution time of your code. If you primarily use Lambda to access external resources, increasing memory probably won’t reduce your bill. In fact, you might pay more with no meaningful gain in the execution time.

It’s easy to see that increasing the memory of your Lambda function to save money is worth a try. Not only can you reduce your bill, you’ll also benefit from running faster code. Just remember: start slowly with trial and error until you find the sweet spot between memory speeds and cost. And stay mindful of any cold start problems and third party requests that might push your bill higher.

With a little experimentation and by watching your bill closely each month, you’ll be on your way to more savings and a smoother AWS Lambda experience.