Overview
Avoid idle wait time charges by using Step Functions for orchestration.
Problem with Lambda Orchestration
Lambda charges for entire duration, including wait times:
// Lambda orchestrator (expensive)
exports.handler = async (event) => {
await processStep1(); // Wait until step1 is complete. This time is billed.
await processStep2(); // Wait until step2 is complete. This time is billed.
};
This diagram illustrates the anti-pattern of invoking Lambdas from other Lambdas, where the orchestrating function spends much of its time waiting on downstream work and external services but is still fully billed for that idle duration.
Cost: Charged for all time spent waiting on other Lambdas to complete.
Step Functions Solution
Pay per state transition, not duration:
{
"StartAt": "ProcessStep1",
"States": {
"ProcessStep1": {
"Type": "Task",
"Resource": "arn:aws:lambda:...:function:step1",
"Next": "Wait5Minutes"
},
"Wait5Minutes": {
"Type": "Wait",
"Seconds": 300,
"Next": "ProcessStep2"
},
"ProcessStep2": {
"Type": "Task",
"Resource": "arn:aws:lambda:...:function:step2",
"End": true
}
}
}
Cost: Only charged for Lambda execution time, not wait states
Additional Benefits
- Supports workflows >15 minutes (Lambda limit)
- Built-in retries and error handling
- Visual workflow monitoring
- 200+ AWS service integrations, so many steps can call AWS services directly (for example, DynamoDB, SNS, SQS, or EventBridge) instead of invoking a “proxy” Lambda
Pricing
- Standard Workflows: Billed per state transition (for example, $0.025 per 1,000 transitions) and optimized for long-running, durable workflows.
- Express Workflows: Billed per request and duration, optimized for high-throughput, short-lived workflows.
- Both are usually much cheaper than burning Lambda time on idle waits and orchestration logic.
When to Use
✓ Workflows with wait times
✓ Complex orchestration
✓ Long-running processes
✓ Retry logic needed