A document processing pipeline runs as an AWS Step Functions Standard workflow (serverless workflow orchestrator — Standard tier bills per state transition, not per execution or per second). Seven top-level states: receive document, validate format, extract text, run classification, store result, notify downstream, update audit log. The extract-text state is a Map state (fans out over an array — each item runs its own sub-workflow, and every state inside every iteration is billed as a transition) that processes the document page by page. Documents average 9 pages, and each page runs a 7-state pipeline: render, OCR, confidence check, a retry choice, redaction, store page, emit metrics.
Average execution takes 4–6 seconds end to end.
When the pipeline processed 80,000 documents per month, the Step Functions bill was $140. The platform grew. Last month it processed 2.2 million documents. The bill was $3,850.
Nothing changed in the workflow. No new states were added. The team is deciding whether to optimize or migrate.
What is the correct explanation, and what is the right fix?
A) Step Functions Standard pricing is per execution at a flat rate — 2.2M executions scaled the cost linearly and only reducing volume can reduce it; but Standard Workflows are not priced per execution — the billable unit is the state transition, and a single execution can contain a few transitions or hundreds
B) Standard bills every state transition, and the Map state multiplies them — 7 top-level states plus 9 pages × 7 states per page is roughly 70 transitions per document; at 2.2M documents that is ~154M transitions, and at $0.025 per 1,000 transitions, $3,850; the bill scales with documents × pages, not documents
C) Step Functions Standard includes a per-second execution charge — longer executions at higher volume caused the spike; but duration billing is the Express Workflow model; a Standard execution that sits in a Wait state for 24 hours costs the same transitions as one finishing in 4 seconds
D) The increase is CloudWatch Logs (AWS monitoring, charges per GB ingested) ingestion from execution history — a real cost at scale, but a 27× bill jump from $140 to $3,850 with unchanged logging configuration cannot come from log ingestion
Answer in the comments.
Top comments (4)
D — Execution-history logging at 2.2M runs adds real CloudWatch Logs cost, and it is worth checking after an Express migration. But with unchanged log configuration, ingestion grows linearly with volume from a small base — it cannot manufacture a 27× jump that lands precisely on the transition math above.
C — Duration billing is Express, not Standard. Standard’s indifference to time is actually its superpower for long-running workflows: a 3-day human-approval Wait costs a handful of transitions. This pipeline has the opposite shape — short and hop-heavy — which is exactly the shape Standard punishes and Express rewards.
A — There is no flat per-execution rate on Standard. Two workflows with identical execution counts can differ 50× in cost purely on state count and Map fan-out — which also means cost is designable, not just a function of volume.
The answer is B.
Standard Workflows (serverless workflow orchestrator — bills per state transition) charge $0.025 per 1,000 state transitions — $25 per million. The unit is not the execution. It is every hop the execution makes, and a Map state (runs a sub-workflow per array item) turns one document into a multiplier.
Run the math for one document: 7 top-level transitions, plus the Map fan-out — 9 pages × 7 states per page = 63 — roughly 70 transitions per document.
At 80,000 documents: 5.6M transitions × $25/M = $140. That was the old bill.
At 2.2M documents: 154M transitions × $25/M = $3,850. That is the new bill, to the dollar.
Nobody added a state; the workload’s pages grew with its documents. That is the trap: with Map states, your Step Functions bill scales with documents × pages, and the per-page pipeline that felt clean in the designer — a state per small operation — is a per-page tax at $25 per million hops.
Two fixes, and they compound:
Fix 1 — Migrate to Express Workflows (bills per request and per GB-second of duration, like Lambda — transitions are free). This workflow qualifies cleanly: it runs 4–6 seconds (Express caps at 5 minutes), and it uses no callbacks or wait-for-task-token patterns. At 2.2M short executions, Express typically lands over 90% cheaper than this Standard bill. Know what you trade: Express is at-least-once execution, where Standard is exactly-once — so the side effects (store, notify, audit) need idempotency keys. Regular readers will recognize the rule: at-least-once is the price of most things cheap and scalable, and idempotency is how you pay it once. Express also keeps history in CloudWatch Logs (AWS monitoring, charges per GB ingested) rather than a 90-day execution console — set log levels deliberately or Fix D’s cost becomes real.
Fix 2 — Coarsen the per-page pipeline. Seven orchestrated states per page means the orchestrator supervises render, OCR, confidence, redaction as separate hops. Collapse them into one Lambda task per page — or one per document — and orchestrate at the granularity of side effects and retry boundaries, not lines of code. A state transition is an orchestration cost; spend it where a failure needs independent retry or compensation, nowhere else. (Day 9’s durable-functions lesson was the same law wearing different clothes: checkpoint per side effect, not per thought.)