AWS Step Functions

Q: When should you use AWS Step Functions?

Use Step Functions when a process has multiple steps that must run in order, with branching, parallelism, retries, or error handling between them — and you want that control logic in the workflow definition instead of scattered through function code. It's the wrong tool for a single call with no orchestration (invoke Lambda directly), plain event routing or fan-out (that's EventBridge or SNS ), or high-throughput ordered stream processing (that's Kinesis).

Q: What's the difference between Standard and Express workflows?

Standard workflows run exactly-once, up to a year, with full execution history — for long-running, auditable, or human-in-the-loop flows, billed per state transition. Express workflows run at-least-once (steps must be idempotent), up to five minutes, at very high throughput, billed per request plus duration — far cheaper at high volume. Only Standard supports the Run-a-Job (.sync) and Wait-for-Callback (.waitForTaskToken) patterns.

Q: How much does AWS Step Functions cost?

It depends on the workflow type. Standard bills per state transition — every step your execution moves through — so a chatty workflow run at high volume gets expensive. Express bills per request plus duration and memory, which is one to two orders of magnitude cheaper at high volume. Verify current rates on the official pricing page before estimating a real bill.

Q: Can Step Functions call Lambda and write to DynamoDB?

Yes. A Task state can invoke a Lambda function, read or write a DynamoDB item, publish to SNS , send to SQS , put an event on EventBridge , or read/write S3 objects. Each runs under the state machine's execution role, which must grant that action on the target — Design Beaver flags the missing IAM as you draw.

What Step Functions is

Step Functions runs a workflow for you. You define a state machine — a set of steps with ordering, branching, parallelism, retries, error handling, and waits — and it executes each step, calling other AWS services along the way and tracking exactly where every run is. The steps that call out to other services are Task states; the states around them (Choice, Parallel, Map, Wait, Retry, Catch) handle the flow.

The point is that the coordination logic lives in the workflow, not hand-rolled in your code. No polling loops, no ad-hoc retry code, no “what happens if step 3 fails after step 2 already succeeded.” Every state machine runs under an execution role, and each Task state’s call uses that role — which is where most of the real work hides. Design Beaver models Step Functions as a regional orchestrator and validates as you draw which services a step can call and the IAM each of those calls needs.

When to use Step Functions (and when not to)

Reach for Step Functions when a process genuinely has multiple steps in a defined order, with branching, parallel work, or error handling between them — and you want the retry, catch, wait, and timeout logic in the workflow definition rather than buried in function code. The visual execution history is a real operational win: you can look at a stuck run and see exactly which state it stopped on. It’s also the natural fit for long-running or human-in-the-loop processes, since a Standard workflow can run for up to a year and pause mid-flight for an external callback.

Don’t reach for it for a single call with no orchestration — just invoke Lambda directly; a one-step state machine is pure cost and indirection. Plain content-based routing or fan-out of discrete events is EventBridge or SNS, not a workflow. High-throughput ordered stream processing is Kinesis. And at very high volume, a Standard workflow’s per-transition billing adds up fast — that’s what Express is for.

Variants: Standard vs Express workflows

The one real decision when you place a state machine is the workflow type — and it’s not a small one. It changes the execution guarantee, the time limit, which integration patterns you get, and how you’re billed.

Option	What it is
Standard workflowdefault	Exactly-once execution, durable and auditable, runs up to one year. Full execution history retained. Supports all service-integration patterns including Run-a-Job (.sync) and Wait-for-Callback (.waitForTaskToken). Priced per state transition. Use for long-running, human-in-the-loop, or audit-sensitive workflows.
Express workflow	At-least-once execution (a step can run more than once, so steps must be idempotent), runs up to five minutes, up to 100,000 state transitions/sec. Supports only Request-Response integrations, not .sync/.waitForTaskToken. Priced per request plus duration/memory — far cheaper at high volume. Use for high-throughput, short-lived event processing.

Step Functions pricing

The trap is picking Standard by default and running a high-volume pipeline through it. Standard bills per state transition — every step counts — while Express bills per request plus duration, which is dramatically cheaper at scale. Match the workflow type to the workload before you worry about anything else.

Two separate models by workflow type. Standard workflows bill per state transition (each step your execution moves through). Express workflows bill per request (execution started) plus duration (rounded up to the nearest 100ms) and the memory used, in 64-MB chunks.

Option	Representative rate
standard	$0.025 per 1,000 state transitions ($0.000025 per transition)
express	$1.00 per 1,000,000 requests, plus a duration charge per GB-hour (billed per 100ms in 64-MB memory chunks)

Free tier

Standard workflows: 4,000 state transitions per month (Always Free)
Express workflows: no free tier confirmed this pass — treat as billed from the first request

Keeping the bill down

Use Express workflows for high-volume, short, idempotent workloads — dramatically cheaper than Standard at scale (per-request vs per-transition)
Minimize the number of states in a Standard workflow — every transition is billable; collapse trivial passthrough states where you can
Do bulk/looping work inside a single Lambda step rather than as many state transitions when the per-transition count would balloon

us-east-1 (rates vary by region). Rates as of 2026-07. Verify at the official pricing page before using for real cost estimates — this list is not kept in sync with AWS pricing changes.

How Step Functions connects to other services

A workflow diagram is just boxes until you know which services each Task state can actually call and what that call requires. Almost every Step Functions connection is an IAM edge: the state machine’s execution role has to grant the specific action on the target — lambda:InvokeFunction, dynamodb:PutItem, sns:Publish, and so on. Design Beaver models each of these edges, so it knows what a workflow can orchestrate and what makes each call correct.

Lambdasecurity
A Task state invokes a Lambda function (the optimized Lambda integration) — the most common Step Functions step, running your custom logic for one stage of the workflow
IAM:lambda:InvokeFunction
DynamoDBsecurity
A Task state reads or writes a DynamoDB item directly (the optimized DynamoDB integration — GetItem/PutItem/UpdateItem/DeleteItem/Query) with no Lambda in between, for simple persistence steps in the workflow
IAM:dynamodb:GetItemdynamodb:PutItemdynamodb:UpdateItemdynamodb:DeleteItemdynamodb:Query
SNSsecurity
A Task state publishes a message to an SNS topic (the optimized SNS integration) to notify subscribers as a workflow step — e.g. announce that an order was processed
IAM:sns:Publish
SQSsecurity
A Task state sends a message to an SQS queue (the optimized SQS integration) to hand work off to a downstream consumer — including the Wait-for-Callback (.waitForTaskToken) pattern, where the workflow pauses until the consumer calls back with the task token (Standard workflows only)
IAM:sqs:SendMessage
EventBridgesecurity
A Task state publishes a custom event to an EventBridge event bus with PutEvents (the optimized EventBridge integration), so other services react through rules without the workflow calling them directly
IAM:events:PutEvents
S3security
A Task state reads or writes an S3 object directly through the AWS SDK integration (e.g. arn:aws:states:::aws-sdk:s3:getObject / putObject) — for pulling a config/input object or writing a result without a Lambda step
IAM:s3:GetObjects3:PutObjects3:ListBucket

What Step Functions can’t connect to

Some edges look reasonable on a canvas but have no Step Functions integration behind them — a Task state can’t run a SQL query against a database or make a network call to software on an instance. Design Beaver flags them instead of letting you draw a diagram that can’t be built.

RDS
RDS has no Step Functions service integration — a state machine can't run a SQL query against a relational database directly. Put a Lambda step (or use the RDS Data API from a Lambda) between the workflow and RDS to touch the database.
EC2
A state machine doesn't make network calls to software running on an EC2 instance — there's no EC2 target for a Task state. To reach an EC2-hosted service from a workflow, invoke a Lambda step that calls it, or front it with an API the workflow can call.
CloudFront
CloudFront is a CDN that serves content to end users from HTTP origins — it is neither a Task-state target nor something that starts an execution. There is no Step Functions <-> CloudFront relationship to draw.
Route 53
Route 53 is DNS — a state machine has no DNS-addressable hostname and DNS is not a workflow step. There is no Step Functions <-> Route 53 edge; the workflow reaches services through their APIs, not a domain name.

Anti-patterns Design Beaver catches

These are the Step Functions mistakes that pass a diagram review but cost you in production — the ones the validation engine flags as you draw.

Using a Standard workflow for a very high-volume, short-lived, idempotent pipeline

Why it breaksStandard workflows bill per state transition ($0.025 per 1,000) — at high event volume that dominates cost, where Express workflows (priced per request + duration) are one to two orders of magnitude cheaper

Do this insteadUse Express workflows for high-volume, short (<5 min), idempotent event processing; keep Standard for long-running, auditable, or human-in-the-loop flows

Wrapping a single Lambda invocation in a state machine with no other steps

Why it breaksA one-step workflow adds per-transition cost and an extra layer of indirection without any orchestration benefit — there's no branching, retry-across-steps, or coordination to justify it

Do this insteadInvoke the Lambda directly (or from API Gateway/EventBridge); reach for Step Functions once there are genuinely multiple coordinated steps

Passing large payloads (files, big result sets) through workflow state between steps

Why it breaksStep Functions caps the state passed between steps at 256 KB per payload — large data will exceed it and fail the execution

Do this insteadStore the large object in S3 and pass only its key/pointer through the workflow state; have each step read what it needs from S3

Gotchas that bite in production

Standard billing is per state transition, not per execution. A chatty workflow with many small states, run often, can cost far more than you’d expect. Collapse trivial passthrough states, move looping or bulk work inside a single Lambda step, or use Express.
Express is at-least-once. A step can run more than once, so every step in an Express workflow must be idempotent. Standard is exactly-once — don’t carry one’s assumptions into the other.
.sync and .waitForTaskToken are Standard-only. If a step must run a job to completion and wait, or pause for an external callback, it can’t run as Express. Express supports Request-Response integrations only.
There’s a 256 KB limit on the state passed between steps. Push a file or a big result set through workflow state and the execution fails. Store the large object in S3 and pass its key instead; each step reads what it needs.
The execution role is easy to under-scope. Every service a Task state touches needs its action granted on the role, and a missing permission fails the step at runtime, not at deploy time. This is exactly the kind of edge Design Beaver surfaces as you draw.

Frequently asked questions

When should you use AWS Step Functions?

Use Step Functions when a process has multiple steps that must run in order, with branching, parallelism, retries, or error handling between them — and you want that control logic in the workflow definition instead of scattered through function code. It's the wrong tool for a single call with no orchestration (invoke Lambda directly), plain event routing or fan-out (that's EventBridge or SNS), or high-throughput ordered stream processing (that's Kinesis).

What's the difference between Standard and Express workflows?

Standard workflows run exactly-once, up to a year, with full execution history — for long-running, auditable, or human-in-the-loop flows, billed per state transition. Express workflows run at-least-once (steps must be idempotent), up to five minutes, at very high throughput, billed per request plus duration — far cheaper at high volume. Only Standard supports the Run-a-Job (.sync) and Wait-for-Callback (.waitForTaskToken) patterns.

How much does AWS Step Functions cost?

It depends on the workflow type. Standard bills per state transition — every step your execution moves through — so a chatty workflow run at high volume gets expensive. Express bills per request plus duration and memory, which is one to two orders of magnitude cheaper at high volume. Verify current rates on the official pricing page before estimating a real bill.

Can Step Functions call Lambda and write to DynamoDB?

Yes. A Task state can invoke a Lambda function, read or write a DynamoDB item, publish to SNS, send to SQS, put an event on EventBridge, or read/write S3 objects. Each runs under the state machine's execution role, which must grant that action on the target — Design Beaver flags the missing IAM as you draw.