It is straightforward arithmetic, (for a 1GB function in us-east-1 at time of writing):0.0000000167 $/ms * 1000 ms/s * 60 s/min * 60 min/h * 24 h/day = 1.44 $/day
AWS Lambda is expensive if you're using it for regularly occurring, long-running processes that do not to take advantage of the very short scaling time the service provides. If the work requires constant processing throughout the day — and it is not unpredictably bursty or massively parallelizable with requirements to get the processing done ASAP — it is worth looking to move your compute needs to a different service. And, increasingly worthwhile the more RAM the processing requires.
Leaving more affordable (but more operationally complex) options to the side, let's do a quick comparison of Lambda vs. Fargate.
In this example, we have a Fargate container that runs 24/7 with no scaling, and a Lambda function that is invoked once a minute and runs for 60 seconds:
As you see in the graph above, at no point is doing this work in Lambda more affordable.
In the below example, we introduce a massive performance improvement in our Lambda code — dropping the execution time by two-thirds, down to 20 seconds:
This magic only brings the Lambda function's cost to what Fargate would charge for middle-of-the-road CPU allocation. 😒 I'd bet those performance improvements would work just as well in Fargate too. 😁
AWS Lambda is great, but it’s not great for everything. So, pay attention to your infrastructure patterns, folks!
Want more best practices? Explore Six Feet Up’s AWS blogs, and sign up for our newsletters to get tech tips in your inbox.