AWS Step Functions: Workflow Orchestration

Step Functions makes workflow control flow explicit

AWS Step Functions models workflows as state machines defined with Amazon States Language (ASL). Rather than embedding every transition, retry, and branch inside application code, a state machine represents steps and their transitions declaratively. Task states perform work through Lambda, AWS service integrations, activities, or supported HTTP integrations, while states such as Choice, Wait, Parallel, Map, Succeed, and Fail express control flow.

This makes Step Functions an orchestration service: it knows the workflow's intended sequence and decides which step comes next. That differs from event choreography, where components react to events without one central workflow owning the complete path. Orchestration is particularly useful for multi-step business processes whose branching, retries, and execution history must be understandable as one unit.

Standard and Express workflows expose different execution semantics

Standard Workflows are designed for durable, auditable executions and follow an exactly-once workflow execution model unless Retry behavior causes a task to run again. Their execution history and long-running nature fit business processes where each transition should be traceable. Express Workflows target high-event-rate, short-duration workloads: asynchronous Express executions use an at-least-once model, while synchronous Express executions use an at-most-once model.

The choice should therefore follow semantics and workload shape rather than assuming Express is merely a faster Standard workflow. Non-idempotent actions are typically safer under Standard's execution model, while high-volume idempotent event processing can fit Express. Supported integration patterns also differ, so workflows that depend on callback task tokens or job-run synchronization must use a workflow type that supports those patterns.

• Task: invoke work through a supported integration.
• Choice: branch according to input/state data.
• Parallel: run independent branches concurrently and wait for their completion.
• Map: apply a workflow to items, with Inline and Distributed processing modes.
• Wait: pause until a relative or absolute time condition.

Retry, Catch, and timeouts define failure semantics

When a supported state fails, a Retry rule can match error names and schedule another attempt. IntervalSeconds sets the initial delay, BackoffRate grows subsequent delays, and MaxAttempts limits retry attempts. After matching retriers are exhausted or no retrier matches, Catch rules can route the error to a recovery state. Retriers are evaluated before catchers, which matters when predicting the actual failure path.

Timeouts should be explicit for work that could otherwise wait indefinitely. Task and activity states support timeout-related fields according to their integration model, and heartbeat settings can detect workers that stop reporting progress. Retry does not make a side effect safe: every retried task that may partially succeed should be designed for idempotency or use a service-specific idempotency mechanism.