Step Functions: Standard vs Express, and the cost cliff

Step Functions gives you two workflow types that look almost identical in the console and bill on completely different axes. Pick the wrong one and you can overpay by two orders of magnitude — in either direction. The trap is that the cheaper choice flips depending on how often you run the workflow and how many steps it has, so "use Express, it's cheaper" and "use Standard, it's durable" are both advice that will burn you in the wrong context. Here is how the accounting actually works.

Two meters, two philosophies

Standard workflows bill per state transition: about $0.025 per 1,000 transitions in us-east-1, after a small monthly free tier. Every time execution moves into a state, that is one transition. In exchange you get durability — executions can run up to a year, every step is checkpointed, delivery is exactly-once, and the full execution history is retained and visually inspectable per run. This is the workflow type for long-running, low-volume, high-value orchestration: order fulfillment that waits days for a shipment, human-approval flows, ETL pipelines with retries measured in hours.

Express workflows bill like Lambda: a per-request charge (about $1.00 per million executions) plus a duration × memory charge billed in 100 ms increments against the memory the execution consumes. Executions are capped at five minutes. There is no durable, per-execution history in the console — you send logs to CloudWatch if you want observability, and asynchronous Express delivery is at-least-once rather than exactly-once. This is the workflow type for high-volume, short, stateless-ish work: per-event processing, streaming ingestion, API request orchestration where you run the thing millions of times a day and each run is over in milliseconds.

State-transition accounting, concretely

The reason Standard cost is unintuitive is that transitions are not the same as "steps you drew on the diagram." Every state entry counts. A Choice that routes, a Pass that reshapes data, a Wait, and each branch of a Parallel all count. The one that ambushes people is Map: a Map state that iterates over 1,000 items, where each iteration runs three states, is not a handful of transitions — it is roughly 1,000 × 3 = 3,000 transitions for that single execution. Fan-out multiplies your bill.

So when you estimate Standard cost, don't count boxes in the diagram; count states entered per execution, including every loop iteration, then multiply by executions.

The same workflow, two prices

Take a workflow with 6 state transitions per execution and run it 10 million times a month.

• Standard: 6 × 10,000,000 = 60,000,000 transitions. At $0.025 per 1,000, that is $1,500 a month, before any downstream Lambda or service cost.
• Express: $1.00 per million × 10 = $10 in request charges. If each execution runs about 200 ms at the smallest 64 MB tier, duration cost is a few dollars on top. Call it $15 to $40 all-in.

At that volume Express is roughly 100x cheaper, and it isn't close. The per-transition meter that was invisible at low volume becomes the entire bill at high volume.

Now invert the scenario. Take a durable, long-running workflow with 50 state transitions — approvals, waits, retries — that runs only 1,000 times a month.

• Standard: 50 × 1,000 = 50,000 transitions × $0.025 per 1,000 = $1.25. Plus you get exactly-once execution, a year-long runtime budget, and a full audit trail of every run for free.
• Express: can't even legally run this — the five-minute ceiling rules out anything with day-long waits — and if you forced the model, you would be paying duration × memory for wall-clock time the workflow spends idle, while losing durability and observability.

At low volume, Standard's transition cost is a rounding error and its durability is a genuine feature you would otherwise have to build yourself. This is the cliff: the curves cross, and which side you are on is determined by volume × transitions-per-run, not by which type sounds cheaper.

Nesting Express inside Standard

You do not have to choose globally. The strongest pattern for a workflow that is both long-running and high-volume-in-parts is to nest an Express workflow inside a Standard one. The outer Standard workflow owns the durable spine — the multi-day orchestration, the checkpoints, the human approvals, the retries you want journaled. When it hits a stage that fans out over thousands of items, it calls a nested Express workflow (via StartExecution.sync) to do that inner loop.

The payoff is in the accounting. If the outer Standard workflow ran the per-item loop itself as a Map, you would pay a Standard transition for every item's every state — thousands of transitions per execution at $0.025 per 1,000. Push that loop into a nested Express workflow and the inner iterations bill on Express's cheap request-plus-duration meter instead, while the outer workflow keeps only the handful of durable transitions that actually deserve journaling. You get Standard's durability where it matters and Express's price where the volume is.

The tradeoffs you are actually buying

The price difference is not free money; it reflects real differences in guarantees.

• Delivery semantics. Standard is exactly-once. Asynchronous Express is at-least-once, which means your downstream work must be idempotent — the same event can drive the same step twice. Synchronous Express returns the result to the caller but does not durably persist the execution.
• Observability. Standard retains execution history (about 90 days) with per-run visual debugging and redrive of failed executions built in. Express keeps nothing by default; you opt into CloudWatch Logs, and — worth remembering — that logging is itself billed by ingestion, so a very chatty high-volume Express workflow can quietly grow a CloudWatch bill that eats into the savings that made you choose Express. Log at the level you need, not everything.
• Runtime and state. Standard runs up to a year and checkpoints state durably across waits. Express runs at most five minutes and holds state only in memory for the life of the execution.

The rule I actually use

Estimate executions per month × states entered per execution. If that product is large and each run is short and under five minutes, Express, and make your steps idempotent. If runs are long, low-volume, or need a durable audited history, Standard, and stop worrying about the transition meter because at low volume it costs less than lunch. If the workflow is genuinely both — a durable outer process with a high-volume inner loop — nest Express inside Standard and bill each part on the meter that suits it. The cost cliff is only dangerous when you forget which side of it your traffic lives on.