Lambda vs. Step Functions: The Battle of Cost and Performance

With the big push to use Step Functions over Lambda, you might be wondering “which is more cost-effective”? The answer might surprise you.

From WikiImages on Pixabay

Over the past couple of weeks, I’ve done some analysis on how you can start moving toward Step Functions as part of your standard development processes. You have the option to go “storage first” with completely asynchronous workflows or go completely synchronous with express state machines.

There are use cases for both, but the consensus for production development lives with a hybrid approach: performing a base set of actions synchronously, like validations and id creation and kicking off the rest of the processing asynchronously. You’d then use a WebSocket to inform the user when the workflow is complete.

Developers are curious in nature. I had a slew of people respond to my posts on LinkedIn and Twitter asking what the cost difference was between Lambda and Step Functions. After all, I was making a pitch to ditch Lambda completely. Seems like a justifiable question.

In order to figure out the impact on the wallet, we need to determine how each of these services are billed. AWS has a number of ways to charge you with their serverless services, but are great about transparency and the whole no hidden costs thing.

Let’s dive in and do some analysis on cost and performance of AWS Lambda vs AWS Step Functions.

Cost Factors

We are going to be comparing three different approaches today: Lambda, express workflows, and standard workflows with Step Functions. Below is a table of how each service bills for usage.

You can tune the amount of memory Lambda is allowed to consume, so your consumed GB/sec can vary based on what is configured. With Step Functions, the amount of memory it consumes can be calculated with the following formula:

50MB + state machine definition size + execution data size x Number of Parallel or Map Steps

Take the number calculated above rounded to the nearest 64MB and divide it by the average duration of the workflow to get the consumed GB/second…