This chapter focuses on AWS Step Functions workflow types—Standard and Express—and their cost implications, a key topic for the Cost Optimized domain (Objective 4.3) of the SAA-C03 exam. Understanding when to use each workflow type can significantly reduce costs while meeting performance requirements. Approximately 5-10% of exam questions touch on Step Functions, often testing the trade-offs between durability, execution duration, and pricing. This chapter provides the precise details you need to select the right workflow and optimize costs.
Jump to a section
Think of AWS Step Functions as a system for coordinating a series of tasks to produce a product. A Standard Workflow is like a factory assembly line: each worker (state) performs a task and passes the partially finished product to the next worker in a fixed sequence. The line runs continuously, and each product (execution) follows the same path from start to finish. The factory has a single, slow-moving conveyor belt that ensures every step is completed exactly once, in order. If a worker stops, the entire line pauses until they resume. This is ideal when you need strict ordering, durability, and the ability to look back at every product that ever went through. An Express Workflow, on the other hand, is like a fleet of couriers delivering packages. Each courier receives a request (event) and independently decides the fastest route to complete the delivery. They don't follow a fixed path; they might skip intermediate stops if the package is already complete. The system is highly parallel and fast, but it doesn't keep a detailed log of every courier's journey—only the final delivery status. If a courier fails, the package is lost unless you have a backup system. This is perfect when you need to process millions of requests per second and can tolerate occasional losses or need only aggregate results.
What Are Step Functions Workflows?
AWS Step Functions is a serverless orchestration service that lets you coordinate multiple AWS services into a workflow. Each workflow is a state machine defined using Amazon States Language (ASL). You can choose between two workflow types: Standard and Express.
Why Two Types?
Standard Workflows are designed for long-running, durable, and auditable processes. They guarantee exactly-once execution and can run for up to one year. Express Workflows are designed for high-volume, short-duration workloads that can tolerate at-least-once or at-most-once execution (depending on the mode). They run for up to five minutes. The choice directly impacts cost, execution semantics, and monitoring capabilities.
How They Work Internally
Standard Workflows persist each execution’s history to Amazon CloudWatch Logs and optionally to Amazon S3. Each state transition is recorded, allowing you to replay or audit the entire execution history. The service ensures that each state is executed exactly once, even in the face of failures. Internally, Standard Workflows use a distributed database to track execution state, which introduces latency (typically hundreds of milliseconds per state transition). This makes them unsuitable for sub-second response times.
Express Workflows are optimized for speed. They do not persist execution history by default; instead, they can publish execution results to CloudWatch Logs, Amazon S3, or Amazon EventBridge. They use a lightweight, in-memory execution model that can process thousands of state transitions per second. However, because they don’t persist intermediate state, they cannot guarantee exactly-once execution. Express Workflows come in two modes: - Synchronous: The caller waits for the workflow to complete. Provides at-least-once execution (a state may be executed more than once if retries occur). - Asynchronous: The caller fires and forgets. Provides at-most-once execution (if the workflow fails, it may not be retried; some states may not execute).
Key Components, Values, Defaults, and Timers
Maximum Execution Duration:
Standard: Up to 1 year (31,536,000 seconds).
Express: Up to 5 minutes (300 seconds).
Maximum State Transition Rate:
Standard: ~1,000 transitions per second per account (soft limit, adjustable).
Express: ~100,000 transitions per second per account (soft limit, adjustable).
Execution History Retention:
Standard: Up to 90 days in CloudWatch Logs, or indefinitely if exported to S3.
Express: Not persisted by default; only final results can be logged to CloudWatch Logs or S3.
Pricing Model:
Standard: Pay per state transition. As of 2025, $0.025 per 1,000 state transitions.
Express: Pay per execution, duration, and memory consumption. $1.00 per 1 million executions, plus $0.0000166667 per GB-second (for memory of 64 MB to 256 MB, billed in 1 MB increments).
Execution Modes (Express only):
Synchronous: Request-Response pattern. The caller invokes the workflow and waits for a response. Retries are automatic on transient errors.
Asynchronous: Event-driven. The caller invokes and immediately receives an execution ARN. No automatic retries; failures are lost unless you capture them via CloudWatch Logs.
Configuration and Verification
To create a Standard Workflow using the AWS CLI:
aws stepfunctions create-state-machine \
--name my-standard-workflow \
--definition file://workflow.asl.json \
--role-arn arn:aws:iam::123456789012:role/stepfunctions-role \
--type STANDARDTo create an Express Workflow:
aws stepfunctions create-state-machine \
--name my-express-workflow \
--definition file://workflow.asl.json \
--role-arn arn:aws:iam::123456789012:role/stepfunctions-role \
--type EXPRESSTo verify the type of an existing state machine:
aws stepfunctions describe-state-machine \
--state-machine-arn arn:aws:states:us-east-1:123456789012:stateMachine:my-workflowLook for the type field in the output: STANDARD or EXPRESS.
Interaction with Related Technologies
CloudWatch Logs: Both workflow types can log execution events. Standard Workflows log each state transition; Express Workflows log only final results (or errors) if configured.
Amazon S3: Standard Workflows can export execution history to S3 for long-term storage. Express Workflows can write final results to S3.
Amazon EventBridge: Express Workflows can be triggered by EventBridge events, enabling event-driven architectures. Standard Workflows can also be triggered but are better for long-running processes.
AWS Lambda: Both types can invoke Lambda functions. Lambda timeouts (max 15 minutes) affect Express Workflows (max 5 minutes total) more critically.
AWS SDK Service Integrations: Both support over 200 AWS services, but the integration pattern differs: Standard Workflows wait for a service to complete (e.g., an EMR job), while Express Workflows are designed for fast, synchronous calls.
Cost Optimization Strategies
Use Express for high-volume, short tasks: If your workflow runs under 5 minutes and you don't need full history, Express is cheaper per execution.
Use Standard for long-running workflows: If execution lasts hours or days, Standard is the only option.
Batch state transitions: Combine multiple steps into a single Lambda function to reduce transition count for Standard Workflows.
Choose synchronous or asynchronous Express mode wisely: Synchronous mode includes retries, which can increase costs; asynchronous mode is cheaper but less reliable.
Monitor memory usage: Express Workflows bill for memory (64 MB minimum). Use the smallest memory that meets your needs.
Common Pitfalls
Assuming Express is always cheaper: For low-volume, long-running workflows, Standard may be more cost-effective because Express charges per execution duration.
Ignoring execution history needs: If you need to audit every step, Standard is required. Express does not persist intermediate state.
Using Express for workflows that exceed 5 minutes: The execution will be throttled and fail.
Not setting up logging for Express: Without CloudWatch Logs or S3, you won't see errors or results.
Mixing up synchronous and asynchronous modes: Synchronous is for request-response; asynchronous is for fire-and-forget. Using the wrong mode can break your application logic.
Define the State Machine
Write the Amazon States Language (ASL) JSON definition. Include states (Task, Choice, Parallel, etc.), transitions, and error handling. For Standard Workflows, you can use Wait states for delays up to one year. For Express, Wait states are limited to 5 minutes total. The definition is identical for both types; the difference is how the service executes it.
Choose Workflow Type
Decide between STANDARD and EXPRESS based on execution duration, volume, and durability needs. Standard is for long-running, auditable processes. Express is for high-throughput, short-lived tasks. This choice cannot be changed after creation; you must create a new state machine to switch types.
Invoke the Workflow
Use the AWS SDK, CLI, or EventBridge to start an execution. For Standard, you call `start-execution`. For Express, you call `start-sync-execution` (synchronous) or `start-execution` (asynchronous). The invocation method affects how the caller receives results. For synchronous Express, the API returns the execution output directly. For asynchronous, it returns an execution ARN.
Execution and State Transitions
The service processes each state sequentially for Standard Workflows, persisting state after each transition. For Express, states are processed in-memory with minimal latency. Standard Workflows record every transition to CloudWatch Logs; Express records only final results. If a state fails, Standard Workflows can retry according to the ASL definition; Express synchronous mode retries, but asynchronous mode does not.
Completion and Billing
When the workflow completes, Standard Workflows emit a `ExecutionSucceeded` event and you can retrieve the history. Express Workflows emit the final output (if synchronous) or log it to CloudWatch. Billing occurs per transition (Standard) or per execution and duration (Express). For Express, the clock starts when the execution begins and stops when it ends. For Standard, you are billed per transition regardless of duration.
Scenario 1: E-commerce Order Processing Pipeline
An online retailer uses Step Functions to orchestrate order validation, payment processing, inventory update, and shipping. Orders can take up to 10 minutes to process because of third-party payment gateways and inventory checks. They need full auditability for compliance. The solution uses a Standard Workflow. Each order is an execution that runs for ~8 minutes, with around 50 state transitions. At 10,000 orders per day, the cost is approximately 10,000 * 50 * ($0.025/1000) = $12.50 per day. If they mistakenly used Express, the workflow would fail because it exceeds 5 minutes. The correct choice is Standard.
Scenario 2: Real-time Data Transformation
A streaming analytics company processes millions of events per second from IoT devices. Each event triggers a short workflow that transforms the data and writes to a database. The workflow runs in under 100 ms. They do not need per-event history; only aggregate metrics matter. They use an Express Workflow (asynchronous) to fire and forget. With 10 million executions per day, each lasting 50 ms with 64 MB memory, cost is: executions: 10,000,000 * ($1.00/1,000,000) = $10.00; duration: 10,000,000 * 0.05 seconds * 64 MB (0.0625 GB) * $0.0000166667/GB-second = $0.33. Total ~$10.33 per day. If they used Standard, at 10 transitions per execution, cost would be 10,000,000 * 10 * ($0.025/1000) = $2,500 per day, which is 240x more expensive.
Scenario 3: Periodic Report Generation
A financial services firm generates daily reports that take 30 minutes to run. They need exactly-once execution and the ability to retry if a step fails. They use a Standard Workflow. The cost is low because only one execution per day with ~100 transitions. Express is not possible due to the 5-minute limit.
Common Misconfigurations
Using Express for a workflow that sometimes exceeds 5 minutes due to variable data size. The solution is to add a check at the start and fall back to Standard if the expected duration is too long.
Not setting CloudWatch Logs for Express workflows, then unable to debug failures. Always enable logging for Express, especially asynchronous mode.
Using synchronous Express for fire-and-forget scenarios, causing unnecessary waiting and higher costs due to retries.
What SAA-C03 Tests
The exam tests your ability to choose the correct workflow type based on requirements. Specifically, you must know: - Maximum execution duration: Standard up to 1 year, Express up to 5 minutes. - Execution semantics: Standard exactly-once, Express at-least-once (synchronous) or at-most-once (asynchronous). - Pricing model: Standard per transition, Express per execution + duration + memory. - Use cases: Long-running, auditable → Standard; high-volume, short-duration → Express.
Common Wrong Answers
"Use Express because it's cheaper" – This is often wrong because Express can be more expensive for long-running or low-volume workflows due to duration billing. Candidates forget that Standard charges only per transition, not per time.
"Standard Workflows cannot be used with EventBridge" – False. Both types can be triggered by EventBridge.
"Express Workflows guarantee exactly-once execution" – False. Only Standard guarantees exactly-once. Express synchronous is at-least-once; asynchronous is at-most-once.
"Express Workflows can run for up to 1 year" – False. The limit is 5 minutes.
Key Numbers for the Exam
Standard max duration: 1 year (31,536,000 seconds)
Express max duration: 5 minutes (300 seconds)
Standard pricing: $0.025 per 1,000 state transitions
Express pricing: $1.00 per 1 million executions, plus $0.0000166667 per GB-second
Express memory range: 64 MB to 256 MB (billed in 1 MB increments)
Standard state transition rate: ~1,000 per second (soft limit)
Express state transition rate: ~100,000 per second (soft limit)
Edge Cases
Workflow that sometimes exceeds 5 minutes: You cannot use Express. You must use Standard or redesign the workflow to fit within 5 minutes.
Need for exactly-once execution with high volume: You must use Standard, but be aware of the lower throughput. Consider sharding or multiple state machines.
Combining both types: You can nest an Express Workflow inside a Standard Workflow (using a Task state that invokes the Express workflow). This is a common pattern for hybrid needs.
How to Eliminate Wrong Answers
If the question mentions "audit trail," "execution history," or "long-running" → Standard.
If it mentions "high throughput," "sub-second latency," or "event-driven" → Express.
If it mentions "exactly-once" → Standard (unless synchronous Express with retries, but that's still at-least-once).
If cost is a concern, calculate: For high volume (millions of executions) and short duration (<1 second), Express is cheaper. For low volume and long duration, Standard is cheaper.
Standard Workflows can run up to 1 year; Express Workflows up to 5 minutes.
Standard Workflows guarantee exactly-once execution; Express does not.
Standard pricing is per state transition; Express pricing is per execution, duration, and memory.
Express Workflows support synchronous (at-least-once) and asynchronous (at-most-once) modes.
Standard Workflows are ideal for long-running, auditable processes; Express for high-throughput, short-lived tasks.
You cannot change a workflow's type after creation; you must create a new state machine.
For high-volume, short workflows (<1 second), Express is typically cheaper; for low-volume, long workflows, Standard is cheaper.
Express Workflows can be nested inside Standard Workflows for hybrid use cases.
CloudWatch Logs must be explicitly configured for Express Workflows to capture execution results.
The SAA-C03 exam tests the trade-offs between durability, duration, and cost.
Common wrong answer: 'Express is always cheaper' – ignore duration and memory costs.
These come up on the exam all the time. Here's how to tell them apart.
Standard Workflow
Maximum execution duration: 1 year
Pricing: per state transition ($0.025/1,000 transitions)
Execution semantics: exactly-once
State transition rate: ~1,000 per second (soft limit)
Execution history: persisted for up to 90 days (CloudWatch) or S3
Express Workflow
Maximum execution duration: 5 minutes
Pricing: per execution ($1.00/1M) + per duration and memory ($0.0000166667/GB-second)
Execution semantics: at-least-once (sync) or at-most-once (async)
State transition rate: ~100,000 per second (soft limit)
Execution history: not persisted by default; only final results if logging configured
Mistake
Express Workflows are always cheaper than Standard Workflows.
Correct
False. Express charges per execution duration and memory. For long-running workflows (even under 5 minutes), Standard can be cheaper because it charges only per state transition, not per time. For example, a workflow with 10 transitions running for 4 minutes: Standard cost = 10 * $0.025/1000 = $0.00025; Express cost = $1.00/1,000,000 executions + (240 seconds * 64 MB * $0.0000166667/GB-second) ≈ $0.000001 + $0.000256 = $0.000257. In this case, Express is slightly more expensive. For very short workflows, Express is cheaper.
Mistake
Standard Workflows can only be invoked synchronously.
Correct
False. Standard Workflows are always asynchronous from the caller's perspective. When you call `start-execution`, it returns immediately with an execution ARN. The caller does not wait for the workflow to complete. To get the result, you must poll or use a callback pattern. Express Workflows offer both synchronous and asynchronous modes.
Mistake
Express Workflows support exactly-once execution.
Correct
False. Express Workflows do not guarantee exactly-once execution. Synchronous mode provides at-least-once (a state may be retried), and asynchronous mode provides at-most-once (if a failure occurs after partial execution, the workflow may not complete). Only Standard Workflows guarantee exactly-once execution.
Mistake
You can change a Standard Workflow to Express later.
Correct
False. The workflow type is set at creation and cannot be changed. You must create a new state machine with the desired type and update your application to use the new ARN.
Mistake
Both workflow types have the same execution history retention.
Correct
False. Standard Workflows retain execution history in CloudWatch Logs for up to 90 days and can be exported to S3. Express Workflows do not retain history by default; you must explicitly configure logging to CloudWatch or S3 to capture final results and errors.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Standard Workflows are designed for long-running, durable, and auditable processes. They can run up to 1 year, guarantee exactly-once execution, and persist execution history. Express Workflows are optimized for high-volume, short-lived tasks (max 5 minutes), with lower per-execution cost but no exact-once guarantee. Standard charges per state transition; Express charges per execution, duration, and memory. Choose Standard for workflows that need full history and reliability; choose Express for high-throughput, event-driven scenarios.
No. Express Workflows have a hard limit of 5 minutes (300 seconds). If your workflow exceeds this, it will be throttled and fail. You must use a Standard Workflow for longer durations. To work around this, you can break a long workflow into multiple Express workflows chained together, or use a Standard Workflow to orchestrate Express workflows for sub-tasks.
Express Workflows are generally cheaper for high-volume, short-duration workloads because they charge per execution rather than per state transition. For example, processing millions of events per second with sub-second workflows is much more cost-effective with Express. However, you must consider memory and duration costs. Standard Workflows would be prohibitively expensive due to the high number of state transitions.
It depends on the mode. Synchronous Express Workflows support automatic retries on transient errors, similar to Standard. Asynchronous Express Workflows do not retry; if a state fails, the execution fails and the error is logged (if logging is configured). For exactly-once behavior, you must use Standard Workflows.
You must explicitly configure logging. When creating or updating the state machine, set `loggingConfiguration` to include `CLOUDWATCH_LOGS` or `S3`. This will log final execution results and errors. Note that intermediate state transitions are not logged; only the input, output, and error of the entire execution are recorded.
No. Express Workflows do not guarantee exactly-once execution. Synchronous mode provides at-least-once (some states may be retried), and asynchronous mode provides at-most-once (some states may not execute if failure occurs). For exactly-once, you must use Standard Workflows.
Express Workflows support memory from 64 MB to 256 MB, billed in 1 MB increments. The memory is used for the execution context. Standard Workflows do not have a memory parameter; they are billed per state transition.
You've just covered Step Functions Express vs Standard Workflows Cost — now see how well it sticks with free SAA-C03 practice questions. Full explanations included, no account needed.
Done with this chapter?