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.
NoteExpress Workflows do not support Job-run
( |
| Step Functions activities | Supports Step Functions activities. | Doesn't support Step Functions activities. |