AWS Step Functions (Orchestration)
Key concepts
State machines
Standard vs Express workflows
Task, Choice, Parallel states
Error handling and retries
Service integrations
Overview
AWS Step Functions is a serverless orchestration service that coordinates multiple AWS services into visual workflows called state machines. Instead of embedding orchestration logic, retries, and error handling inside a single large Lambda function, you describe the flow declaratively and let Step Functions manage state, transitions, and failure recovery for you.
Step Functions matters on the SAA-C03 exam because it is the canonical answer for "coordinate several steps reliably" scenarios: multi-step order processing, data pipelines, saga-style distributed transactions, and human-approval flows. You should know when to choose Standard versus Express workflows, the common state types, how retries and catchers work, and how Step Functions integrates directly with other services.
Centralized Orchestration
Reach for Step Functions when a process has multiple ordered steps that need reliable error handling, branching, or coordination across services. It replaces brittle "Lambda calls Lambda" chains with a managed state machine that tracks every transition.
Focus on Standard vs Express selection (duration, pricing, execution guarantee), the Task/Choice/Parallel/Map state types, Retry and Catch fields, and the three integration patterns: Request-Response, Run a Job (.sync), and Wait for Callback (.waitForTaskToken).
Key Concepts
State Machines and Amazon States Language
State Machine
A state machine is a workflow defined in Amazon States Language (ASL), a JSON structure. Each state does one thing: perform work, make a decision, run branches in parallel, wait, or end the workflow. Execution starts at the StartAt state and follows Next transitions until it reaches a terminal state.
{
"Comment": "Validate then process an order",
"StartAt": "ValidateOrder",
"States": {
"ValidateOrder": {
"Type": "Task",
"Resource": "arn:aws:lambda:us-east-1:123456789012:function:Validate",
"Next": "ChargeCard"
},
"ChargeCard": {
"Type": "Task",
"Resource": "arn:aws:lambda:us-east-1:123456789012:function:Charge",
"End": true
}
}
}State Types
The States You Must Know
Task runs work (a Lambda, an ECS task, or another service action). Choice branches based on input values. Parallel runs multiple branches concurrently. Map runs the same steps over each item in an array. Wait pauses for a time or until a timestamp. Pass, Succeed, and Fail shape data or end the run.
Common State Types
| State | Purpose | Example Use |
|---|---|---|
| Task | Do work via a service | Invoke Lambda, run ECS task |
| Choice | Conditional branching | Route by order amount |
| Parallel | Concurrent branches | Fan out independent steps |
| Map | Iterate over a collection | Process each file in a batch |
| Wait | Delay execution | Wait 24 hours before reminder |
Standard vs Express Workflows
Two Workflow Types
Standard workflows run up to 1 year, guarantee exactly-once execution, show full execution history, and are priced per state transition. Express workflows run up to 5 minutes, are priced by number and duration of executions, and suit very high-volume, short-lived event processing. Standard fits long or auditable processes; Express fits streaming and high-throughput ingestion.
Standard vs Express
| Dimension | Standard | Express |
|---|---|---|
| Max duration | 1 year | 5 minutes |
| Execution guarantee | Exactly-once | At-least-once |
| Pricing model | Per state transition | Per execution plus duration |
| Execution history | Full, visual, retained | Sent to CloudWatch Logs |
| Best for | Long-running, auditable flows | High-volume, short event flows |
Error Handling: Retry and Catch
Built-in Resilience
Each Task state can declare Retry (re-attempt on listed errors with backoff) and Catch (route to a fallback state on failure). This pushes resilience into the workflow definition so individual functions stay simple. Use States.ALL as a catch-all matcher.
"ChargeCard": {
"Type": "Task",
"Resource": "arn:aws:lambda:us-east-1:123456789012:function:Charge",
"Retry": [
{
"ErrorEquals": ["States.TaskFailed"],
"IntervalSeconds": 2,
"MaxAttempts": 3,
"BackoffRate": 2.0
}
],
"Catch": [
{
"ErrorEquals": ["States.ALL"],
"Next": "RefundAndNotify"
}
],
"Next": "ShipOrder"
}Service Integrations and Patterns
Three Integration Patterns
Step Functions integrates directly with 200+ AWS services. Request-Response calls a service and continues immediately. Run a Job (.sync) starts work such as an ECS task or Glue job and waits for it to finish. Wait for Callback (.waitForTaskToken) pauses until an external system or human returns a task token, which powers approval steps.
Integration Patterns
| Pattern | Behavior | Use Case |
|---|---|---|
| Request-Response | Call and continue | Publish to SNS, put to DynamoDB |
| Run a Job (.sync) | Wait for completion | ECS RunTask, Glue, Batch |
| Wait for Callback (.waitForTaskToken) | Pause until token returned | Human approval, external system |
Best Practices
1. Keep Tasks small and idempotent
├── Step Functions may retry a Task
└── Design work to be safe to repeat
2. Put retries and catches in the state machine
├── Do not bury retry loops inside Lambda
└── Centralize failure handling in the workflow
3. Choose the workflow type deliberately
├── Standard for long or auditable processes
└── Express for high-volume short events
4. Use .sync for long jobs
└── Let Step Functions track ECS, Glue, Batch completion
5. Use .waitForTaskToken for human approval
└── Resume only when the token is returnedCommon Pitfalls
Pitfall 1: Orchestrating Inside One Giant Lambda
Mistake: Coding the whole multi-step flow, retries, and branching inside a single Lambda.
Why it fails: Hits the 15-minute Lambda limit, loses visibility, and makes failure recovery fragile.
Correct Approach: Model the steps as a state machine so each step, retry, and branch is explicit and observable.
Pitfall 2: Choosing Express for a Long Workflow
Mistake: Using an Express workflow for a process that can run longer than 5 minutes.
Why it fails: Express has a hard 5-minute limit and at-least-once execution.
Correct Approach: Use Standard for long-running or exactly-once workflows; reserve Express for high-volume short events.
Pitfall 3: Polling for Long Jobs
Mistake: Starting an ECS or Glue job, then polling its status in a Wait loop.
Why it fails: Wastes state transitions and adds latency and cost.
Correct Approach: Use the .sync integration so Step Functions waits for completion natively.
Test Your Knowledge
A workflow coordinates an order process that can take several days while it waits for a manager to approve a refund. Which Step Functions design fits best?
A team needs to orchestrate a very high volume of short event transformations, around 100,000 per second, each finishing in seconds. Which workflow type is most cost-effective?
A Task that calls a payment API occasionally fails with a transient error. The architect wants automatic retries with increasing delay before failing over to a refund step. What should they configure?
Related Services
Quick Reference
Key Limits
Step Functions Limits
| Resource | Default |
|---|---|
| Standard max duration | 1 year |
| Express max duration | 5 minutes |
| Max input/output size | 256 KB |
| Open executions per account | 1,000,000 (Standard) |
| State machine definition size | 1 MB |
Common CLI Commands
# Start an execution
aws stepfunctions start-execution \
--state-machine-arn arn:aws:states:us-east-1:123456789012:stateMachine:OrderFlow \
--input '{"orderId":"12345"}'
# Send a success token back (Wait for Callback)
aws stepfunctions send-task-success \
--task-token "$TASK_TOKEN" \
--task-output '{"approved":true}'
# Describe an execution
aws stepfunctions describe-execution \
--execution-arn arn:aws:states:us-east-1:123456789012:execution:OrderFlow:run-1