When using AWS Lambda, you are billed for every millisecond your Lambda function takes to run, depending on how much memory you have allocated. A function configured for 256 MB of memory will cost twice as much as a function configured for 128 MB of memory per millisecond. At first, it may seem that you should allocate as little memory as possible to reduce costs. However, the memory configuration also controls how much CPU power, network bandswidth, and disk I/O you get, and that plays a major role in how long your function takes to execute. Functions that take less time to execute reduces how much you get billed for its invocation.
In a presentation by Harrell Stiles during re:Invent, he benchmarked that the same function allocated with 1024 MB of memory ran over 10 times faster for only $0.00001 more than the 128 MB equivalent, and outperformed the same function allocated with 256 MB and 512 MB of memory. This is due to the additional CPU power that was allocated behind the scenes to the function, which allowed it to complete its task faster. If the function had relied on network and/or disk I/O, it could have also benefited from the increased network and disk bandswidth.
The same presentation noted that Lambda functions allocated with at least 1.8 GB of memory also becomes multi-core. This is useful for improving the performance of functions that make network and/or disk I/O requests. Even if you are using Node.js, the extra core allows for more operating system level threads managed by the underlying
libuv library to run, and you should see performance improvements as a result.
As a caveat, if your Lambda function’s main goal is to start and wait for another process (e.g. a long web request), you should allocate as little memory as possible, since the extra memory would only increase cost without decreasing the wait time. Alternatively, consider doing things asynchronously (e.g. with a callback) so that the Lambda function can halt after making the request.
In the end, if you need to be precise about the performance and/or cost of your application, you need to test the different memory configurations yourself. In most cases, you should allocate at least 1.8 GB of memory for network and/or I/O heavy functions and at least 1024 MB of memory for all other functions.
Major changes to serverless-dotenv-plugin
The Serverless Framework has a new variables engine starting in email@example.com. This is part of a larger initiative by the...
Using dotenv with the Serverless Framework
In my [previous post](https://blog.neverendingqs.com/2021/03/30/major-changes-to-serverless-dotenv-plugin.html), I advised that the [serverless-dotenv-plugin](https://github.com/neverendingqs/serverless-dotenv-plugin) will no longer be able to load environment variables in time...