All cheat sheets
Serverless & AIcheat sheet

Step Functions Express Workflows

Step Functions bills Standard Workflows per state transition and Express per request + GB-second. For high-volume, sub-5-minute, idempotent orchestrations the same workflow runs 90–98% cheaper on Express — one config change.

Last reviewed: July 14, 2026

TL;DR: Step Functions has two flavors and teams reach for the expensive one by reflex. Standard ($0.025 per 1,000 state transitions) is built for long-running, exactly-once, audit-heavy flows up to 1 year. Express ($1.00/M requests + GB-second compute, 5-minute ceiling, at-least-once) is built for high-volume, short, event-driven work — and runs the same orchestration 90–98% cheaper. The migration is one setting change. The one thing you must verify first: every step is idempotent.

The numbers

  • Standard: $0.025 per 1,000 state transitions. An 8-step workflow × 10M runs/mo = 80M transitions ≈ $2,000/mo.
  • Express: $1.00/M requests + $0.00001667/GB-second. Same workflow at ~2s, 64MB ≈ $10 requests + ~$21 compute = ~$31/mo. 98.5% cheaper.
  • Savings scale with volume, not just percentage: IoT ingestion at 100M events/day went $10,000 → $150/mo ($118K/yr); a 500K-upload/mo media pipeline went $100 → $3/mo and started 40% faster (lower per-execution overhead).
  • Sync execution is an underrated win: Express can run synchronously (call it inline like a Lambda and wait for the result) — often the right architecture for API backends that need orchestration with a direct response.

Do this

  1. Sort Standard machines by invocation count in the console — start with the highest-volume one.
  2. Confirm the profile: short duration + high volume + idempotent steps. Any path that could exceed 5 minutes disqualifies Express — don't chain Express workflows to hack around it.
  3. Flip the type in the definition (literally one setting) to create an Express version.
  4. Enable CloudWatch Logs at ERROR level before production — Express has no built-in execution-history console, so this is your only visibility.
  5. Run side-by-side a few days, watch for duplicate executions, then shift traffic gradually and delete the old Standard machine once confident.

Gotchas

  • Express is at-least-once, not exactly-once — under rare failures a workflow instance can run twice. If every step is idempotent (PUT/overwrite, dedup-ID message, idempotency-token API call) this is a non-event. Charging a card, incrementing a counter, or sending an email without a dedup key will double up — add an idempotency key or stay on Standard.
  • No built-in execution history — skipping CloudWatch Logs setup means zero visibility when something breaks.
  • The 5-minute ceiling is hard — external polls, batch jobs, human approval, and activity tasks all need Standard.
  • Don't go "Express everywhere" — mature setups run a hybrid: Express for high-volume hot paths, Standard for approval/audit/long-running flows.

Skip this if

  • The workflow needs human-approval steps, runs longer than 5 minutes, requires strict exactly-once (billing without idempotency keys), or needs console-inspectable audit history for compliance — keep it Standard.
  • You want to squeeze the Lambdas inside the orchestration too — pair this with AWS Lambda Power Tuning for compounding savings.

Run this audit with your AI assistant

Paste this into Claude, ChatGPT, or any agent that can run the AWS CLI with read-only credentials. It audits your account for exactly the waste this sheet describes — and changes nothing.

You are auditing an AWS account's Step Functions state machines for
Standard -> Express migration savings. Use the AWS CLI with READ-ONLY
credentials. Do not create, modify, or delete anything — report findings
and recommended (unapplied) fixes only.

1. Inventory: aws stepfunctions list-state-machines, then
   describe-state-machine — capture name, type (STANDARD vs EXPRESS),
   and step count from the definition.
2. Volume + duration: for each STANDARD machine pull CloudWatch
   AWS/States ExecutionsStarted (Sum, 30 days) and ExecutionTime
   (Average, p99). Candidates = high volume AND p99 well under 5 minutes.
3. Cost math: Standard = $0.025 / 1,000 state transitions
   (transitions ≈ steps × executions). Express = $1.00/M requests +
   $0.00001667 per GB-second. Compute current Standard $/mo and
   projected Express $/mo per candidate; show the delta.
4. Idempotency + audit gate (flag, don't decide): does any step have a
   non-idempotent side effect (charge a card, increment a counter, send
   an email, append to a log) with no dedup key? Does the workflow need
   human-approval steps, activity tasks, >5-min paths, or console-grade
   audit history? Any of these => stay Standard or add idempotency first.

Report a table: state machine | type | steps | execs/mo | p99 duration |
idempotent? | audit/approval needs? | est. Standard $/mo | est. Express
$/mo | verdict (migrate / add-dedup-then-migrate / stay). Change nothing.
Works with any assistant that can run shell commands.

Want the guided version?

The Step Functions Express Workflows walkthrough covers this topic interactively — it asks about your setup, branches to what’s relevant, and quizzes you on the tricky parts. Free and anonymous.

Start the walkthrough