# Inefficient Workflow Design in AWS Step Functions

Canonical: https://www.pointfive.co/efficiency-hub/inefficiencies/inefficient-workflow-design-in-aws-step-functions

[Cloud Efficiency Hub](https://www.pointfive.co/efficiency-hub) 

# Inefficient Workflow Design in AWS Step Functions

## Explanation

Improper design choices in AWS Step Functions can lead to unnecessary charges. For example: \* Using  Standard Workflows  for short-lived, high-frequency executions leads to excessive per-transition charges. \* Using  Express Workflows  for long-running processes (close to or exceeding the 5-minute limit) may cause timeouts or retries. \* Inefficient use of states-such as chaining many simple states instead of combining logic into a Lambda function-can increase cost in both workflow types. \* Overuse of payload-passing between states (especially in Express workflows) increases GB-second and data transfer charges.

## Relevant Billing Model

\* \*Standard Workflows:\* Billed per state transition \* \*Express Workflows:\* Billed per invocation, execution duration (in GB-seconds), and data transfer Choosing the wrong workflow type or poorly structuring a workflow (e.g., excessive state transitions) can significantly inflate costs, especially under high execution volumes or when parallel states and payload sizes are not optimized.

## Detection

- Express workflows frequently hit duration or payload limits

- Short-lived workflows are using Standard instead of Express

- The number of state transitions is unusually high relative to the business logic

- Simple sequential logic could be collapsed into a Lambda or intrinsic function

- Map and Parallel states are overused or not optimized

- Input/output payload sizes between states are larger than necessary

## Remediation

- Choose Express workflows for short-lived, high-volume executions

- Use Standard workflows for long-running, infrequent executions

- Combine simple logic steps into a single Lambda or use intrinsic functions

- Use \*ResultPath\*, \*OutputPath\*, and \*Parameters\* fields efficiently to trim payloads

- Minimize use of unnecessary Map or Parallel states where linear processing suffices

- Benchmark costs and execution patterns using AWS Step Functions metrics

## Relevant Documentation

[https://docs.aws.amazon.com/step-functions/latest/dg/concepts-standard-vs-express.html](https://docs.aws.amazon.com/step-functions/latest/dg/concepts-standard-vs-express.html) 
[https://aws.amazon.com/step-functions/pricing/](https://aws.amazon.com/step-functions/pricing/) 
[https://docs.aws.amazon.com/step-functions/latest/dg/best-practices.html](https://docs.aws.amazon.com/step-functions/latest/dg/best-practices.html)

[Submit Feedback](https://hub.pointfive.co/inefficiencies/inefficient-workflow-design-in-aws-step-functions)

## At a glance

Reference

CER-0176

Cloud provider

AWS

Service

AWS Step Functions

Category

[Compute](https://www.pointfive.co/efficiency-hub/service-category/compute)

Inefficiency type

Misconfiguration

## Contributed by

- Jarred Clore 

### Jarred Clore

Cloud FinOps Delivery Leader @ Cisco

[LinkedIn](https://www.linkedin.com/in/jarred-clore/)

---
Source: the public page above. Product screenshots and illustrative interfaces are examples, not live customer data.