Step Functions vs SQS Chains: Choosing a Workflow Orchestration Model

When building backend processing that runs through several steps — order fulfillment is the classic case — the structural options come down to two: Step Functions conducting the whole flow, or each step handing off to the next through SQS queues. The conclusion up front: business flows with branching, retries, and compensation, and anything whose progress must be visible at a glance, go to Step Functions; simple one-or-two-step async work and high-volume event consumption go to SQS plus Lambda. The price gap runs to tens of x, which makes this look like a money question, but the real decider is who owns failure handling. Choosing among the messaging services themselves is covered in SQS vs SNS vs EventBridge. Prices are for us-east-1.

Side-by-side comparison #

The structural split: is there a conductor? #

Step Functions is orchestration. The flow definition lives in one place — the state machine — and that definition decides each step’s success, failure, retry, and branch. Every execution records how far it got and where it failed, visible in the console. Retry policies and catch clauses are declared, not coded, which pulls failure handling out of business logic.

An SQS-and-Lambda chain is choreography. Nothing knows the whole flow; each step finishes its work and drops a message on the next queue. The moving parts are just queues and functions, which keeps it simple and cheap, but the flow as a concept exists nowhere in the system. Answering “where is this order right now?” requires correlation-ID logging and tracing you build yourself, and compensation logic for a step-three failure ends up scattered across consumers.

With two steps or fewer and failure handling that amounts to “park it in a DLQ and reprocess,” choreography’s simplicity wins. As steps multiply, branches appear, and partial failures need rolling back (the saga pattern), the scattered flow turns into maintenance cost. A working rule: more than three queue-separated steps is the signal to move to a state machine.

Pricing: what the tens-of-x gap really means #

Standard workflows bill per state transition, about $25 per million. A 5-state workflow run a million times a month is 5 million transitions, about $125. The same processing as an SQS chain bills a few dollars for some millions of queue requests. This gap is why high-rate processing on Standard makes bills noticeably grow.

Express workflows fill the middle. At about $1 per million executions plus duration and memory, a short high-rate pipeline costs only a fraction of Standard: the example above comes to a few dollars including execution time. The price is its constraints — 5-minute cap, at-least-once semantics (idempotency required), and history through CloudWatch Logs rather than Standard’s per-step console view.

So the pricing axis has three slots: low-rate business flows with human waits or long runs go Standard; high-rate automated pipelines under 5 minutes go Express; processing that needs no orchestration at all goes SQS. When a Standard bill hurts, the first move to evaluate is Express, not an SQS rewrite.

Combination: not a rivalry #

Real architectures usually combine the two.

• SQS at the entrance, Step Functions for processing: the queue levels inbound spikes, and a consumer starts a state machine execution per message — queue buffering plus state machine visibility.
• SQS calls inside the state machine: Step Functions sends to SQS as a direct integration, no Lambda needed, for steps that hand work to other systems. With a callback token (waitForTaskToken), a step can send a message and wait until the external processing reports back.
• Main line on the state machine, side work on queues: the order-confirmation main line runs under Step Functions while side effects that must not block it — notifications, say — flow through queues. The split lowers both cost and complexity.

Decision order #

1. Count the steps and branches: two or fewer in a straight line means SQS plus Lambda is enough. Three or more, or any branching, parallelism, or compensation, makes Step Functions the candidate.
2. Write down the failure scenarios: if either “we must trace how far it got” or “partial failures must be rolled back” is true, orchestrate. If DLQ reprocessing suffices, chain queues.
3. Split Standard vs Express on duration and rate: over 5 minutes or human waits means Standard; short and high-rate means Express, checking idempotency at the same time.
4. Sanity-check the bill in transitions: steps × monthly executions × $0.000025 is the Standard bill. High-rate on Standard means Express is the first saving to take.
5. Put a queue in front when leveling is needed: spike absorption is queue work, flow conduction is state machine work. Splitting the roles keeps both small.

Summary #

• The decider is failure ownership, not price. Retries, branching, compensation, and tracing point to Step Functions; DLQ-grade simple async points to SQS plus Lambda.
• Standard costs about $25 per million transitions and buys year-long runs, exactly-once semantics, and per-step history — the pricing of low-rate business flows.
• Express at about $1 per million executions runs tens of times cheaper than Standard. Short, high-rate pipelines belong on Express, not Standard.
• More than three queue-separated steps is where choreography’s simplicity flips into maintenance cost.
• The practical answer is combination: level with queues, conduct with the state machine, and separate the main line from side work.