Stackbook Logo
architecture-descriptionestablished · low operational burden

AWS Step Functions (Serverless Workflows)

Also known as: step-functions, serverless-workflow, state-machine, aws-workflow

Intent

Orchestrate serverless workflows as state machines with built-in retries, error handling, parallel execution, and visual debugging — no servers to manage.

Problem

Coordinating Lambda functions, ECS tasks, API calls, and human approvals requires reliable orchestration with retries, error handling, and visibility — without managing servers.

Forces

  • Serverless functions (Lambda) need coordination
  • Long-running processes (hours to months)
  • Error handling, retries, timeouts must be declarative
  • Visual debugging and monitoring required
  • No servers to manage (fully managed)

Solution

✓ When to Use

  • Serverless orchestration (Lambda, ECS, API calls)
  • Long-running processes with retries, human approval
  • Visual debugging and audit trail required
  • Team wants fully managed (no cluster ops)

✗ When Not to Use

  • Complex logic better in code (Temporal better)
  • Sub-second latency (Express: 5min max)
  • Team not in AWS (Temporal portable)
  • Cost-sensitive high-volume (Express cheaper)

Pros

  • +Fully managed: no servers, no cluster ops
  • +Declarative retries, catches, timeouts
  • +Visual debugging: see execution graph, history
  • +Integrates with all AWS services
  • +Express: high-throughput, low-cost for short workflows

Cons

  • ASL verbose: JSON/YAML gets large
  • Logic in config: harder to test, review, version
  • Vendor lock-in: AWS only
  • Cost: state transitions add up at scale
  • Debugging: ASL logic errors hard to trace

Cost Profile

Infrastructure

Low — fully managed

Operational

Low — no cluster ops

Cognitive

Medium — ASL, state machine thinking

Failure Modes

  • State machine too large: ASL size limit (1MB)

  • Infinite loop: Choice → Wait → Choice without progress

  • Task token lost: callback never sent → timeout

  • Express at-least-once: duplicate executions

  • History limit: 25k events max per execution

Real-World Examples

Alternatives

  • temporal
  • camunda
  • custom-state-machine
  • eventbridge
  • event-driven

Related Patterns

  • saga-patterns
  • temporal-workflows
  • event-driven-architecture
  • serverless
  • human-in-the-loop
  • compensating-transaction

Competency Domains

distribution communicationreliability opsdeploymenteconomics evolutiondata consistency