Durable Workflow Orchestration
Temporal vs AWS Step Functions pricing: how do costs compare at high volume (millions of steps) and long retention?
9 min read
When you’re pushing millions of steps and need long retention, the “sticker price” of AWS Step Functions is only half the story. You also pay in ways the bill doesn’t show: more Lambda invocations, more glue code, more operational drag. Temporal flips that model. You pay for durable execution capacity (Actions in Temporal Cloud or infra if self‑hosting), but you don’t pay per little state transition—and you eliminate most of the retry, timeout, and recovery code you’d otherwise ship.
Quick Answer: At high volume and long retention, AWS Step Functions’ per‑state and history charges compound quickly. Temporal (especially Temporal Cloud) tends to be more cost‑efficient and predictable for large, long‑running workflows because pricing tracks durable execution capacity, not every micro‑step or month of history—while also replacing a lot of custom reliability infrastructure.
Frequently Asked Questions
How do Temporal and AWS Step Functions charge for “steps” at high volume?
Short Answer: AWS Step Functions charges primarily per state transition (and often extra via Lambda, API calls, and CloudWatch), while Temporal charges for overall execution capacity (Actions) and storage, not for each step in a Workflow. At millions of steps, Temporal’s cost curve is flatter and easier to predict.
Expanded Explanation:
AWS Step Functions’ pricing is fundamentally “event meter” driven. Every state transition is a billable event. For workflows that fan out, retry, or have many small states, that can multiply fast. Add in Lambda charges, VPC costs, and CloudWatch logs, and your effective per‑workflow cost becomes hard to forecast as volume grows.
Temporal uses a different model. In Temporal Cloud, you pay for Actions per second (the rate of Workflow/Activity operations) and storage/retention, but you don’t pay per fine‑grained state transition. A Workflow that runs for weeks and performs thousands of steps still looks like “code running under a durable engine,” not thousands of individually billed events. If you self‑host Temporal, your cost is infrastructure (compute + storage) you provision for the Temporal Service and your Workers.
At millions of steps, this difference matters. The cost of a Workflow in Temporal is dominated by how much actual work it performs and how much history you choose to retain, not by how many tiny state transitions a DSL decomposes it into.
Key Takeaways:
- Step Functions pricing scales with every state transition and associated AWS services; the more steps and retries, the higher the bill.
- Temporal pricing aligns with durable execution capacity and storage, making heavy, long‑running workflows more cost‑predictable at scale.
How should I think about costs when I’m running millions of workflow steps?
Short Answer: With Step Functions, model your cost as (states × price_per_state) + Lambda + logs; with Temporal, think in terms of (Actions per second + storage) or infra cost if self‑hosting. At multi‑million step scale, Execution volume and retention drive Step Functions’ bill; sustained throughput and storage drive Temporal’s.
Expanded Explanation:
Consider a system that orchestrates millions of operations per day—payment flows, order fulfillment, AI pipelines, CI/CD rollouts. In Step Functions, every map iteration, choice, retry, and callback is a state transition. A “simple” workflow written as code might turn into dozens of states in a Step Functions definition. At high volume, this multiplier dominates your cost.
With Temporal, that same logic lives directly in your application code as a Workflow. The engine records a compact event history and replays it deterministically to recover from crashes. Temporal Cloud bills you based on how many Actions/second you use (think: operations on Workflows and Activities) and how much you store. You can run Workflows for days or weeks; the fact that they’re long‑lived doesn’t explode the bill step by step.
Steps:
- Estimate state count in Step Functions.
Count average states per execution (including retries, map fan‑outs, and error paths), then multiply by executions and per‑state price. - Estimate lambda/API/log overhead.
Add Lambda duration costs, downstream AWS service usage, and CloudWatch logs driven by Step Functions. - Estimate Temporal capacity.
For Temporal Cloud, estimate peak Actions/second and history size based on Workflow volume and retention. For self‑hosting, estimate node and database requirements for your target throughput.
How do Temporal and Step Functions compare on long‑term history and retention costs?
Short Answer: Step Functions was not designed as a long‑term execution ledger; history is limited and not cheap to keep at scale. Temporal is explicitly built around long‑lived Workflow histories, so retaining months or years of detailed event history is normal and more cost‑efficient.
Expanded Explanation:
Step Functions gives you execution history, but it’s not meant to be your primary, durable system of record for multi‑month or multi‑year processes. Retention is limited by service constraints, and you usually end up exporting logs or events into S3, DynamoDB, or another system—each with its own storage, query, and maintenance cost. The result is a fragmented story: some state in Step Functions, some in Lambda logs, some in your data stores. You pay for all of it, and debugging still requires stitching things together.
Temporal treats Workflow history as the core primitive. Every state transition is recorded as an event in an append‑only history. This is how Temporal replays, recovers, and “rewinds” Workflows. Retention is configurable. You can keep histories for as long as you need, and Temporal Cloud is optimized for this pattern—high scale, long‑lived histories, and disaster‑resilient storage, without you building the storage layer.
From a cost perspective, that means you’re not paying Step Functions + S3 + custom export logic to keep a full audit trail. You’re paying for one durable execution platform that already thinks in terms of histories and retention.
Comparison Snapshot:
- Option A: AWS Step Functions
Shorter‑lived execution histories; long retention often means exporting to S3/DynamoDB, adding more services and costs. - Option B: Temporal / Temporal Cloud
Long‑lived, first‑class Workflow histories, configurable retention, and direct replay/debugging with no extra systems. - Best for:
High‑volume, long‑running workflows that require detailed, durable execution history (auditing, debugging, compliance).
What does implementation effort have to do with effective cost at scale?
Short Answer: Step Functions shifts cost into orchestration DSLs, glue services, and operational complexity; Temporal moves that complexity into a durable runtime so you implement Workflows as normal code. At scale, less orchestration code and fewer moving parts usually means lower total cost of ownership.
Expanded Explanation:
Cost isn’t just the AWS line item. It’s how many engineers you need to design state machines, maintain runbooks, wire retries, and debug production incidents across services. With Step Functions, you design JSON/YAML state machines, wire them to Lambda or ECS, then write custom logic for idempotency, retries, compensations, and timeouts. As workflows grow, so do the DAGs, the error handling branches, and the tests. You pay for that complexity every sprint.
Temporal’s model is different. You write Workflows and Activities as normal code in Go, Java, TypeScript, Python, or .NET. The Temporal Service handles durable state, retries, timers, and signals. Crash mid‑workflow? The engine replays from the last event and your code picks up exactly where it left off. That’s work you don’t have to do.
Temporal Cloud adds another dimension: no infra management. You get high availability, built‑in replication and disaster recovery, and automatic scaling to hundreds of thousands of Actions per second, without provisioning databases or tuning clusters. Either way, Temporal never runs your code; Workers run in your environment and only talk out to Temporal. You don’t open your firewall inbound.
What You Need:
- With Step Functions:
State machine design skills, Lambda/service glue, export pipelines for long‑term history, and operational practices around partial failures and timeouts. - With Temporal:
Application developers writing Workflows and Activities as code, plus either Temporal Cloud (no infra) or a self‑hosted Temporal cluster and database if you want full control.
Strategically, when does Temporal become more cost‑effective than AWS Step Functions?
Short Answer: As your workflows become more stateful, long‑running, and high volume, Temporal usually becomes more cost‑effective—both in direct spend and in engineering time—because it gives you durable execution as a primitive instead of billing you per step and forcing you to rebuild reliability on top.
Expanded Explanation:
For very simple, low‑volume orchestrations, Step Functions can be fine. You get a managed service, pay per state, and move on. But as soon as you’re orchestrating real business processes—moving money, order fulfillment, CI/CD rollouts with rollbacks, AI/ML pipelines, human‑in‑the‑loop flows—the hidden costs show up:
- State machine sprawl across accounts and regions.
- Custom retry/compensation logic in every Lambda.
- Ad‑hoc exports just to keep a usable audit trail.
- Incident response that depends on logs, not a first‑class execution history.
Temporal is designed precisely for this class of problem. Workflows can run for days, weeks, or months. They survive crashes, timeouts, flaky networks, and partial outages without losing progress. Temporal Cloud gives you this at scale—up to 300k+ Actions per second—with consumption‑based pricing so you’re not paying for idle capacity or over‑provisioned databases.
Strategically, organizations adopt Temporal when they realize reliability work is dominating their roadmap. They want to stop building bespoke workflow engines and error‑handling frameworks and instead standardize on one durable execution platform across teams. That consolidation is where the cost advantage really compounds.
Why It Matters:
- Impact 1: You trade per‑step billing and orchestration DSL complexity for a durable execution engine and code‑first Workflows. Fewer moving parts, fewer custom state machines, fewer incidents.
- Impact 2: You gain full visibility—via Temporal’s Web UI—into every Workflow, with the ability to inspect, replay, and rewind. That cuts mean time to recovery and reduces the human cost of operating high‑volume systems.
Quick Recap
At low volume and short retention, Step Functions’ per‑state pricing can look simple. As you scale to millions of steps and months of history, that model becomes expensive and hard to reason about. Every state, every retry, every piece of glue code adds to your bill and to your operational burden.
Temporal takes the opposite stance. You write your workflow logic as normal code. The Temporal Service provides durable execution, history, replay, retries, timeouts, and visibility. Temporal Cloud layers on high availability, disaster recovery, and automatic scaling to hundreds of thousands of Actions per second, with consumption‑based costs instead of oversized infra. For large, long‑running workflows, that usually translates into lower, more predictable spend—and a lot less time building and debugging homegrown reliability.