Choosing Step Functions workflow type
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 Using Amazon States Language to define Step Functions workflows. 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 Amazon Web Services account, see Module 7 - API Gateway, Parallel State, Express workflows
For information about the console experience for Standard and Express Workflow executions, see Viewing workflow execution details in Step Functions.
Standard vs Express Workflows | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Standard Workflows | Express Workflows: Synchronous and Asynchronous | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Maximum duration | One year | Five minutes | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Supported execution start rate |
For information about quotas related to supported execution start rate, see Quotas related to API action throttling. |
For information about quotas related to supported execution start rate, see Quotas related to API action throttling. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Supported state transition rate |
For information about quotas related to supported state transition rate, see Quotas related to state throttling. |
No limit | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
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. For more information about debugging Standard Workflow executions in the console, see Viewing workflow execution details in Step Functions and Viewing and debugging executions. |
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. For more information about debugging Express Workflow executions in the console, see Viewing workflow execution details in Step Functions and Viewing and debugging executions. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
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. |
Synchronous and Asynchronous Express Workflows in Step Functions
There are two types of Express Workflows that you can choose: Asynchronous Express Workflows and Synchronous Express Workflows.
-
Asynchronous Express Workflows return confirmation that the workflow was started, but don't wait for the workflow to complete. To get the result, you must poll the service's CloudWatch Logs. You can use Asynchronous Express Workflows when you don't require immediate response output, such as messaging services or data processing that other services don't depend on. You can start Asynchronous Express Workflows in response to an event, by a nested workflow in Step Functions, or by using the
StartExecution
API call. -
Synchronous Express Workflows start a workflow, wait until it completes, and then return the result. Synchronous Express Workflows can be used to orchestrate microservices. With Synchronous Express Workflows, you can develop applications without the need to develop additional code to handle errors, retries, or run parallel tasks. You can run Synchronous Express Workflows invoked from Amazon API Gateway, Amazon Lambda, or by using the
StartSyncExecution
API call.Note
If you run Step Functions Express Workflows synchronously from the console, the
StartSyncExecution
request elapses after 60 seconds. To run the Express Workflows synchronously for a duration of up to five minutes, make theStartSyncExecution
request using the Amazon SDK or Amazon Command Line Interface (Amazon CLI) instead of the Step Functions console.Synchronous Express execution API calls don't contribute to existing account capacity limits. Step Functions provides capacity on demand and automatically scales with sustained workload. Surges in workload may be throttled until capacity is available.
Execution guarantees in Step Functions workflows
Standard Workflows | Asynchronous Express Workflows | Synchronous Express Workflows |
---|---|---|
Exactly-once workflow execution | At-least-once workflow execution | At-most-once workflow execution |
Execution state internally persists between state transitions. | Execution state doesn't persist between state transitions. | Execution state doesn't persist between state transitions. |
Automatically returns an idempotent response on starting an execution with the same name as a currently-running workflow. The new workflow doesn't start and an exception is thrown once the currently-running workflow is complete. | Idempotency is not automatically managed. Starting multiple workflows with the same name results in concurrent executions. Can result in loss of internal workflow state if state machine logic is not idempotent. | Idempotency is not automatically managed. Step Functions waits once an execution starts and returns the state machine's result on completion. Workflows don't restart if an exception occurs. |
Execution history data removed after 90 days. Workflow names can be reused after removal of out-of-date execution data. To meet compliance, organizational, or regulatory requirements, you can reduce the execution history retention period to 30 days by sending a quota request. To do this, use the Amazon Support Center Console and create a new case. |
Execution history is not captured by Step Functions. Logging must be enabled through Amazon CloudWatch Logs. | Execution history is not captured by Step Functions. Logging must be enabled through Amazon CloudWatch Logs. |