Ask any AWS team how they ended up on Step Functions and you'll get the same answer: it was already there. Already in the console, already on the bill. Nobody had to make a case for it.
The problems don't show up on day one. They show up slowly, a bill that's a little higher than expected a workflow that's a little slower than it should be for what you're building now. By the time someone brings it up in a meeting, half the room's already been thinking it.
The billing model punishes exactly the growth you want
Per-state billing is invisible at low volume. You don't notice it. Then workflow volume climbs into the millions and it stops being invisible, it becomes a number finance asks about. The frustrating part isn't that it's expensive. It's that the pricing model actively gets worse the more successful your usage of the tool becomes, which is backwards from how infrastructure spend is supposed to behave. A flat, fixed-price model doesn't have that problem: cost doesn't move just because volume did.
You're betting on one region staying up
Step Functions is AWS-managed, all the way down. Fine, until a regional outage takes your workflows with it, or until ""we should probably not have all our eggs in one cloud"" moves from a hypothetical someone raised in a planning meeting to an actual mandate from above. Orchestration that runs across AWS, Azure, GCP, or on-prem means a provider having a bad day is an incident, not an outage for your customers too.
The JSON is the job, some days
Step Functions' state machine definitions are genuinely powerful. They're also genuinely tedious to write and debug by hand, and every hour spent wrestling a state machine into shape is an hour not spent on the workflow's actual business logic. A visual builder and YAML definitions don't make the underlying problem simpler, they just get engineers out of the syntax and back into the logic faster.
It wasn't built to feel instant, because it wasn't built for that
This is the one that actually surprises teams. Step Functions is an event-driven tool wearing a request-response costume when you need one, and the seams show:
- Every state transition adds measurable latency. That's a non-issue for a nightly batch job and a real problem for a chat response or an AI agent call that needs to feel immediate.
- There's no native synchronous flow. Getting request-response behavior means wrapping the state machine in API Gateway or a Lambda, which means more infrastructure to babysit, not less.
- CloudWatch tells you what happened. It's genuinely bad at telling you what's happening right now: no live view of step progress or partial outputs while a workflow is actually stuck.
A platform built for real-time, API-driven orchestration from the start doesn't have these seams to paper over: no wait between steps, synchronous and asynchronous flows on equal footing, and tracing you can watch live instead of reconstruct afterward.
None of this means Step Functions is wrong for you
It's a fine choice for AWS-native, event-driven, background-heavy workflows, and plenty of teams should keep using it exactly as-is. The point where it's worth reconsidering is specific: when volume growth starts hurting your bill, when a single-region dependency stops being acceptable, or when a workflow needs to respond in the time it takes someone to read a chat message rather than the time it takes a batch job to run. That's not a tooling preference. That's a different job than the one Step Functions was built to do."
Top comments (0)