When Step Functions is the right boundary for serverless work

Step Functions is useful when a process has meaningful state that should survive an individual Lambda invocation. Approval steps, long waits, compensating actions, and multi-service retries are often easier to review in a workflow than in nested code callbacks.

Model the business state explicitly

The workflow should represent states an operator can explain: submitted, validated, awaiting approval, processing, completed, or compensated. Keep application-specific decisions in handlers, but let the workflow own sequencing, timeout, retry, and terminal failure behavior.

Do not introduce a workflow for every request. A small synchronous operation can remain simple. The boundary becomes valuable when visibility, durability, and recovery would otherwise be recreated inconsistently in application code.

The best test is operational: can a teammate see where an instance is, why it stopped, and what action is safe next?