AWS Step Functions offers two workflow types — Standard and Express — with pricing models different enough that choosing the wrong one for a given workload can produce a cost difference of an order of magnitude or more. We see this most often in high-volume, short-duration workflows (per-request API orchestration, real-time data transformation steps) built on Standard workflows by default, simply because Standard was the original workflow type and remains the default choice in a lot of tutorials and starter templates.
How the Two Pricing Models Actually Differ
Standard Workflows are priced per state transition — each step in the workflow that executes incurs a charge, regardless of how long the workflow runs. This model is well-suited to long-running, low-volume workflows (order fulfillment processes, human-approval steps that might wait hours or days) where the total transition count stays modest even though the workflow spans a long duration.
Express Workflows are priced by number of requests and workflow duration (billed per GB-second of execution, similar to Lambda's pricing model), with no per-state-transition charge. This model is dramatically cheaper for high-volume, short-duration workflows — the kind that fire thousands or millions of times per day but complete in seconds.
Where the Cost Blowout Happens
A workflow with, say, 8 steps that fires 500,000 times a day, built as a Standard workflow, generates 4 million state transitions daily — and Standard's per-transition pricing means that volume adds up fast. The same workflow as an Express workflow is priced by duration and request count instead, typically costing a small fraction of the Standard equivalent for this specific volume/duration profile.
// Express workflow definition - same logic, different billing model
{
"Comment": "High-volume request processing - Express workflow",
"StartAt": "ValidateRequest",
"States": {
"ValidateRequest": {
"Type": "Task",
"Resource": "arn:aws:lambda:us-east-1:123456789012:function:validate",
"Next": "ProcessRequest"
},
"ProcessRequest": {
"Type": "Task",
"Resource": "arn:aws:lambda:us-east-1:123456789012:function:process",
"End": true
}
}
}
The state machine definition itself doesn't change meaningfully between workflow types — the type is set at creation and determines the billing model and some operational characteristics.
What You Give Up With Express
Express workflows aren't a strictly better choice — they trade away some capabilities that Standard workflows provide: Express workflows have a maximum duration of 5 minutes (Standard supports up to a year), and Express execution history isn't retained in the same detailed, queryable way Standard's is — Express relies on CloudWatch Logs for execution history rather than the Step Functions console's built-in execution history view. For workflows needing long-running human-approval steps, extended retry/wait patterns, or detailed native execution history for debugging, Standard remains the right choice regardless of cost.
The Decision Framework
- Volume: high request volume (thousands+ per day) favors Express's per-request/duration pricing.
- Duration: workflows completing well under 5 minutes are eligible for Express; anything longer requires Standard.
- Audit/debugging needs: workflows needing detailed native execution history for compliance or debugging favor Standard, or Express with a well-built CloudWatch Logs-based audit pipeline as a substitute.
- Exactly-once vs. at-least-once semantics: Standard guarantees exactly-once execution; Express provides at-least-once, which matters for idempotency design in the downstream tasks.
Auditing Existing Workflows for the Wrong Choice
The most direct audit signal is state transition count relative to workflow duration in AWS Cost Explorer, filtered to Step Functions — a high-transition-count, short-duration workflow running as Standard is the pattern worth investigating first, since it's usually both the easiest fix and the largest single line-item savings opportunity in a Step Functions cost review.
This workflow-type decision is part of our AWS cloud infrastructure capability, alongside the broader approach in serverless cost optimization on AWS.
Talk to us about your AWS cost audit: 907-841-8407 or contact@rutagon.com.
Talk to us about your AWS cost audit →
Frequently Asked Questions
Can we switch an existing Standard workflow to Express without rebuilding it?
The state machine definition (ASL) is largely portable, but the workflow type is set at creation, so switching requires creating a new state machine of the Express type and cutting traffic over — not an in-place conversion.
Does Express workflow's at-least-once execution guarantee cause problems?
It can, if downstream tasks aren't idempotent — a task might execute more than once for a single logical workflow run, so Express workflows generally require idempotent task design, which is worth confirming before migrating a workload built assuming exactly-once semantics.
How do we see execution history for Express workflows if it's not in the console the same way?
Express workflow execution details are sent to CloudWatch Logs (when logging is enabled on the state machine), so building a CloudWatch Logs Insights query or dashboard is the practical substitute for the native Standard execution history view.
Is there a rule of thumb for the volume threshold where Express becomes cheaper?
It depends on your specific step count and per-transition pricing versus duration/request pricing, but as a general pattern, workflows firing more than a few thousand times daily with short execution times are worth modeling against both pricing structures directly.
Does Express support the same range of state types as Standard?
Mostly yes, though there are some feature differences (like maximum execution duration and certain wait patterns) — check the current AWS documentation for the specific state types your workflow uses before committing to a migration.