What is the difference between Standard and Express Step Functions workflows?

Standard workflows can run for up to one year, support exactly-once execution semantics, and provide full execution history. They charge per state transition. Express workflows run for up to five minutes, support at-least-once (asynchronous) or at-most-once (synchronous) execution, and charge per execution based on duration and memory. Express is ideal for high-volume, short-duration event processing, while Standard suits long-running orchestration.

How does error handling work in Step Functions?

Each Task state can define Retry and Catch blocks. Retry specifies which error types to retry with configurable intervals, backoff rates, and maximum attempts. Catch defines fallback states to transition to when retries are exhausted. Error types include built-in names like States.Timeout, States.TaskFailed, and States.ALL, plus custom error names thrown by Lambda functions. Proper error handling prevents workflow failures from cascading and enables graceful degradation.

Can Step Functions call services other than Lambda?

Yes, Step Functions has optimized integrations with over 220 AWS services including DynamoDB, SQS, SNS, ECS, EMR, Glue, SageMaker, and Bedrock. These SDK integrations let you call AWS APIs directly from a Task state without writing Lambda wrapper functions. Each integration supports three patterns: Request Response (fire and forget), Run a Job (.sync for synchronous execution), and Wait for Callback (.waitForTaskToken for external signals).

AWS Step Functions Workflow Builder

ServerlessAWS

Build Step Functions state machine ASL definitions with tasks, choices, and retries.

Last verified: May 2026

Step Functions Configuration

Build Step Functions state machine definitions using Amazon States Language (ASL).

Required Fields

CommentStartAtStates

{
  "Comment": "Order processing workflow",
  "StartAt": "ValidateOrder",
  "States": {
    "ValidateOrder": {
      "Type": "Task",
      "Resource": "arn:aws:lambda:us-east-1:123456789012:function:validate-order",
      "Next": "CheckInventory",
      "Retry": [
        {
          "ErrorEquals": ["States.TaskFailed"],
          "IntervalSeconds": 3,
          "MaxAttempts": 2,
          "BackoffRate": 1.5
        }
      ]
    },
    "CheckInventory": {
      "Type": "Choice",
      "Choices": [
        {
          "Variable": "$.inventoryAvailable",
          "BooleanEquals": true,
          "Next": "ProcessPayment"
        }
      ],
      "Default": "OutOfStock"
    },
    "ProcessPayment": {
      "Type": "Task",
      "Resource": "arn:aws:lambda:us-east-1:123456789012:function:process-payment",
      "Next": "ShipOrder"
    },
    "ShipOrder": {
      "Type": "Task",
      "Resource": "arn:aws:lambda:us-east-1:123456789012:function:ship-order",
      "End": true
    },
    "OutOfStock": {
      "Type": "Fail",
      "Error": "InventoryUnavailable",
      "Cause": "Requested items are out of stock."
    }
  }
}

Generated Output

Output will appear here...

About This Tool

AWS Step Functions orchestrates multi-step serverless workflows using the Amazon States Language (ASL), a JSON-based specification that defines states, transitions, error handling, and parallel execution branches. Writing ASL by hand is error-prone because of its strict schema requirements for state types (Task, Choice, Parallel, Map, Wait, Pass, Succeed, Fail), input/output processing with JSONPath, and retry/catch configurations. The Step Functions Workflow Builder provides a guided interface for assembling ASL definitions with correct state structures, transition logic, and error handling, generating valid JSON that can be deployed directly to Step Functions.

Real-World Scenario

Your team is migrating a 12-step order pipeline from a Lambda function chain (where each step's failure required custom retry logic) to Step Functions. The builder generates ASL with: 5 Task states for AWS service integrations (DynamoDB, SNS, Lambda for custom logic), Choice state for branching on fraud check result, Wait state with callback for human approval, retry config on transient errors, and catch block routing to a Fail state with detailed error info. End-to-end pipeline visibility goes from 'Lambda logs scattered across CloudWatch groups' to 'one execution graph showing every step'.

When to Use This Tool

•Building an order processing workflow with sequential steps for validation, payment, inventory, and shipping with retry logic on transient failures
•Creating a data pipeline workflow that uses Map state to process S3 objects in parallel with configurable concurrency limits
•Designing a human approval workflow with Wait states and callback patterns that pause execution until an external signal is received
•Generating ASL definitions for workflows that branch using Choice states based on input data conditions

Pro Tips

TIP

Express workflows are billed per execution, duration, and memory — but they cap at 5 minutes. If your workflow occasionally exceeds 5 minutes on retries (e.g., slow downstream service), it silently fails. Always set a CloudWatch alarm on ExecutionsFailed for Express workflows.

TIP

State transitions in Standard workflows include every Pass, Choice branch evaluation, and Map iteration. A Map state iterating over 1,000 items generates 1,000+ transitions. Use Express workflows for high-iteration Map states to avoid bill shock — Express's per-execution model is dramatically cheaper for fan-out work.

TIP

Use the AWS SDK integrations directly from Task states instead of writing Lambda glue. A Task state that calls dynamodb:GetItem directly is faster, cheaper, and simpler than a Lambda function that does the same call. Most Lambda glue functions in workflows can be replaced with native SDK integrations.

How It Works Under the Hood

The builder generates Amazon States Language (ASL) JSON definitions with: state types (Task, Choice, Parallel, Map, Wait, Pass, Succeed, Fail), transitions (Next/End/Default), input/output processing (InputPath, ResultPath, OutputPath, ResultSelector), retry configurations (ErrorEquals, IntervalSeconds, MaxAttempts, BackoffRate), and catch blocks. Output validates against the ASL schema before generating, surfacing common mistakes like unreachable states or undefined transitions.

Frequently Asked Questions

What is the difference between Standard and Express Step Functions workflows?: Standard workflows can run for up to one year, support exactly-once execution semantics, and provide full execution history. They charge per state transition. Express workflows run for up to five minutes, support at-least-once (asynchronous) or at-most-once (synchronous) execution, and charge per execution based on duration and memory. Express is ideal for high-volume, short-duration event processing, while Standard suits long-running orchestration.
How does error handling work in Step Functions?: Each Task state can define Retry and Catch blocks. Retry specifies which error types to retry with configurable intervals, backoff rates, and maximum attempts. Catch defines fallback states to transition to when retries are exhausted. Error types include built-in names like States.Timeout, States.TaskFailed, and States.ALL, plus custom error names thrown by Lambda functions. Proper error handling prevents workflow failures from cascading and enables graceful degradation.
Can Step Functions call services other than Lambda?: Yes, Step Functions has optimized integrations with over 220 AWS services including DynamoDB, SQS, SNS, ECS, EMR, Glue, SageMaker, and Bedrock. These SDK integrations let you call AWS APIs directly from a Task state without writing Lambda wrapper functions. Each integration supports three patterns: Request Response (fire and forget), Run a Job (.sync for synchronous execution), and Wait for Callback (.waitForTaskToken for external signals).

Related Learning Guides

Lambda Performance Tuning26 min read

Was this tool helpful?

Disclaimer: This tool runs entirely in your browser. No data is sent to our servers. Always verify outputs before using them in production. AWS, Azure, and GCP are trademarks of their respective owners.