Step Functions — Workflow Orchestration

State machines and tasks, retries/catch/parallel/map/timeouts/callbacks, and when the workflow deserves to be first-class

State machine = named states in JSON (ASL)a Task state runs one unit of work
Retry (same state) vs Catch (reroute)retry for transient errors, catch once retries are exhausted
Parallel (fixed branches) vs Map (per item)branch count: authored vs data-driven
Move orchestration out of one Lambdaonce retries/branches across services are the real complexity

1.State Machines, Tasks, and Executions

A Step Functions workflow is called a state machine — a series of steps called states, defined in JSON (Amazon States Language). A Task state runs one unit of work, usually a Lambda function or another AWS service call. Each time you start the state machine, that run is called an execution, and Step Functions records every state transition as execution history you can inspect afterward.

Key features

A state machine is defined in the Amazon States Language (ASL), a JSON-based structure of named states
A Task state is a single unit of work — commonly an AWS Lambda invocation, or a direct call to another AWS service via a service integration
Every state (except Succeed/Fail) needs a Next field pointing to the following state, or End: true to terminate the workflow there
An execution is one run of the state machine, started by the console, the StartExecution API, or an EventBridge rule, and produces JSON output from JSON input
Standard Workflows keep full execution history — every state entered, its input/output, and timing — retrievable via the API for 90 days after completion
Standard Workflows run exactly-once per state (unless Retry is configured) and can run for up to one year; Express Workflows run at-least-once and cap at five minutes

One execution through a two-state workflow

StartAtNextEnd: true

StartExecution

ValidateOrder (Task)

ChargeCard (Task)

Execution result

Command

state-machine.jsonjson

{
  "StartAt": "ValidateOrder",
  "States": {
    "ValidateOrder": {
      "Type": "Task",
      "Resource": "arn:aws:lambda:us-east-1:123456789012:function:ValidateOrder",
      "Next": "ChargeCard"
    },
    "ChargeCard": {
      "Type": "Task",
      "Resource": "arn:aws:lambda:us-east-1:123456789012:function:ChargeCard",
      "End": true
    }
  }
}

A state machine is a JSON workflow of named states; a Task state does one unit of work (usually a Lambda call). Each run is an execution, and Step Functions records every state transition as execution history you can inspect without adding your own logging.

2.Retries, Catch, Parallel, Map, Timeouts, and Callbacks

A Task, Parallel, or Map state can carry a Retry array (retry the same state on specific errors, with a growing wait between attempts) and a Catch array (route to a fallback state after retries are exhausted). A Parallel state runs a fixed set of branches at once; a Map state runs the same branch once per array item. TimeoutSeconds fails a Task that runs too long; the callback pattern (.waitForTaskToken) pauses a Task until an external system reports back.

Key features

Retry (on Task, Parallel, Map): ErrorEquals array to match, IntervalSeconds (default 1), MaxAttempts (default 3), BackoffRate (default 2.0) — each retry waits IntervalSeconds × BackoffRate^attempt
Catch (on Task, Parallel, Map): ErrorEquals array plus a Next state to transition to once retries are exhausted or absent; States.ALL matches any error and must be the last, standalone catcher
A Parallel state runs a fixed, hand-written set of branches concurrently — add a new branch by editing the definition
A Map state runs the same set of steps once per element of an input array, concurrently — the branch count follows the data, not the definition
TimeoutSeconds fails a Task with a States.Timeout error if it runs too long; HeartbeatSeconds fails it if a callback task goes silent for too long between heartbeats
The callback pattern (.waitForTaskToken) pauses a Task until an external system calls SendTaskSuccess or SendTaskFailure with that token — used for human approval or a third-party system finishing async work

Parallel vs Map

Parallel state

A fixed, hand-authored set of branches
Each branch can do something different
Branch count is part of the state machine definition

Map state

One branch, run once per array item
Every iteration runs the same steps
Iteration count follows the input data at run time

Signature

Retry { ErrorEquals, IntervalSeconds=1, MaxAttempts=3, BackoffRate=2.0 } · Catch { ErrorEquals, Next } · Parallel vs Map · TimeoutSeconds/HeartbeatSeconds · .waitForTaskToken

Retry: same state, growing wait, for transient errors (default 3 attempts, backoff ×2). Catch: reroute to a different state once retries are exhausted or the error is not retryable. Parallel: a fixed set of different branches. Map: one branch, once per array item. TimeoutSeconds/HeartbeatSeconds bound how long a Task or a callback can run silently.

3.Step Functions vs. Orchestration Crammed Into One Lambda

A single Lambda calling several other services in sequence, with its own hand-written retry loops and try/catch blocks, is orchestration logic hidden inside application code. Step Functions moves that same logic into a visible state machine definition, so each step, retry, and failure is inspectable in execution history instead of buried in a function's source and its logs.

Key features

A Lambda with nested try/catch blocks calling several other services has hidden orchestration logic — the workflow only exists as code, not as something inspectable
Step Functions makes retries, catch handlers, parallel branches, and timeouts declarative fields in the state machine definition rather than hand-written control flow
Standard Workflow execution history is retrievable via the API for 90 days after completion, showing every state's exact input and output — no custom logging required
Step Functions coordinates calls to over two hundred AWS services directly via SDK integrations, without a Lambda function in between for each one
A single Lambda has a hard execution timeout (15 minutes maximum); Standard Workflows can run for up to one year, which fits long-running, multi-step processes a single invocation cannot
The workflow type (Standard or Express) is fixed at creation and cannot be changed later — Standard fits long-running/auditable work, Express fits high-volume/short/idempotent work

Signature

Orchestration in one Lambda (hidden, 15-min timeout) vs Step Functions (declarative, inspectable, up to 1 year)

Once retry logic, error branches, and multi-service coordination inside one Lambda are the actual complexity, that is a sign the workflow deserves to be a first-class Step Functions state machine — declarative, inspectable execution history — rather than more code buried in one function.

Spotted a mistake on this page? Tell us.

Read Sheet