What's changed: In-scope service coverage (axis B): added Kinesis Data Streams streaming definition, role, and selection vs SQS/SNS/Firehose to s2 (EventBridge).
2.3Orchestrating Workflows with Step Functions
Understand workflow design with AWS Step Functions state machines: orchestrating multiple steps (sequence, choice, parallel), retries/error handling, and integrating Lambda and other services.
When you need to control multiple steps with sequence, branching, parallelism, and retries, use AWS Step Functions—a state machine you can visualize and manage.
2.3.1State machines
- State machine: connects states in sequence, Choice, Parallel, Wait, and Map.
- Retry/Catch: declaratively define retries and error handling (fallbacks) on failure.
- Service integrations: invoke 200+ services (Lambda/SQS/SNS/DynamoDB) without glue code.
- Standard vs Express: Standard = long-running, auditable, up to 1 year; Express = high-volume, short-duration.
When you must reliably run multiple steps with sequence, branching, parallelism, waits, and retries, baking that control into each Lambda gets complex and fragile. Step Functions defines the flow declaratively as a state machine you can visualize and monitor, with Retry/Catch (fallback), Choice, Parallel, and Map, invoking 200+ AWS services without glue code. The rule: a single simple async step → a lone Lambda; multi-step state transitions, error control, long flows → Step Functions. Choose Standard (auditable, long-running) or Express (high-volume, short-duration).
| Requirement | Choice |
|---|---|
| Single simple async step | A lone Lambda |
| Multi-step, branching, retries | Step Functions |
| Long-running, auditable | Standard workflow |
| High-volume, short-duration | Express workflow |
Scenario: an order workflow. Define "check inventory → charge → (on success) ship / (on failure) refund and notify" as a Step Functions state machine. Steps are Lambdas, branching is Choice, a charge failure falls back to a refund state via Catch, transient errors use Retry, and progress is visualized. For a single-step notification, Step Functions is overkill—use a lone Lambda.
Watch the mix-ups: (1) Single step = lone Lambda / complex orchestration = Step Functions (avoid over-engineering). (2) Standard (long-running, auditable, up to 1 year) vs Express (high-volume, short). (3) Step Functions does orchestration; event routing is EventBridge—different roles.
Q. When to use Step Functions? To reliably orchestrate multiple steps with branching/parallelism/retries; a single step is fine with a lone Lambda. Q. Standard vs Express? Standard for long-running/auditable (up to 1 year); Express for high-volume, short-duration. Q. vs EventBridge? EventBridge routes events; Step Functions orchestrates workflows.
Common on DVA: orchestrate multi-step with sequence/choice/parallel and retries = Step Functions, single step = lone Lambda, long/auditable = Standard, high-volume short = Express. Orchestration = Step Functions; routing = EventBridge.
2.3.2Section summary
- Step Functions = orchestrate multiple steps via a state machine (Choice/Parallel/Retry/Catch)
- Complex flows = Step Functions; single step = lone Lambda; choose Standard/Express
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. You want to orchestrate multiple steps with sequence, branching, parallelism, and retries. Which service fits best?
Q2. Which state in a Step Functions state machine branches based on a condition?
Q3. When a single async step suffices, which choice avoids over-engineering?