What Is AWS Step Functions? The Flowchart That Runs Itself

AWS Step Functions is the flowchart that runs itself: you define the steps, decisions, waits, parallel branches, retries, and service calls in a state machine, then AWS keeps track of each execution and moves it to the correct next step. The counterintuitive part is that Step Functions usually does not perform the business work itself. Lambda, DynamoDB, ECS, Glue, SNS, SQS, Bedrock, an HTTPS API, or another service does the work; Step Functions is the coordinator that remembers what happens next. To try it, open Step Functions in the console, choose Create state machine, and start with a small Standard workflow.

Think about an online order. One component validates the order, another charges the customer, another reserves stock, another creates a shipment, and another sends a confirmation. The difficult part is rarely writing each individual action. The difficult part is deciding what should happen after each result, what to do when something fails, whether two tasks can run together, and how to know where a particular order stopped.

A Step Functions workflow moves that coordination into a visible definition. AWS calls the complete workflow a state machine, each step a state, and each running copy of that workflow an execution. That vocabulary sounds formal at first, but it becomes simple once you picture a real flowchart whose boxes and arrows are executable.

What AWS Step Functions actually is

Step Functions is a managed workflow service for building distributed applications, automating processes, orchestrating microservices, and coordinating data or machine-learning pipelines.

The word orchestration is the key. An orchestra contains many musicians, but somebody has to control timing, order, and coordination. Step Functions plays that coordinating role for application components.

Imagine Jake runs a small phone shop. His website accepts repair bookings. A new repair request might require these actions:

• Validate the customer's request.
• Check whether the model is supported.
• Estimate the repair category.
• Create a booking record.
• Notify the technician.
• Wait for approval if the repair is expensive.
• Send a confirmation to the customer.

Jake could put all of that into one huge Lambda function. He could also split it across several functions and make one function call another. Both approaches can work. The trouble appears when the process itself becomes complicated.

What happens if the notification service returns a temporary error? What happens if the customer selects an unsupported model? What happens if approval takes three hours? What happens if inventory checking and sending a preliminary message can happen at the same time? What happens if the payment task completes but the next task fails?

Those are workflow questions, not merely function questions.

Ethan says it more bluntly: “If one Lambda has become your manager, timer, retry engine, decision tree, and traffic cop for six other pieces of the application, you are making that function own orchestration. That is when I start drawing the process as a state machine instead.”

This distinction matters because you can use Step Functions without making every step a Lambda function. A Task state can integrate directly with supported AWS APIs, and Step Functions can also call HTTPS endpoints. If the only purpose of a Lambda is to make one API call that Step Functions already supports, the extra function may be unnecessary.

Why “the flowchart that runs itself” is a useful description

A normal flowchart is documentation. It tells a human what should happen.

A Step Functions state machine is executable. Its states describe what AWS should do, which route should be selected, when to wait, what should run in parallel, and where execution ends.

Suppose Jake's booking workflow starts with a request containing this:

{
  "repairId": "R-1042",
  "device": "Phone",
  "repairType": "screen",
  "priority": "same-day"
}

A Choice state could inspect repairType or priority and select a route. A Task state could store a repair record. A Parallel state could trigger two independent branches. A Wait state could pause before a follow-up. A Catch path could redirect a failed task into an error-handling branch.

The flowchart is therefore not a picture placed beside the program. It is part of the program.

That makes Step Functions particularly useful when a process is easier to understand as “this happens, then this, unless that happens, while these two other things run, and retry this particular failure.”

If you can explain the process by tracing arrows with your finger, a state machine is often a natural representation.

State machine, state, task, transition, and execution

You only need five terms to understand most beginner Step Functions explanations.

If Jake receives 100 bookings today, he does not need 100 different state machines. He can have one state machine and 100 executions.

Each execution has its own input and can follow its own route. A screen repair could take the normal path. Water damage could go to manual review. An unsupported model could end early. A high-value repair could pause for approval.

The state machine definition describes the possibilities. The execution represents what happened for one particular run.

The workflow definition uses Amazon States Language, usually called ASL. It is JSON-based. Workflow Studio gives you a visual way to build and inspect a state machine, but the workflow has a structured machine-readable definition underneath.

A tiny state machine you can read in one minute

You do not need a complicated Lambda integration to understand how a state machine moves.

{
  "Comment": "Simple repair workflow",
  "StartAt": "ReceiveRepair",
  "States": {
    "ReceiveRepair": {
      "Type": "Pass",
      "Next": "Complete"
    },
    "Complete": {
      "Type": "Succeed"
    }
  }
}

StartAt identifies the first state. Here that state is ReceiveRepair.

The ReceiveRepair state has Next set to Complete. That tells Step Functions which state comes next.

Complete is a Succeed state, so the execution ends successfully.

An important detail: the order in which states are written inside the JSON object does not determine execution order. Fields such as StartAt, Next, branching rules, and terminal states determine the path.

That is a useful thing to understand before looking at a large definition. A state machine is a graph, not a script that simply runs top to bottom because lines appear in that order.

The state types that make the flowchart useful

A workflow becomes interesting when it can do more than move straight from A to B.

Task represents work performed by an integrated service, API, activity, or another supported target.

Choice creates conditional branches. It is the decision diamond from an ordinary flowchart.

Wait pauses the workflow for a duration or until a timestamp.

Parallel runs multiple branches concurrently when those branches can proceed independently.

Map repeats processing for a collection of items. Map can operate in Inline or Distributed mode depending on the workload pattern.

Pass can pass or transform data without performing an external task.

Succeed ends an execution successfully.

Fail ends an execution as a failure.

This is why Step Functions is more useful than simply writing “call service A, then service B.” The control states let the workflow represent real business logic.

Jake's repair flow might say:

• Task: save the booking.
• Choice: determine whether manual approval is required.
• Parallel: send a customer acknowledgment and notify the technician.
• Wait: pause before checking an external repair status.
• Task: update the booking.
• Succeed: mark the workflow complete.

If something fails in the middle, the workflow can follow error-handling behavior rather than relying on a chain of hidden application calls.

How to create a Step Functions workflow in the console

Workflow Studio is the visual builder in the Step Functions console. For a beginner, it is the easiest place to see the relationship between the graph and the ASL definition.

1. Open the AWS Management Console and go to Step Functions.
2. Open State machines.
3. Choose Create state machine.
4. Build the workflow in Workflow Studio.
5. Add flow states or actions to the workflow.
6. Select each state and configure its input, output, retry, error, timeout, and integration settings where applicable.
7. Inspect the generated state-machine definition in code view.
8. Choose the workflow type you actually need: Standard or Express.
9. Configure the state machine name and execution role.
10. Create the state machine.
11. Choose Start execution.
12. Provide JSON input if the workflow expects it.
13. Follow the execution through the graph and execution details.

The execution role is important. IAM, or Identity and Access Management, controls which AWS actions the state machine can perform.

If your workflow contains a Lambda invocation but its role cannot invoke that function, the workflow fails even though the graph looks perfect.

If it calls DynamoDB, SNS, SQS, ECS, or another service, the role needs the permissions required for those actions.

That means the workflow definition answers “what should happen,” while IAM answers “what is this workflow actually allowed to do?”

The Step Functions CLI route

Once a workflow moves beyond experimentation, you usually want its definition in source control instead of depending only on a diagram saved in the console.

A basic create command looks like this:

aws stepfunctions create-state-machine \
  --name RepairWorkflow \
  --definition file://workflow.json \
  --role-arn arn:aws:iam::123456789012:role/StepFunctionsExecutionRole

The ARN is the Amazon Resource Name that uniquely identifies the role.

After the state machine exists, an execution can be started with:

aws stepfunctions start-execution \
  --state-machine-arn arn:aws:states:us-east-1:123456789012:stateMachine:RepairWorkflow \
  --input '{"repairId":"R-1042","priority":"same-day"}'

For a Standard execution, commands such as describe-execution and get-execution-history help inspect what happened.

The CLI also includes validate-state-machine-definition, which is useful in deployment pipelines because you can validate the definition before treating it as ready to deploy.

The practical split is simple: Workflow Studio is excellent for understanding and designing workflows visually; source-controlled ASL plus CLI or infrastructure-as-code deployment is better when repeatability matters.

Step Functions can call services directly

One of the most common beginner misconceptions is that Step Functions means “a chain of Lambda functions.”

Lambda is a popular integration, but Step Functions can coordinate far more than Lambda.

AWS SDK integrations allow workflows to call thousands of API actions across more than 200 AWS services. Optimized integrations provide Step Functions-specific behavior for selected services. Step Functions can also use HTTP Task to call HTTPS APIs.

That creates an important design question: does this step need custom code at all?

If a Lambda function contains important business logic, keep the code where it belongs. If the Lambda's entire job is “call this one supported AWS API and return the result,” check whether a direct integration can remove that glue function.

For example, a workflow may be able to publish to SNS, send an SQS message, update DynamoDB, start an ECS task, invoke Lambda, start another Step Functions execution, run a Glue job, or interact with another supported service directly.

Removing unnecessary glue code has a practical advantage: fewer functions mean fewer deployment units, fewer IAM relationships, fewer logs to search, and fewer places for simple forwarding logic to fail.

That September 2026 change matters because older explanations often describe integration support as a list that can lag behind newly released APIs. The current direction is faster automatic addition of new AWS SDK integrations.

Request Response, .sync, and callback patterns

Calling a service is only half the question. The other half is deciding how long Step Functions should wait before moving on.

Step Functions uses three major service-integration patterns.

Request Response is the default pattern. Step Functions sends the request, waits for the HTTP response, and then progresses to the next state.

Be careful with the word “response.” If an API returns “job accepted,” that does not necessarily mean the long-running job is finished. It only means the API request returned.

Run a Job, written with .sync for supported integrations, lets a Standard Workflow wait until the job completes before moving to the next state.

Wait for Callback, using .waitForTaskToken, lets the workflow pause until an external process returns a task token.

That callback pattern is particularly useful when the next step depends on something outside the immediate AWS API call, including approval or another external process.

Express Workflows support Request Response integrations but not the Run a Job or Wait for Callback integration patterns. That difference alone can rule out Express for some workflows.

Standard vs. Express Workflows

This is the design choice most beginners should understand before they create a production state machine.

If Jake has a repair approval that can wait for a technician or customer for hours, Standard is the natural workflow type to evaluate. Express cannot run beyond five minutes.

If he is processing a large stream of short, high-volume events where work is idempotent and finishes quickly, Express may be a better fit.

Idempotent means repeating an operation does not create an unintended duplicate effect. That matters because asynchronous Express workflows use at-least-once execution semantics; synchronous Express runs are at-most-once instead.

For example, a task that simply recalculates a status may be safe to repeat. A task that charges a credit card needs much more careful duplicate protection.

Do not choose Express only because somebody called it cheaper. The pricing units are different, the runtime limit is different, execution semantics are different, and integration-pattern support is different.

Retry and Catch: failure becomes part of the workflow

Failures in distributed systems are normal. A service can throttle. A network call can fail. A task can time out. A dependency can reject invalid input.

The useful part of Step Functions is not that failures disappear. They do not. The useful part is that you can make failure behavior explicit.

Retry lets a Task retry matching errors using the policy you define.

Catch lets a workflow route matching errors to another state.

Those are different responses to different problems.

A temporary service failure may deserve another attempt. Invalid business data probably does not.

Jake asks, “Why not retry every error ten times and hope one works?”

Ethan answers, “Because a bad phone number does not become a good phone number after ten attempts. Retrying permanent failures only makes the workflow slower and potentially more expensive.”

Retries can also repeat downstream work. If the target operation is not idempotent, you need to understand what a repeated request could do.

Timeouts deserve equal attention. A task that could remain stuck should have a clear idea of how long the workflow is willing to wait.

A workflow definition that contains the retry, timeout, and error route is easier to review than an application where each function quietly implements its own unrelated failure behavior.

How data moves through Step Functions

A state machine execution can begin with JSON input. States can read that input, pass values to services, transform results, store values in variables, and produce output for later steps.

For Jake, an execution might begin with:

{
  "repairId": "R-1042",
  "customerId": "C-205",
  "priority": "same-day",
  "estimatedValue": 180
}

A Choice state can inspect priority. A Task can use repairId. A later state can use the result of an earlier operation.

Modern Step Functions workflows can use variables and JSONata for data transformation. JSONPath remains supported as well.

The reason this deserves its own section is that many apparent Step Functions failures are really data-shape problems.

A task succeeds, but the next state expects the output under a different key. A Choice rule looks for a value that was overwritten. A service returns nested data while the next task expects a flat field.

When an execution fails or takes the wrong branch, inspect the actual state input and output rather than assuming the field is where you remember putting it.

There is also a hard payload boundary: the maximum input or output size for a task, state, or execution is 256 KiB.

Parallel vs. Map: two different kinds of concurrency

Parallel and Map can both make a workflow do more than one thing, but they solve different problems.

Use Parallel when you have a fixed set of different branches.

For example, after Jake accepts a repair, the workflow could run these two branches at the same time:

• Notify the technician.
• Send the customer an acknowledgment.

Those are two known branches that happen to be independent.

Use Map when the workflow needs to repeat processing across a collection of items.

If Jake uploads a list containing 200 devices for a corporate repair batch, Map is the more natural mental model: process each item using the same iterator logic.

Distributed Map exists for larger workloads and can run child workflow executions at high concurrency. A single Map Run currently supports up to 10,000 parallel child workflow executions.

That does not mean “set everything to 10,000 because bigger is faster.” The services downstream from the Map have their own quotas and scaling behavior. A workflow capable of creating large concurrency can overwhelm a dependency if you do not design the rate intentionally.

Parallel has another failure behavior worth knowing: if a branch fails and the error is not handled, the Parallel state can cause the whole execution to fail. If one branch is allowed to fail independently, design that error handling inside the branch.

How much AWS Step Functions costs

Pricing is one place where Standard and Express must not be mixed together.

The prices in this section are US East (N. Virginia) prices checked on October 5, 2026.

Standard Workflows are billed by state transition. A transition is counted when a workflow step executes. Retries create additional billable state transitions.

The Step Functions Standard free tier includes 4,000 state transitions per month. That Step Functions free tier does not automatically expire after 12 months.

The current US East (N. Virginia) Standard price is $0.000025 per state transition.

Here is Jake's worked example.

Assume his normal repair workflow uses six billable transitions and runs 100,000 times in one month with no retries.

6 transitions × 100,000 executions = 600,000 transitions.

Subtract the 4,000 free transitions:

600,000 - 4,000 = 596,000 billable transitions.

Now multiply by $0.000025:

596,000 × $0.000025 = $14.90.

That $14.90 is the Step Functions Standard transition charge in this example. It is not Jake's entire AWS application bill.

If his workflow invokes Lambda, DynamoDB, ECS, Bedrock, PrivateLink, or another paid service, those resources have their own charges.

Express Workflows use a different pricing model. You pay for requests plus execution duration and memory consumption.

AWS currently charges $1.00 per million Express requests in US East (N. Virginia). Duration is measured from execution start until completion or termination, rounded to the nearest 100 ms, and memory is billed in 64 MB chunks.

One current AWS pricing example uses a 64 MB workflow running one million times for 30 seconds each. That example calculates $1.00 in request charges plus $31.26 in duration charges, for $32.26 total Step Functions Express charges.

That example is useful because it shows why “Express costs $1 per million” is incomplete. The request charge is only one part of the Express bill.

The limits that can change your Step Functions design

“Serverless” does not mean “unlimited.” You do not need to memorize every Step Functions quota, but a few are architectural.

Standard maximum execution time: one year.

Express maximum execution time: five minutes.

Maximum task, state, or execution input/output: 256 KiB.

Standard execution-history size: 25,000 events.

If event 25,000 is the successful completion event, a Standard execution can finish successfully. If event 25,000 is not ExecutionSucceeded, the execution fails because it has reached the history quota.

That is why a giant loop inside one Standard execution can become a problem even if each individual task is small.

Distributed Map can help by giving child workflow executions their own histories, and another option for long-running workflows is starting a new execution from the current workflow when appropriate.

Open Standard executions: the current default quota is 1,000,000 open executions for each AWS account in each AWS Region. Express Workflows are not subject to that particular open-execution quota.

Distributed Map: a single Map Run can have up to 10,000 parallel child executions, and the default maximum number of open Map Runs is 1,000.

Closed Standard execution history: retained for 90 days by default. A reduction to 30 days can be requested for compliance or organizational requirements.

Redrive window: a qualifying Standard Workflow execution can be redriven during a 14-day redrivable period. Express workflows do not support redrive.

The practical lesson is not “memorize 10,000, 25,000, and 1,000,000.” The lesson is to identify which quota touches your architecture and check its current value before building your scaling assumption around it.

Step Functions vs. Lambda: manager vs. worker

This is not really a competition between two services.

Lambda runs code.

Step Functions coordinates a process.

A Lambda function might calculate a quote. Another Lambda might validate an order. A third might generate a document.

Step Functions can decide which one runs first, whether a second task depends on its output, what to do when one fails, whether another branch can run concurrently, and whether the workflow should wait before continuing.

Use Lambda alone when the application has one clear event and one clear piece of work and there is no real orchestration problem.

Use Step Functions when coordination itself has become part of the application.

A useful test is to draw the process on paper.

If the boxes are simple but the arrows are becoming complicated, orchestration is becoming the interesting part of the system.

That is where Step Functions starts earning its place.

Step Functions vs. EventBridge: orchestration vs. reaction

Another common question is whether EventBridge replaces Step Functions.

They solve different shapes of problem.

With orchestration, one workflow has an opinion about sequence. It knows what should happen next.

With event-driven choreography, a producer emits an event and independent consumers react to that event.

Imagine Jake completes a repair.

If one central process must update inventory, charge the final amount, wait for a receipt job, then send the customer a message, Step Functions is a natural orchestrator.

If the fact “RepairCompleted” should simply be published so accounting, analytics, loyalty, and notification systems can independently react, an event pattern is natural.

You can combine them. An EventBridge event can start a Step Functions workflow. A workflow can emit events as part of a larger architecture.

Ethan's rule is: “If somebody asks ‘what step is this order currently on?’, that sounds like orchestration. If somebody asks ‘who cares that this event happened?’, that sounds like event distribution.”

Where Step Functions fits well

Step Functions is a strong fit when the process contains real sequencing, decisions, retries, parallel work, waiting, or coordination across services.

Common shapes include order processing, account provisioning, approval processes, data pipelines, machine-learning workflows, infrastructure automation, security automation, media processing, microservice coordination, and batch processing.

Do not focus on the industry. Focus on the process shape.

An insurance claim, repair order, student application, video-processing job, cloud-account setup, and machine-learning pipeline may look unrelated, but they can all have the same workflow characteristics:

• Several steps.
• Conditional branches.
• Independent parallel tasks.
• Retries for temporary failures.
• A need to know where one execution currently is.
• Potential waits between steps.
• A clear success or failure outcome.

That is the pattern Step Functions is designed to represent.

It is especially attractive when your existing code contains many variables whose only purpose is remembering which step completed, or when functions spend large amounts of code deciding which other function should run next.

When I would not use Step Functions

Not every application needs orchestration.

If API Gateway invokes one Lambda, the Lambda does one short operation, and the response returns immediately, adding a state machine may give you another thing to deploy without solving a real problem.

If services are naturally independent consumers of events, forcing all of them into one central workflow can create unnecessary coupling.

If your workflow can exceed five minutes, Express is the wrong workflow type regardless of how attractive its throughput looks.

If you need callback or .sync integration behavior, Express does not support those patterns.

If you are trying to push large files through state input and output, Step Functions state data is the wrong storage layer.

If every task is a Lambda that only forwards one supported AWS API request, check whether direct integrations can simplify the architecture.

The point is not to use Step Functions because the visual graph looks nice. Use it when orchestration is a problem worth solving.

How to debug Step Functions without guessing

The workflow graph is useful because it gives you a structured starting point when something fails.

For Standard Workflows, inspect the execution and identify the state where the failure occurred.

Then inspect the state input, output, error, and cause.

Do not begin by rewriting code.

1. Confirm that the execution actually started.
2. Identify the exact state that failed.
3. Inspect the input that reached the state.
4. Inspect the error and cause.
5. Determine whether the failure came from the state definition, IAM, data transformation, or the integrated service.
6. Check whether Retry or Catch matched the error you expected.
7. Check whether a timeout or quota is involved.
8. Check the target service's own logs or metrics if the Step Functions task successfully reached it.

This order matters.

Jake once thinks the booking Lambda is broken because the workflow stopped at SendConfirmation. But if the error is an IAM authorization failure, changing Lambda code would be wasted effort.

Likewise, if a Choice state follows the wrong path because the field is located under a different JSON object, changing the downstream service will not fix it.

Standard workflows can be visually debugged using execution history. Express workflows require CloudWatch Logs when you want retained execution-history details.

Step Functions symptom-first troubleshooting table

The exact error is more valuable than the general symptom. Copy the error name, failing state, execution ARN, timestamp, and Region before changing the workflow.

That gives you a stable point of comparison after each fix.

What to collect when nothing works

If a Step Functions problem survives the obvious fixes, collect evidence before changing more configuration.

Record the AWS account involved, Region, state-machine ARN, workflow type, execution ARN, failing state name, start time, failure time, error, cause, and execution-role ARN.

Preserve the input that triggers the failure.

If only one branch fails, note the exact field that selects that branch.

If a target AWS service returns the error, collect that resource's ARN or identifier and its relevant logs or metrics.

If throttling is suspected, inspect the Step Functions CloudWatch metric and the downstream service's metrics for the same time window.

If a problem is intermittent, do not replace the useful failing input with a new “clean” test input before you capture it.

If you need AWS Support, “execution ARN X failed in state Y at 14:32 UTC with error Z” is actionable. “My Step Function sometimes fails” is not.

Support also cannot make an IAM-denied call succeed while your policy still denies it, and it cannot make a 6-minute process fit inside the 5-minute Express execution maximum. Some problems require changing the architecture, not escalating the same configuration.

A simple architecture test before you choose Step Functions

Before creating a state machine, answer five questions.

1. Does order matter? If step B must wait for step A, you have sequencing.

2. Are there decisions? If different inputs follow different paths, you have branching.

3. Can anything run in parallel? If independent work can happen concurrently, the graph may express that cleanly.

4. Do failures need different responses? If some failures deserve retry while others need a fallback path, orchestration is doing real work.

5. Do you need to know where an individual process is? If “what step is order 7123 on?” matters, execution visibility is valuable.

If you answer no to all five, Step Functions may not add much.

If you answer yes to several, the workflow is becoming a first-class part of the application and deserves its own definition.

The mental model that makes Step Functions easy to remember

Imagine a restaurant kitchen.

The cooks are the services that do the work.

One cook prepares a starter. Another prepares a main course. Another handles dessert.

The order ticket contains information.

The process decides what starts first, which dishes can be prepared together, when something has to wait, what changes if an ingredient is unavailable, and when the whole meal is considered complete.

Step Functions is that process controller.

It does not need to become the cook.

That one distinction prevents two common design mistakes: putting too much business code into the workflow definition, and putting too much workflow-control code into Lambda functions.

The best Step Functions designs usually keep each layer responsible for its own job.

The worker performs business work.

The state machine coordinates the worker.

IAM controls what the state machine may call.

Input and output carry the data required for the next decision.

Execution history tells you what happened.

Once those responsibilities are separated, the service stops feeling like “another AWS thing to learn” and starts feeling like an executable version of a process diagram.

AWS Step Functions FAQs

1. What is AWS Step Functions in simple terms?

AWS Step Functions is a serverless workflow service. You define a process as states and transitions, then Step Functions coordinates the execution of that process across AWS services, APIs, decisions, waits, retries, and branches.

2. Is AWS Step Functions really a flowchart?

It is more than a picture. Workflow Studio displays a state machine visually, but the state machine is an executable workflow definition. When an execution starts, Step Functions follows that definition rather than merely displaying it.

3. What is a state machine in AWS Step Functions?

A state machine is the complete workflow definition. It names the states, identifies the starting state, and defines how execution moves among states until the workflow succeeds, fails, times out, or reaches another terminal condition.

4. What is the difference between Step Functions and Lambda?

Lambda runs code. Step Functions coordinates workflow logic. A Task state can invoke Lambda, but Step Functions can also call many AWS APIs and HTTPS endpoints directly. They are commonly used together rather than being replacements for each other.

5. Can AWS Step Functions work without Lambda?

Yes. A state machine can use flow states and supported service integrations without invoking Lambda. If a step only needs to call a supported AWS API, a direct Step Functions integration may remove the need for a forwarding Lambda function.

6. What is the difference between Standard and Express Step Functions?

Standard Workflows can run for up to one year, use exactly-once workflow execution semantics, provide detailed Step Functions execution history, and are billed by state transition. Express Workflows can run for up to five minutes, use at-least-once semantics when started asynchronously (at-most-once when synchronous), and are billed by requests, duration, and memory.

7. How long can an AWS Step Functions workflow run?

A Standard Workflow execution can run for up to one year. An Express Workflow execution can run for up to five minutes. A process that can exceed five minutes should not be designed as one Express execution.

8. How much does AWS Step Functions cost?

Standard Workflows are billed by state transition. In US East (N. Virginia), the price checked on October 5, 2026 is $0.000025 per state transition, with 4,000 free Standard transitions per month. Express Workflows are billed by requests plus duration and memory consumption. Other AWS services used by the workflow are billed separately.

9. Does Step Functions have a free tier?

Yes. Standard Workflows include 4,000 free state transitions each month. The Step Functions free tier does not automatically expire at the end of a 12-month AWS Free Tier period.

10. Can Step Functions retry a failed Lambda function?

Yes. A Task can use Retry rules for matching errors and Catch rules to route failures to another state. Retry behavior should be designed for failures that can reasonably succeed on another attempt rather than being applied to every error.

11. Can Step Functions wait for human approval?

Standard Workflows can model long-running approval processes. For supported integrations, the callback pattern can pause the workflow until an external process returns the task token. Standard workflows can run for up to one year.

12. What is a Choice state in AWS Step Functions?

A Choice state creates conditional branching. It evaluates workflow data and selects the next state according to the rules you define. It is the executable equivalent of a decision diamond in a conventional flowchart.

13. What is the maximum Step Functions payload size?

The maximum input or output size for a task, state, or execution is 256 KiB of UTF-8 encoded data. Large files should generally stay in a storage service such as Amazon S3 while the workflow passes a reference to them.

14. What happens when Step Functions reaches 25,000 history events?

A Standard Workflow execution has a hard 25,000-event history quota. If event 25,000 is ExecutionSucceeded, the execution can finish successfully. If it is not the successful completion event, the execution fails because the history limit has been reached.

15. Can AWS Step Functions run tasks in parallel?

Yes. A Parallel state runs separate branches concurrently. Map processes collections of items, and Distributed Map supports large-scale processing through child workflow executions with up to 10,000 parallel child executions in one Map Run.

16. When should I use AWS Step Functions?

Use Step Functions when workflow coordination has become a real application requirement: several steps, conditional branches, waits, retries, parallel work, long-running processing, service integrations, or a need to inspect the progress of individual executions. For one simple action with no orchestration, a state machine may be unnecessary.

The picture to keep in your head

A Step Functions state machine is an executable process.

The states are the boxes. The transitions are the arrows. Task states hand work to services. Choice states select branches. Wait states pause. Parallel and Map create concurrency. Retry and Catch define failure behavior. Input and output carry the information the next step needs.

That is why “the flowchart that runs itself” is a useful beginner explanation.

Just attach one sentence to it so you do not develop the wrong mental model: the flowchart coordinates the work; other services usually perform the work.

If your application has become a collection of functions calling functions, timers hidden in code, retry loops scattered across services, and flags whose only job is remembering what already happened, draw the process. You may discover that the arrows have become important enough to deserve their own service.

And if you are looking at a failed execution tonight, start with the exact failing state, input, error, and execution ARN instead of changing everything around it. A visible workflow is most valuable when you use that visibility.

Revision note. Written October 5, 2026, with the September change that adds new AWS services to Step Functions automatically. If your Lambda chain has quietly grown branches, waits and retries, you are not doing it wrong; it has simply become a workflow.