AWS Step Functions
Step Functions
You need to coordinate complex, multi-step workflows and microservices with visual state tracking and error handling.
Reach for it when
- Orchestrating a multi-step checkout workflow involving payment, inventory check, and shipping updates.
- Managing long-running data processing pipelines that require human approval steps before completing.
- Implementing try/catch/retry error logic across a series of independent serverless Lambda functions.
Do not reach for it when
- Passing high-throughput messages between two services without complex conditional logic — use SQS or SNS instead.
- Orchestrating simple code executions that can be handled inside a single Lambda function — use code logic instead.
- Building real-time web socket connections or API endpoints that require sub-second latency — use API Gateway instead.
Alternatives, and how to choose
| Service | Pick it instead when |
|---|---|
| EventBridge | Choose it when routing single events to targets based on payload rules rather than orchestrating state. |
| SQS | Choose it when you need simple queueing and buffering between two decoupled systems. |
How you pay
- The model
- Pay per state transition (Standard workflows) or per request and execution duration (Express workflows).
- The line item that surprises people
- Running Standard workflows for high-frequency short tasks can accumulate massive state transition fees.
What trips people up
- The execution history payload size is limited to 256KB; passing large datasets between states will fail.
- Standard workflows can run for up to one year, but Express workflows are capped at 5 minutes execution time.
- Failing to configure timeouts on task states can cause executions to hang indefinitely waiting for external responses.
Verify the live service
This page is a concept reference. Cost models are qualitative; confirm the current offering, Region and pricing before deploying.