{
  "content": "# Step Functions vs Lambda: What It Is and When to Use It\n\n## Definition\n\n[AWS Lambda](/terms/lambda) is a serverless, event-driven compute service that runs your code in response to triggers, while [AWS Step Functions](/terms/step-functions) is a serverless orchestration service that lets you coordinate multiple AWS services, including Lambda functions, into visual workflows. The core difference is **compute vs. orchestration**: Lambda performs a single task, whereas Step Functions designs and manages a multi-step process. They are not competitors but are frequently used together to build robust, scalable applications.\n\n## How It Works\n\nUnderstanding the distinction lies in their execution models. AWS Lambda operates on a simple, powerful principle: an event happens, your code runs. This event could be an HTTP request from [Amazon API Gateway](/terms/api-gateway), a new file upload to an [Amazon S3](/terms/s3) bucket, or a message in an [Amazon SQS](/terms/sqs) queue. Lambda automatically provisions an execution environment, runs your function code with the event data as input, and then tears it down. The function itself is stateless, meaning it retains no memory of past invocations.\n\nAWS Step Functions, in contrast, orchestrates workflows defined as **state machines**. You define the workflow using a JSON-based declarative language called Amazon States Language (ASL). This definition creates a visual flowchart in the AWS console, making complex processes easy to understand, debug, and modify.\n\nA state machine is made of states, which are individual steps in your workflow. Key state types include:\n*   **Task:** The most common state, representing a unit of work. This can be invoking a Lambda function, running a container on [Amazon ECS](/terms/ecs), interacting with a database like [Amazon DynamoDB](/terms/dynamodb), or calling one of over 220 integrated AWS services directly.\n*   **Choice:** Adds branching logic (like an if/then/else statement) to your workflow.\n*   **Parallel:** Allows for multiple branches of execution to run concurrently.\n*   **Map:** Dynamically processes items in a dataset in parallel.\n*   **Wait:** Pauses the workflow for a specified time.\n\nWhen an execution starts, Step Functions moves from one state to the next, passing the output of the previous step as input to the current one. This allows it to manage the state of your entire workflow automatically, a critical feature that standalone Lambda functions lack.\n\n### Direct Comparison: Lambda vs. Step Functions\n\n| Feature | AWS Lambda (Standalone) | AWS Step Functions | \n| :--- | :--- | :--- | \n| **Primary Role** | Event-driven Compute | Workflow Orchestration | \n| **Execution Model** | Runs a single function in response to a trigger | Executes a multi-step state machine | \n| **State Management** | Stateless by default (requires external database) | Built-in state management between steps | \n| **Max Duration** | 15 minutes | 1 year (Standard Workflows) / 5 minutes (Express Workflows) | \n| **Error Handling** | In-code (try/catch), Dead-Letter Queues (DLQs) | Declarative, workflow-level retry/catch logic | \n| **Visibility** | Logs and traces in [Amazon CloudWatch](/terms/cloudwatch) | Visual execution history graph, detailed event log | \n| **Core Problem Solved** | Running code without managing servers | Coordinating distributed components and microservices | \n\n## Key Features and Limits\n\n### AWS Lambda (as of 2026)\n*   **Execution Timeout:** Maximum of 15 minutes (900 seconds).\n*   **Memory:** 128 MB to 10 GB. CPU power is allocated proportionally.\n*   **Ephemeral Storage:** Up to 10 GB in the `/tmp` directory.\n*   **Concurrency:** Default 1,000 concurrent executions per region (can be increased).\n*   **Payload Size:** 6 MB (synchronous) and 256 KB (asynchronous) request/response.\n*   **Deployment Package Size:** 50 MB (zipped, direct upload), 250 MB (unzipped, including layers).\n\n### AWS Step Functions (as of 2026)\n*   **Workflow Types:**\n    *   **Standard:** For long-running, durable, and auditable workflows. Can run for up to one year. Executes exactly once.\n    *   **Express:** For high-volume, short-duration (up to 5 minutes) event-processing workflows. Executes at least once.\n*   **Execution History:** 25,000 events. For longer workflows, patterns must be used to stay within this limit.\n*   **Payload Size:** 256 KB passed between states. Larger payloads must be stored in S3 and referenced.\n*   **State Machines per Account:** 100,000 per region.\n*   **Service Integrations:** Over 220 direct AWS service integrations, reducing the need for Lambda "glue" code.\n\n## Common Use Cases\n\n**Choose AWS Lambda (standalone) for:**\n*   **Real-time Data Processing:** Simple, fast transformations of data streams from services like [Amazon Kinesis](/terms/kinesis).\n*   **Web Backends:** Powering serverless APIs via Amazon API Gateway for simple CRUD (Create, Read, Update, Delete) operations.\n*   **Single-Task Automation:** Responding to a specific event, like creating a thumbnail when an image is uploaded to S3.\n\n**Choose AWS Step Functions to orchestrate Lambda functions and other services for:**\n*   **Business Process Automation:** Multi-step processes like order fulfillment, which involves checking inventory, processing payment, and scheduling shipping.\n*   **Data Processing & ETL Pipelines:** Complex Extract, Transform, Load (ETL) jobs that require multiple stages, error handling, and parallel processing.\n*   **Infrastructure Automation:** Provisioning AWS resources in a specific order, with waits and checks to ensure one step completes before the next begins.\n*   **Human-in-the-Loop Workflows:** Processes that require manual approval. A workflow can pause using a callback pattern and wait for an external signal to resume.\n*   **Microservice Orchestration:** Coordinating a sequence of calls to different microservices to complete a larger transaction, with robust error handling and state management.\n\n## Pricing Model\n\nYou are billed for both services independently, even when used together.\n\n*   **AWS Lambda:** Pricing is based on two main factors: the number of requests for your functions and the duration of their execution, measured in gigabyte-seconds (GB-s). There is a perpetual free tier that includes 1 million requests and 400,000 GB-seconds of compute time per month.\n\n*   **AWS Step Functions:** The pricing model depends on the workflow type.\n    *   **Standard Workflows:** Billed per state transition (each time a step in your workflow is executed). A free tier includes 4,000 state transitions per month.\n    *   **Express Workflows:** Billed based on the number of executions, execution duration, and memory consumed. This model is more cost-effective for high-volume, short-duration tasks.\n\nIt's important to remember that you also pay for any AWS services your state machine invokes, such as Lambda execution costs, API Gateway calls, or data transfer charges.\n\n## Pros and Cons\n\n### AWS Lambda (for Orchestration)\n*   **Pros:** Simpler for very basic, linear sequences. Can be cheaper if state transitions are extremely high and logic is simple.\n*   **Cons:** Leads to a pattern called \"Lambda Pinball\" or \"function chaining,\" where functions trigger each other. This creates a brittle, tightly coupled architecture that is difficult to debug, visualize, and maintain. State management and error handling must be custom-built, adding significant complexity.\n\n### AWS Step Functions\n*   **Pros:**\n    *   **Resilience:** Built-in error handling, retries, and catch blocks at the workflow level.\n    *   **Visibility:** Provides a visual audit trail of every execution, simplifying debugging.\n    *   **State Management:** Automatically manages and passes state between steps.\n    *   **Decoupling:** Separates workflow logic from business logic, making components more reusable and easier to modify.\n*   **Cons:**\n    *   **Overhead:** Can be overkill for simple, single-step tasks.\n    *   **Cost:** For extremely high-volume, simple workflows, the cost per state transition in Standard Workflows can be higher than a single, larger Lambda function.\n    *   **Payload Limits:** The 256 KB payload limit between states requires careful management for data-intensive workflows.\n\n## Comparison with Alternatives\n\n*   **Amazon Simple Workflow Service (SWF):** SWF is an older workflow service that provides more control but also requires more management. It involves writing \"decider\" logic to manage the workflow's state and task scheduling. For most new applications, AWS recommends Step Functions as it offers a more productive, serverless, and integrated approach.\n\n## Exam Relevance\n\nUnderstanding the difference between Lambda and Step Functions is critical for several AWS certifications, especially:\n*   **AWS Certified Developer - Associate (DVA-C02):** Questions focus on choosing the right service to build resilient, scalable microservice-based applications. Expect scenarios asking how to coordinate multiple Lambda functions or handle long-running processes.\n*   **AWS Certified Solutions Architect - Associate (SAA-C03):** Focuses on architectural patterns. You'll need to know when to use Step Functions to decouple components and improve the reliability of a distributed system.\n\nExaminees must understand that Step Functions is the primary service for orchestrating multi-step, stateful workflows, while Lambda is the compute engine that often executes the individual steps.\n\n## Frequently Asked Questions\n\n### Q: Can AWS Step Functions run without AWS Lambda?\nA: Yes, absolutely. Step Functions can directly integrate with over 220 AWS services. For example, you can have a state that writes an item to a DynamoDB table, sends a message to an SQS queue, or starts a job in [AWS Batch](/terms/batch), all without writing any Lambda code. This is a powerful way to reduce \"glue\" code and cost.\n\n### Q: What is the maximum execution time for a Step Functions workflow?\nA: A Standard Workflow can run for a maximum of one year. This makes it suitable for very long-running processes, including those that require human intervention. Express Workflows are designed for high-volume, short-duration tasks and have a maximum execution time of five minutes.\n\n### Q: How do I manage data and state between steps in a workflow?\nA: Step Functions automatically handles state. The JSON output of a state is passed as the input to the next state by default. You can use built-in features like `InputPath`, `OutputPath`, and `ResultPath` within your state machine definition to filter and manipulate the JSON data as it flows through the workflow, ensuring each step gets exactly the input it needs.\n\n---\n*This article reflects AWS features and pricing as of 2026. AWS services evolve rapidly — always verify against the [official AWS documentation](https://docs.aws.amazon.com/) before making production decisions.*",
  "contentPlain": "# Step Functions vs Lambda: What It Is and When to Use It\n\n## Definition\n\nAWS Lambda is a serverless, event-driven compute service that runs your code in response to triggers, while AWS Step Functions is a serverless orchestration service that lets you coordinate multiple AWS services, including Lambda functions, into visual workflows. The core difference is **compute vs. orchestration**: Lambda performs a single task, whereas Step Functions designs and manages a multi-step process. They are not competitors but are frequently used together to build robust, scalable applications.\n\n## How It Works\n\nUnderstanding the distinction lies in their execution models. AWS Lambda operates on a simple, powerful principle: an event happens, your code runs. This event could be an HTTP request from Amazon API Gateway, a new file upload to an Amazon S3 bucket, or a message in an Amazon SQS queue. Lambda automatically provisions an execution environment, runs your function code with the event data as input, and then tears it down. The function itself is stateless, meaning it retains no memory of past invocations.\n\nAWS Step Functions, in contrast, orchestrates workflows defined as **state machines**. You define the workflow using a JSON-based declarative language called Amazon States Language (ASL). This definition creates a visual flowchart in the AWS console, making complex processes easy to understand, debug, and modify.\n\nA state machine is made of states, which are individual steps in your workflow. Key state types include:\n*   **Task:** The most common state, representing a unit of work. This can be invoking a Lambda function, running a container on Amazon ECS, interacting with a database like Amazon DynamoDB, or calling one of over 220 integrated AWS services directly.\n*   **Choice:** Adds branching logic (like an if/then/else statement) to your workflow.\n*   **Parallel:** Allows for multiple branches of execution to run concurrently.\n*   **Map:** Dynamically processes items in a dataset in parallel.\n*   **Wait:** Pauses the workflow for a specified time.\n\nWhen an execution starts, Step Functions moves from one state to the next, passing the output of the previous step as input to the current one. This allows it to manage the state of your entire workflow automatically, a critical feature that standalone Lambda functions lack.\n\n### Direct Comparison: Lambda vs. Step Functions\n\n| Feature | AWS Lambda (Standalone) | AWS Step Functions | \n| :--- | :--- | :--- | \n| **Primary Role** | Event-driven Compute | Workflow Orchestration | \n| **Execution Model** | Runs a single function in response to a trigger | Executes a multi-step state machine | \n| **State Management** | Stateless by default (requires external database) | Built-in state management between steps | \n| **Max Duration** | 15 minutes | 1 year (Standard Workflows) / 5 minutes (Express Workflows) | \n| **Error Handling** | In-code (try/catch), Dead-Letter Queues (DLQs) | Declarative, workflow-level retry/catch logic | \n| **Visibility** | Logs and traces in Amazon CloudWatch | Visual execution history graph, detailed event log | \n| **Core Problem Solved** | Running code without managing servers | Coordinating distributed components and microservices | \n\n## Key Features and Limits\n\n### AWS Lambda (as of 2026)\n*   **Execution Timeout:** Maximum of 15 minutes (900 seconds).\n*   **Memory:** 128 MB to 10 GB. CPU power is allocated proportionally.\n*   **Ephemeral Storage:** Up to 10 GB in the `/tmp` directory.\n*   **Concurrency:** Default 1,000 concurrent executions per region (can be increased).\n*   **Payload Size:** 6 MB (synchronous) and 256 KB (asynchronous) request/response.\n*   **Deployment Package Size:** 50 MB (zipped, direct upload), 250 MB (unzipped, including layers).\n\n### AWS Step Functions (as of 2026)\n*   **Workflow Types:**\n    *   **Standard:** For long-running, durable, and auditable workflows. Can run for up to one year. Executes exactly once.\n    *   **Express:** For high-volume, short-duration (up to 5 minutes) event-processing workflows. Executes at least once.\n*   **Execution History:** 25,000 events. For longer workflows, patterns must be used to stay within this limit.\n*   **Payload Size:** 256 KB passed between states. Larger payloads must be stored in S3 and referenced.\n*   **State Machines per Account:** 100,000 per region.\n*   **Service Integrations:** Over 220 direct AWS service integrations, reducing the need for Lambda \"glue\" code.\n\n## Common Use Cases\n\n**Choose AWS Lambda (standalone) for:**\n*   **Real-time Data Processing:** Simple, fast transformations of data streams from services like Amazon Kinesis.\n*   **Web Backends:** Powering serverless APIs via Amazon API Gateway for simple CRUD (Create, Read, Update, Delete) operations.\n*   **Single-Task Automation:** Responding to a specific event, like creating a thumbnail when an image is uploaded to S3.\n\n**Choose AWS Step Functions to orchestrate Lambda functions and other services for:**\n*   **Business Process Automation:** Multi-step processes like order fulfillment, which involves checking inventory, processing payment, and scheduling shipping.\n*   **Data Processing & ETL Pipelines:** Complex Extract, Transform, Load (ETL) jobs that require multiple stages, error handling, and parallel processing.\n*   **Infrastructure Automation:** Provisioning AWS resources in a specific order, with waits and checks to ensure one step completes before the next begins.\n*   **Human-in-the-Loop Workflows:** Processes that require manual approval. A workflow can pause using a callback pattern and wait for an external signal to resume.\n*   **Microservice Orchestration:** Coordinating a sequence of calls to different microservices to complete a larger transaction, with robust error handling and state management.\n\n## Pricing Model\n\nYou are billed for both services independently, even when used together.\n\n*   **AWS Lambda:** Pricing is based on two main factors: the number of requests for your functions and the duration of their execution, measured in gigabyte-seconds (GB-s). There is a perpetual free tier that includes 1 million requests and 400,000 GB-seconds of compute time per month.\n\n*   **AWS Step Functions:** The pricing model depends on the workflow type.\n    *   **Standard Workflows:** Billed per state transition (each time a step in your workflow is executed). A free tier includes 4,000 state transitions per month.\n    *   **Express Workflows:** Billed based on the number of executions, execution duration, and memory consumed. This model is more cost-effective for high-volume, short-duration tasks.\n\nIt's important to remember that you also pay for any AWS services your state machine invokes, such as Lambda execution costs, API Gateway calls, or data transfer charges.\n\n## Pros and Cons\n\n### AWS Lambda (for Orchestration)\n*   **Pros:** Simpler for very basic, linear sequences. Can be cheaper if state transitions are extremely high and logic is simple.\n*   **Cons:** Leads to a pattern called \"Lambda Pinball\" or \"function chaining,\" where functions trigger each other. This creates a brittle, tightly coupled architecture that is difficult to debug, visualize, and maintain. State management and error handling must be custom-built, adding significant complexity.\n\n### AWS Step Functions\n*   **Pros:**\n    *   **Resilience:** Built-in error handling, retries, and catch blocks at the workflow level.\n    *   **Visibility:** Provides a visual audit trail of every execution, simplifying debugging.\n    *   **State Management:** Automatically manages and passes state between steps.\n    *   **Decoupling:** Separates workflow logic from business logic, making components more reusable and easier to modify.\n*   **Cons:**\n    *   **Overhead:** Can be overkill for simple, single-step tasks.\n    *   **Cost:** For extremely high-volume, simple workflows, the cost per state transition in Standard Workflows can be higher than a single, larger Lambda function.\n    *   **Payload Limits:** The 256 KB payload limit between states requires careful management for data-intensive workflows.\n\n## Comparison with Alternatives\n\n*   **Amazon Simple Workflow Service (SWF):** SWF is an older workflow service that provides more control but also requires more management. It involves writing \"decider\" logic to manage the workflow's state and task scheduling. For most new applications, AWS recommends Step Functions as it offers a more productive, serverless, and integrated approach.\n\n## Exam Relevance\n\nUnderstanding the difference between Lambda and Step Functions is critical for several AWS certifications, especially:\n*   **AWS Certified Developer - Associate (DVA-C02):** Questions focus on choosing the right service to build resilient, scalable microservice-based applications. Expect scenarios asking how to coordinate multiple Lambda functions or handle long-running processes.\n*   **AWS Certified Solutions Architect - Associate (SAA-C03):** Focuses on architectural patterns. You'll need to know when to use Step Functions to decouple components and improve the reliability of a distributed system.\n\nExaminees must understand that Step Functions is the primary service for orchestrating multi-step, stateful workflows, while Lambda is the compute engine that often executes the individual steps.\n\n## Frequently Asked Questions\n\n### Q: Can AWS Step Functions run without AWS Lambda?\nA: Yes, absolutely. Step Functions can directly integrate with over 220 AWS services. For example, you can have a state that writes an item to a DynamoDB table, sends a message to an SQS queue, or starts a job in AWS Batch, all without writing any Lambda code. This is a powerful way to reduce \"glue\" code and cost.\n\n### Q: What is the maximum execution time for a Step Functions workflow?\nA: A Standard Workflow can run for a maximum of one year. This makes it suitable for very long-running processes, including those that require human intervention. Express Workflows are designed for high-volume, short-duration tasks and have a maximum execution time of five minutes.\n\n### Q: How do I manage data and state between steps in a workflow?\nA: Step Functions automatically handles state. The JSON output of a state is passed as the input to the next state by default. You can use built-in features like `InputPath`, `OutputPath`, and `ResultPath` within your state machine definition to filter and manipulate the JSON data as it flows through the workflow, ensuring each step gets exactly the input it needs.\n\n---\n*This article reflects AWS features and pricing as of 2026. AWS services evolve rapidly — always verify against the [official AWS documentation](https://docs.aws.amazon.com/) before making production decisions.*",
  "faq": [
    {
      "question": "Can AWS Step Functions run without AWS Lambda?",
      "answer": "Yes, absolutely. Step Functions can directly integrate with over 220 AWS services. For example, you can have a state that writes an item to a DynamoDB table, sends a message to an SQS queue, or starts a job in AWS Batch, all without writing any Lambda code. This is a powerful way to reduce \"glue\" code and cost."
    },
    {
      "question": "What is the maximum execution time for a Step Functions workflow?",
      "answer": "A Standard Workflow can run for a maximum of one year. This makes it suitable for very long-running processes, including those that require human intervention. Express Workflows are designed for high-volume, short-duration tasks and have a maximum execution time of five minutes."
    },
    {
      "question": "How do I manage data and state between steps in a workflow?",
      "answer": "Step Functions automatically handles state. The JSON output of a state is passed as the input to the next state by default. You can use built-in features like `InputPath`, `OutputPath`, and `ResultPath` within your state machine definition to filter and manipulate the JSON data as it flows through the workflow, ensuring each step gets exactly the input it needs."
    }
  ]
}