What is AWS Step Functions in simple terms?

AWS Step Functions is a serverless service that coordinates several steps of a process as a single workflow. Instead of coding into your application the order in which each component is called, what happens if one fails and how many times to retry, you define that flow as a state machine and Step Functions runs it, retries what fails and keeps a record of every step. It is the conductor of a process that involves several services.

What is the difference between Standard and Express workflows?

A Standard workflow can run for up to one year and follows an exactly-once execution model, which makes it suitable for long processes or ones that cannot be repeated without consequences, such as a payment or starting a cluster. An Express workflow runs for up to five minutes and follows an at-least-once model, meaning an execution could run more than once; it fits high-volume event processing where repeating a step is harmless. The choice depends on how long the process runs and whether repeating a step is safe.

Does Step Functions replace AWS Lambda?

No, they complement each other. Lambda runs the logic of each step; Step Functions decides the order of those steps, handles errors and keeps the state of the process between them. Without an orchestrator, that coordination logic ends up hand-coded inside the functions, which is exactly what makes a serverless architecture fragile as it grows.

When is Step Functions a better fit than a queue or an event bus?

It fits when you need to coordinate a stateful sequence: steps that happen in a certain order, conditions, parallel branches, waits and a clear view of where each execution stands. A queue or an event bus is ideal for decoupling components and moving messages between them, but neither keeps track of the overall process. In practice they coexist: the bus routes the event that triggers the workflow and Step Functions coordinates what comes next.

Is it useful for orchestrating AI processes?

Yes, and it is one of its fastest-growing uses. An AI process is rarely a single call: it usually chains data retrieval, a model invocation, validation of the result and an action on a business system, with retries and human approval steps. Step Functions coordinates that sequence and leaves traceability for every step, which matters when the process must be auditable.

What is AWS Step Functions?

AWS Step Functions is a serverless orchestration service: it coordinates several AWS services and several pieces of your own application as a single workflow, with a defined order, built-in error handling and a record of every step. In Step Functions a workflow is modeled as a state machine, and each step of that workflow is called a state.

In business terms: if your processes today are a chain of calls between components that someone hand-coded — and nobody dares to touch — Step Functions turns that chain into an explicit, visible workflow with automatic retries.

What problem does it solve?

As an application grows, the logic that coordinates the steps starts spreading everywhere: a Lambda function calling another one, a retry hand-coded here, an if deciding whether to continue there, the process state stored in a table because there was nowhere else to put it. The result is familiar:

Nobody knows which step a process is on when something fails midway.
Retry logic is rewritten in every component, with different criteria each time.
Changing the order of the steps means touching code across several services at once.
There is no traceability: reconstructing what happened in a specific execution requires cross-checking logs from several sources.

Step Functions moves that coordination logic out of the code and turns it into an explicit definition of the workflow. Order, conditions, retries and error handling stop being scattered and live in a single place.

How it works

A Step Functions workflow is defined in Amazon States Language, a JSON-based format that describes the states and how the flow moves from one to the next. The most used state types cover almost any business process:

Task: the actual unit of work. It invokes a Lambda function, calls another AWS service or even an external HTTPS API.
Choice: a branch. Depending on the incoming data, the workflow takes one path or another.
Parallel: runs several branches at the same time and waits for all of them to finish.
Map: repeats the same steps over each element of a list, for example each file in a batch or each item in an order.
Wait: pauses the workflow for a set time or until a date, without consuming compute while it waits.

Integration with the rest of AWS is direct: through AWS SDK integrations, a workflow can call thousands of API actions across AWS services without you writing an intermediate function just for that.

Retries and errors, built in

This is the part that saves the most code in practice. Step Functions provides two native mechanisms:

Retry: defines a retry policy when a step fails, with the number of attempts and the interval between them.
Catch: defines an alternative path when the error persists — notify, compensate the operation, log the case for review — instead of leaving the process hanging.

Writing that same logic by hand inside each function is possible, but it rarely stays consistent across components and is almost never documented.

Orchestration and choreography are not the same

This is the most common confusion when designing event-driven architectures, and it is worth separating clearly.

In choreography, each component reacts to the events it cares about without anyone directing the whole: a queue or an event bus moves the messages and each service decides what to do with its own. That is the territory of SQS, SNS and EventBridge, which we compare in detail in SQS vs SNS vs EventBridge.

In orchestration, one piece keeps track of the overall process: it knows the order of the steps, the state of the execution and what to do if something fails. That is the role of Step Functions.

They do not compete: they combine. The usual pattern is that an event arrives through a bus, triggers a Step Functions workflow, and that workflow coordinates the steps that follow. The practical rule: if you need to move messages between decoupled components, think messaging; if you need to keep track of a stateful process, think orchestration.

Standard and Express: which to choose

Step Functions offers two workflow types, and the choice is made per process, not for the whole architecture.

Criterion	Standard	Express
Maximum duration	Up to 1 year	Up to 5 minutes
Execution model	Exactly-once	At-least-once
A step repeats	Only if you define retries	Yes, by the delivery model
Fits with	Long, non-repeatable processes	High-volume event processing
Typical example	A payment, starting a cluster	Transforming input data in bulk

The question that settles the choice is simple: is repeating a step of this process harmless? If it is — transforming a value and storing it, for example — Express fits and is efficient at high volume. If it is not — charging twice is not an option — the exactly-once model of Standard is the right one.

Where it adds the most value

Data and ETL processes. Coordinating extraction, transformation and loading with retries per stage and visibility into where each run stopped. It is the natural complement of an ETL pipeline.
Microservices orchestration. When a business operation spans several microservices, the workflow keeps the state and avoids each service having to know who comes next.
Processes with human approval. A wait state lets you pause the workflow until a person approves, without keeping anything running in the meantime.
AI workflows. Chaining context retrieval, model invocation, validation and an action on a business system, with traceability for every step. It is the foundation for taking AI agents into a production-grade, auditable environment.

How we work with it at Caleidos

At Caleidos, as an AWS Advanced Tier Services Partner, we use Step Functions when a process stops being an isolated call and becomes a business workflow with several steps, conditions and points of failure. It is part of our Cloud Native Apps practice: we move the coordination logic out of the code, turn it into an explicit workflow with retries and traceability, and instrument it with observability from the start so the team can see where each execution stands. If you are just entering the model, we cover the basics in what serverless is, and the logic of each step usually lives in AWS Lambda.

Do you have critical processes coordinated by hand across several services?

Let’s talk about your architecture: we review your current workflows and tell you where an orchestrator reduces operational risk and where it is not needed.

What is AWS Step Functions? Serverless workflow orchestration