AWS Step Functions
Workflow orchestration
Describes multi-step workflows (call Lambda, wait, branch, retry, run in parallel) as state machines with a visual diagram.
- Cost$ Low
- Difficulty●●●●●
- Costs money when idle?No
- Serverless
- In examsSAA · DVA · SOA
Think of it asLike a foreman with a checklist: the next step is assigned only when this one is done, and failed steps get redone.
Where does Step Functions fit?
Calls Step Functions
Step FunctionsStep Functions calls
A real example, step by step
- Order processing has steps: check stock, charge the card, send an email; if any step fails, earlier steps must be undone.
- You draw the workflow in Step Functions: each step calls a Lambda or an AWS service directly.
- If charging hits a network error, it retries 3 times with growing delays; if it still fails, it moves to a refund step.
- Large orders need a manager's approval: the workflow pauses until someone clicks approve, even for days.
- Every run shows each completed step and where it failed, so debugging is much faster.
When to use it
✓ Use it when
Multi-step workflows: order processing, data pipelines, steps waiting for human approval.
✗ Avoid it when
Just one simple step → call Lambda directly.
Common uses
- Multi-step ordering workflows with retries
- Data/ML processing pipelines
- Workflows with human approval steps
- Orchestrate multiple Lambda functions instead of nested calls
Step Functions, Lambda or EventBridge?
| Step Functions |  Lambda |  EventBridge | |
|---|---|---|---|
| Role | Orchestrates many steps | Runs one piece of code | Routes events |
| Run time | Up to 1 year (Standard) | Up to 15 minutes | Not applicable |
| Error handling | Built-in retry, catch, branching | You write it in code | Delivery retries, dead-letter queues |
| Best for | Multi-step processes, approvals | One short task | Reacting to events |
What does it cost?
- Pricing model: Standard: ~$0.025/1,000 state transitions. Express: per execution (~$1/1 million) + duration and memory.
- Free tier: Always Free (Standard): 4,000 state transitions/month.
Using Standard for very high-frequency flows (Express is much cheaper); Map loops with too many steps.
Orchestrate several Lambdas with retries, branching or human approval → Step Functions. Process thousands of S3 files in parallel → the Map state in Distributed mode. Long processes that must run exactly once → Standard; high-volume short ones → Express.
Try real exam questions
1A company recently migrated to the AWS Cloud. The company wants a serverless solution for large-scale parallel on-demand processing of a semistructured dataset. The data consists of logs, media files, sales transactions, and IoT sensor data that is stored in Amazon S3. The company wants the solution to process thousands of items in the dataset in parallel. Which solution will meet these requirements with the MOST operational efficiency?
- AUse the AWS Step Functions Map state in Inline mode to process the data in parallel.
- BUse the AWS Step Functions Map state in Distributed mode to process the data in parallel.
- CUse AWS Glue to process the data in parallel.
- DUse several AWS Lambda functions to process the data in parallel.
Show answer
Correct answer: B
The Step Functions Map state in Distributed mode runs thousands of child workflows in parallel, reading data straight from S3. Inline mode supports far less parallelism.
Frequently asked questions
What is the difference between Standard and Express workflows?
Standard workflows can run for up to a year, execute each step exactly once and keep a detailed history, which suits long processes such as approvals. Express workflows run for up to 5 minutes with very high throughput and are billed by executions and duration, which suits high-volume event processing.
How is Step Functions priced?
Standard workflows are billed per state transition. Express workflows are billed by executions, duration and memory. For workflows with many small repeated steps, consider Express.
What do AWS exams ask about Step Functions?
Orchestrating multiple Lambdas and AWS services, retry and catch for error handling, waiting for human approval (callbacks), choosing Standard or Express, and calling AWS services directly without an intermediate Lambda.