AWS Step Functions & EventBridge Support
Step Functions Standard vs Express workflows.
Standard and Express workflows run the same state machine language but behave differently: how long they can run, how many times a step may execute, how history is kept and how you are billed. Choosing wrongly gives surprise costs or duplicate side effects. We match the type to the job.
When You Need This
The situations where this work pays for itself.
Signs it is time
- Step Functions cost is much higher than expected for a high-volume flow
- You process thousands of short events per second
- A workflow waits for humans, callbacks or long timers
- You see duplicate effects from an Express workflow
- You need to inspect each execution's history in the console
What you get
- A recommendation per workflow with the evidence
- A cost model using your volume
- Converted or nested state machine definitions
- Logging and alarm setup for the chosen type
How we do it
A clear, safe process you can follow along with.
1. Describe the workload
We record expected execution count, duration, step count, payload size and whether any step waits for a callback, a human or a long timer.
2. Apply the hard limits
Standard workflows can run up to one year and support callbacks and activities well. Express workflows are limited to a short maximum duration, currently five minutes, so long waits rule them out.
3. Check execution semantics
Standard guarantees each state runs exactly once for the workflow's normal path. Asynchronous Express workflows run at least once, so tasks must be idempotent. Synchronous Express runs at most once and returns the result to the caller.
4. Compare cost with real numbers
Standard is billed per state transition, Express by requests and duration and memory. We model your volume against the current price list, since which is cheaper depends on step count and run time.
5. Plan observability
Standard keeps execution history in the service. Express sends logs to CloudWatch Logs, which must be enabled and sized, and can themselves be expensive at volume. We choose logging level deliberately.
6. Convert or split and test
The type cannot be changed in place, so we create a new state machine, or nest Express inside Standard for a high-volume inner loop, run side-by-side tests and cut over.
Mistakes we help you avoid
Common ways this goes wrong, and what we do instead.
Using Express for non-idempotent work
At-least-once execution can repeat side effects such as payments or emails.
Using Standard for tiny high-volume events
Per-transition billing adds up quickly at millions of runs.
Turning on full Express logging in production
Logging every payload can cost more than the workflow.
Expecting to switch type later
The type is set at creation, so plan the migration.
Frequently Asked Questions
Can a Standard workflow call an Express workflow?
Yes. A common pattern is a Standard parent that waits or orchestrates and Express children that handle short high-volume work.
Which is cheaper, Standard or Express?
Express is usually cheaper for high-volume short runs, Standard for lower volume or long runs. We calculate with your actual volume rather than rules of thumb.
How do I debug Express executions?
Enable logging to CloudWatch Logs and use X-Ray if you need traces. Console history for Express is not stored the way Standard history is.
Want Help With Step Functions Standard vs Express workflows?
Schedule an appointment. Tell us about your environment and we will outline the safest, highest-value approach.
Schedule Appointment › No commitment required