Designing Workflow Orchestration with AWS Step Functions - Choosing Between Standard and Express
This article clarifies the criteria for selecting between Standard workflows and Express workflows and introduces declarative error handling with Retry/Catch and large-scale parallel processing with distributed map.
Basic Concepts of Step Functions
Step Functions is a serverless workflow orchestration service. You define a workflow as a state machine, and each state performs AWS service calls, conditional branches, and parallel processing. When you chain Lambda functions, you need to implement the call order between functions, error handling, and retry logic inside each function, but with Step Functions you describe these declaratively in the workflow definition (ASL). In the visual editor, you can build workflows by drag and drop and check the execution status in a graph in real time.
Choosing Between Standard and Express Workflows
Standard workflows persist the execution history for each state transition and support long-running executions of up to 1 year. The price is about $0.000025 per state transition (as of August 2026). They are suited to workloads that need auditing of the execution history and run relatively infrequently, such as order processing, approval flows, and data pipelines. Express workflows do not persist the execution history and are specialized for short executions of up to 5 minutes. Their pricing is based on the number of executions and the execution duration, and for large numbers of short executions they cost significantly less than Standard workflows. They are ideal for high-throughput / short-duration workloads such as event processing from IoT devices, API Gateway backends, and streaming data transformation.
Error Handling and Parallel Processing
In the Retry field of Step Functions, you can declaratively define the number of retries, the initial wait time, and the backoff rate for each error type. For example, you can configure control such as retrying Lambda.ServiceException up to 3 times with exponential backoff, while not retrying business logic errors and transitioning to another state with Catch. For errors caught in the Catch field, you can run notification sending or cleanup processing in a fallback state. The Map state runs the same processing in parallel for each element of an array. In distributed map mode, you can run large-scale batch processing with up to 10,000 parallel executions, using CSV or JSON files in an S3 bucket as input.
Step Functions Pricing
Standard workflows cost about $0.000025 per state transition, which comes to about $0.10 for 4,000 state transitions. Express workflows are charged by a combination of the number of executions (about $1.00 per million) and the execution duration (about $0.00001667 per GB-second). For high-throughput workloads executed thousands of times per second, the state transition charges of Standard workflows rise sharply, so Express costs significantly less. Conversely, for long-running workflows executed a few times a day, Standard is cheaper. The free tier is 4,000 state transitions per month for Standard workflows and 25,000 executions per month for Express.
Service Integrations and Invocation Patterns
The strength of Step Functions is that it can connect many AWS services with little code. Not only Lambda invocations but also a variety of services, such as writing to databases and sending messages, can be called directly from workflow steps. There are synchronous calls that wait for processing to complete before moving to the next step, asynchronous calls that only start the processing and do not wait, callbacks that wait for external processing to complete, and so on. You can choose the invocation method that fits the situation. Because you can combine services without writing glue code, you can focus on designing the processing flow itself and build workflows that are easy to maintain.
State Management and Passing Data
In a workflow, processing proceeds while data is passed between steps. Step Functions has a mechanism that transforms the output of the previous step and passes it as the input of the next step, and lets you extract or format only the parts you need. This lets you control the flow of data between steps declaratively. However, there is an upper limit on the size of data that can be passed between steps, so you design the workflow so that large data is placed in storage and only a reference is passed. Designing the data flow clearly means each step reliably receives the information it needs, and lets you keep the workflow easy to follow even for complex processing.
Observability and Debugging
A major advantage of Step Functions is that you can visually grasp the execution status of workflows. For each execution, a history is recorded of which steps ran when and whether they succeeded or failed. On the workflow represented as a diagram, you can see at a glance how far the processing progressed and where it stopped, which makes it easy to isolate problems. You can also trace the input and output of each step and identify why a step failed on unexpected data. If you combine execution logs and traces with monitoring, you can detect anomalies in production. Being able to visualize complex processing flows helps in both development and operations.
Typical Use Cases
Step Functions is put to good use in situations where you want to run multiple processes reliably in order. Typical examples include the orchestration of ETL that performs data extraction / transformation / loading in sequence, the coordination of processing that links multiple microservices, and business flows that include human approval partway through. You can also incorporate compensating processing that undoes the operations performed so far to maintain consistency when part of a series of processes fails. It also supports uses that process large amounts of data in parallel. Its value as a workflow platform lies in being able to assemble, with high reliability, stateful multi-step processing that a single function cannot fully express.
Summary
Step Functions is a service that manages the complexity of workflows in serverless architectures. It separates the coordination logic between Lambda functions from the code and lets you visualize / manage it with declarative workflow definitions. By optimizing costs through choosing between Standard and Express and standardizing error handling with Retry/Catch, you can build robust serverless applications.
References (Official AWS Resources)
The primary sources for this page are the official AWS website and documentation. Check the official pages below for the latest specifications and pricing.
- AWS Step Functions official page
- AWS Lambda official page
- Amazon EventBridge official page
- AWS Documentation (official)
If this page and the official documentation disagree, treat the official documentation as authoritative.