AWS Step Functions

AWS’s serverless workflow engine: state machines in JSON that call AWS services directly.

What it is: Workflow orchestration
Type: Managed service on AWS
Made by: Amazon Web Services
License: Proprietary
Facts checked: 5 October 2026

What it is

A Step Functions state machine is a JSON document written in the Amazon States Language. Task states do work, Choice states branch, Wait states pause, Parallel and Map states fan out, and any Task can declare Retry and Catch rules. A Task can call more than 14,000 API actions across over 220 AWS services through SDK integrations, or any HTTPS API, so many workflows need no glue code at all. Data passed between states is shaped with JSONata expressions or the older JSONPath fields.

You pick one of two types when you create the state machine. Standard workflows run for up to a year, run each step exactly once, keep 90 days of execution history, and are billed per state transition. They can also wait for a job to finish (.sync) or for a callback carrying a task token, and their Distributed Map runs up to 10,000 child executions in parallel. Express workflows run for at most five minutes at much higher rates, at least once (asynchronous) or at most once (synchronous), and are billed by executions, duration and memory.

Why teams pick it

No workers or servers: AWS runs the engine and every step
Calls DynamoDB, SQS, ECS, Glue and hundreds of other services directly, without a Lambda in between
The console draws each execution as a graph, with every step’s input and output kept for audit
Standard workflows’ exactly-once steps suit non-idempotent work such as payments

Watch out for

Each state’s input or output is capped at 256 KiB, so large data must go through S3
A Standard execution’s history is capped at 25,000 events; long loops must hand off to new executions
Logic lives in a JSON DSL that’s harder to test and refactor than code, and it only runs on AWS
Per-transition billing makes busy Standard workflows expensive; high-volume work belongs in Express
Step Functions Local, the downloadable emulator, is now unsupported; AWS points to the TestState API for testing state logic

Alternatives

What all workflow orchestration have in common →

Cloudflare WorkflowsCommercialDurable execution on Cloudflare Workers: a workflow is ordinary TypeScript or Python code split into steps, and each step’s result is saved so a failed run retries that step and carries on instead of starting over.

PrefectOpen sourceA Python workflow orchestrator where a pipeline is an ordinary function decorated with `@flow`, with retries, caching, schedules and a UI added around it.

TemporalOpen sourceAn open-source durable execution engine: you write workflows as ordinary code and they survive crashes.

How it fits with other technologies

What AWS Step Functions uses

What uses AWS Step Functions

Charge with retries, then wait three days (JSONata) · json

{
  "QueryLanguage": "JSONata",
  "StartAt": "ChargeCard",
  "States": {
    "ChargeCard": {
      "Type": "Task",
      "Resource": "arn:aws:states:::lambda:invoke",
      "Arguments": { "FunctionName": "charge-card", "Payload": "{% $states.input %}" },
      "Retry": [{ "ErrorEquals": ["States.TaskFailed"], "MaxAttempts": 3, "BackoffRate": 2 }],
      "Next": "WaitThreeDays"
    },
    "WaitThreeDays": { "Type": "Wait", "Seconds": 259200, "End": true }
  }
}

See it in a real stack

No architecture uses AWS Step Functions yet. Drop it into the playground and wire it up yourself.Open playground →

Where it came from2012–2026

Amazon had wrestled with multi-step processes for years. Jeff Barr wrote in 2012 that he’d been told a single Amazon.com order “needed to make its way through at least 40 different states or steps before it was considered complete.” AWS’s first answer for customers was the Simple Workflow Service (SWF), launched in February 2012, in which you wrote “decider” programs that polled for events and chose the next step. It was powerful, but by the later account of the team that built it, developers found it complex.

Serverless functions made the need sharper, because a real application meant coordinating many small functions and services, with retries and error handling between them. On December 1, 2016 AWS launched Step Functions: you declare the workflow as a state machine in JSON, the Amazon States Language, and AWS runs it and draws it. Tim Bray, who edited the States Language specification, introduced it as a “Serverless Distributed Cloud Microservices Polyglot Workflow Orchestration Coordinator thingie.”

Since then Step Functions has learned to call AWS services directly, first a handful and from 2021 almost the whole AWS SDK, so many workflows need no glue functions at all. It has also added cheaper Express workflows, Distributed Map for very large parallel jobs, and JSONata for shaping data.

Why it’s built this way

Workflows as declarative JSON, not code: A States Language document can be validated, drawn as a graph and run by AWS with no customer code for the control flow. The price is a DSL that’s harder to test and refactor than a program, the opposite trade-off to Temporal’s.
Retries and error handling declared per state: Retry and Catch rules put failure handling in the workflow definition, so each function can stay small and unaware of what happens around it.
Billing per state transition: At launch AWS charged $0.025 per 1,000 state transitions, which suits long, low-volume business processes. High-volume event processing got the cheaper Express type in 2019.
Call AWS APIs straight from a Task: Direct service integrations, and later SDK integrations addressed by ARN, removed the Lambda functions early workflows needed just to call DynamoDB or SQS.

Timeline

2012
Amazon SWF, its predecessor, launches in February
2016
Step Functions launches at re:Invent on December 1
2019
Express workflows for high-volume, short runs
2021
SDK integrations reach over 200 AWS services; Workflow Studio
2022
Distributed Map for large parallel jobs
2024
JSONata transformations and variables
2026
Preview of an AI agent reasoning step (AgentCore)

Sources13 · facts checked 5 October 2026

Improve this page on GitHub