Standard vs. Express Workflows

When you create a state machine, you select a Type of either Standard or Express. The default Type
for state machines is Standard. A state machine whose Type is Standard is called a Standard workflow
and a state machine whose Type is Express is called an Express workflow.

For both Standard and Express workflows, you define your state machine using the Amazon States Language. Your
state machine executions will behave differently depending on the Type that you select.

Important

The Type you choose can’t be changed after you create the state machine.

Note

If you define your state machines outside the Step Functions’ console, such as in an editor of your choice, you must save your state machine definitions with the extension .asl.json.

Standard Workflows are ideal for
long-running (up to
one year), durable, and auditable workflows.
You
can retrieve the full execution history using the Step Functions API
for
up to 90 days after your execution completes. Standard Workflows
follow
an
exactly-once
model, where your tasks and states are never
run
more than
once,
unless you have specified Retry behavior in ASL. This makes
Standard
Workflows suited to orchestrating
non-idempotent
actions, such as starting an Amazon EMR cluster or processing payments. Standard
Workflow
executions are billed according to the number of state transitions processed.

Express Workflows are ideal for high-volume, event-processing workloads such as IoT data
ingestion, streaming data processing and transformation, and mobile application backends.
They can run for up to five minutes. Express Workflows employ an
at-least-once
model, where
an
execution
could
potentially run more than once. This makes
Express
Workflows ideal for orchestrating idempotent actions such as transforming
input data and storing
by
way of a PUT
action
in Amazon DynamoDB. Express Workflow executions are billed by the number of
executions, the
duration
of execution, and the memory
consumed while the
execution ran.

Standard and Express Workflows can automatically start in response to events such as HTTP
requests
from
Amazon API Gateway
(fully-managed
APIs at scale), IoT Rules and over 140
other
event sources in Amazon EventBridge.

Tip

To deploy an example of an Express workflow to your AWS account, see Module 7 – API Gateway, Parallel State, Express workflows of The AWS Step Functions Workshop.

For information about
the
console experience for Standard and Express Workflow executions, see Standard and Express Workflow executions in the console.

Standard vs Express Workflows

Standard Workflows
Express Workflows: Synchronous and Asynchronous

Maximum duration
One
year
Five
minutes

Supported execution start
rate
Over 2,000 per second
Over 100,000 per second

Supported state transition
rate
Over 4,000 per second
for
each account
Nearly unlimited

Pricing

Priced
by
number of state
transitions.
A
state
transition is counted each time a step in your execution is
completed.
Priced by the number of executions you run, their duration, and memory
consumption.

Execution history
Executions can be listed and described with Step Functions APIs.
Executions
can be visually debugged through the console. They can
also be inspected in CloudWatch Logs by enabling logging on your state
machine.

Unlimited execution history, that is, as many execution history entries are maintained as you can generate
within a 5-minute period.

Executions
can be inspected in CloudWatch Logs or the Step Functions console by enabling logging on
your state machine.

Execution
semantics
Exactly-once
workflow execution.

Asynchronous Express Workflows:
At-least-once
workflow execution.

Synchronous Express Workflows:
At-most-once
workflow execution.

Service
integrations
Supports all service integrations and patterns.
Supports all service integrations.

Note

Express Workflows do not support Job-run
(.sync)
or Callback
(.waitForTaskToken)
service integration patterns.

Step Functions activities
Supports Step Functions activities.
Doesn’t
support Step Functions activities.