Lambda vs Step Functions for Async Workflows: The Cost Call

For most small-team async workflows, plain AWS Lambda is cheaper than Step Functions, often by a wide margin. Step Functions Standard Workflows bill $0.025 per 1,000 state transitions, and a transition fires for every step, retry, and wait in your state machine. A five-step workflow costs roughly $0.000125 per execution before any compute runs — and that’s on top of the Lambda invocations the steps still trigger. If your background jobs are short, mostly linear, and run a few thousand times a day, you’ll almost always pay less by chaining Lambdas directly and skipping the orchestrator. Step Functions earns its price only when you need durable state, long waits, or human-in-the-loop branching that would otherwise force you to build the same machinery yourself.

The two cost models, side by side #

Lambda charges on two axes: $0.20 per 1 million requests and $0.0000166667 per GB-second of compute. A 256 MB function running 300 ms costs about $0.00000125 of compute plus $0.0000002 per request — call it $1.45 per million invocations at that size. There are no transition fees; you pay for the code that actually runs. If a background job is a straight pipeline — receive an event, transform it, write to a database — you can express the whole thing as one function or a short chain and pay only for execution time.

Step Functions adds a coordination layer on top of that compute. Each Task, Choice, Wait, Pass, Map iteration, and Parallel branch counts as a billed state transition on Standard Workflows. The orchestrator doesn’t replace your Lambda cost — it sits above it. So a five-step Standard Workflow that invokes five Lambdas pays the Lambda bill and the transition bill. At 1 million workflow runs a month with five transitions each, that’s 5 million transitions, or about $125/month in Step Functions fees alone — money that buys you nothing if your workflow never retries, branches, or waits.

Express Workflows change the math for high volume #

AWS offers a second Step Functions tier, Express Workflows, billed by request count and duration rather than per transition: $1.00 per 1 million requests plus a memory-and-time charge. For high-frequency, short-lived workflows — thousands of invocations per minute — Express can undercut Standard dramatically because you stop paying per step. The catch is that Express Workflows do not offer exactly-once execution semantics and carry a 5-minute maximum duration, so they fit event-processing fan-out, not long-running sagas. If your async job is a burst of quick transformations, Express is usually the right Step Functions tier; if it’s a slow multi-hour process with manual approvals, you want Standard.

When orchestration actually pays for itself #

The honest threshold is this: reach for Step Functions when recreating its features in Lambda would cost more in engineering time and reliability than the transition fees cost in dollars. Durable waits are the clearest case — a Standard Workflow can pause for up to a year waiting on a callback token, and you pay nothing for the idle time. Building that with Lambda means stashing state in DynamoDB, scheduling wake-ups with EventBridge, and writing your own retry-and-backoff logic. Centralized error handling, visual execution history, and built-in Catch/Retry blocks are the other genuine wins. For a team automating order processing or multi-stage ETL where a failed step must not silently drop work, that visibility is worth the $125.

What you should not do is default to Step Functions because it feels more ’enterprise.’ A two-step ’resize image, write metadata’ job does not need a state machine. Neither does a nightly report that runs 30 times a month — at that volume Step Functions costs fractions of a cent, so the decision there is purely about whether you want the orchestration features, not the price. The cost argument only becomes decisive at scale, which is exactly where a small team is least likely to be when they’re first wiring up background jobs.

Where Vylara fits #

Vylara reads your repository and figures out the async infrastructure your app already implies. When the Vylara agent detects a queue library like bullmq or celery during analysis, it surfaces that as a managed resource — a Redis-backed queue in your own AWS account — rather than silently assuming you want a full orchestration service. You see a plain ’Your app needs’ card with a monthly estimate (a managed cache runs around ~$8/mo), and you choose whether to provision it or point at something you already run. The architecture stays grounded in what your code does, not in a trend. This is the same philosophy we apply to the broader serverless vs managed containers decision: the cheapest correct choice depends on your actual access patterns, not a default.

Because everything lands in your account, the Step Functions and Lambda bills flow straight from AWS to you — Vylara charges for the orchestration and agent layer, not your compute. You review the generated deployment configs in a diff before anything deploys, and the first deploy is what provisions the environment; pushing to your repo updates configs but doesn’t quietly spin up cloud resources. If a background worker starts throttling or a queue backs up after launch, the in-app infrastructure chat can read your CloudWatch logs and metrics and propose a fix inline, with your approval required for any write. For the full picture of what we provision and manage on AWS, the AWS deployment pillar walks through the resource types end to end, and if you’re weighing idle cost on scheduled jobs, our guide on scheduling off-hours shutdowns pairs well with this one.

The short version: start with Lambda, measure your transition count before adopting Step Functions, and let the workflow’s real need for durability — not the word ’orchestration’ — drive the upgrade. At a few thousand runs a day you will not notice either bill; at a few million you absolutely will, and by then you’ll know exactly which features you’re paying for.