# AWS Step Functions

> Use when working with Aws Step Functions — aWS Step Functions execution analysis, state machine management, error tracking, and performance optimization. Covers execution history, failure investigation, state transition metrics, Express vs Standard comparison, and workflow visualization.

- Skill: `cloudthinker-ai/aws-step-functions` (Agent Skill)
- Install (CLI): `npx skillmds@latest add cloudthinker-ai/aws-step-functions`
- Raw SKILL.md: https://api.skillmd.com/api/skills/cloudthinker-ai/aws-step-functions/raw
- Safety review: pending (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: DevOps & Infra
- Author: cloudthinker-ai (https://skillmd.com/u/cloudthinker-ai)
- Updated: 2026-09-08
- Page: https://skillmd.com/skills/cloudthinker-ai/aws-step-functions

---


# AWS Step Functions Skill

Analyze AWS Step Functions state machines with parallel execution and anti-hallucination guardrails.

**Relationship to other AWS skills:**

- `aws-step-functions/` → Step Functions-specific analysis (state machines, executions, errors)
- `aws/` → "How to execute" (parallel patterns, throttling, output format)

## CRITICAL: Parallel Execution Requirement

**ALL independent operations MUST run in parallel using background jobs (&) and wait.**

```bash
#!/bin/bash
export AWS_PAGER=""

for sm_arn in $state_machines; do
  get_execution_history "$sm_arn" &
done
wait
```

## Helper Functions

```bash
#!/bin/bash
export AWS_PAGER=""

# List all state machines
list_state_machines() {
  aws stepfunctions list-state-machines \
    --output text \
    --query 'stateMachines[].[stateMachineArn,name,type,creationDate]'
}

# Get state machine details
describe_state_machine() {
  local sm_arn=$1
  aws stepfunctions describe-state-machine --state-machine-arn "$sm_arn" \
    --output text \
    --query '[name,status,type,creationDate,loggingConfiguration.level,tracingConfiguration.enabled]'
}

# List recent executions
list_executions() {
  local sm_arn=$1 status=${2:-""}
  local status_filter=""
  [ -n "$status" ] && status_filter="--status-filter $status"
  aws stepfunctions list-executions --state-machine-arn "$sm_arn" $status_filter \
    --max-results 20 \
    --output text \
    --query 'executions[].[executionArn,name,status,startDate,stopDate]'
}

# Get execution details
describe_execution() {
  local exec_arn=$1
  aws stepfunctions describe-execution --execution-arn "$exec_arn" \
    --output text \
    --query '[name,status,startDate,stopDate,error,cause]'
}

# Get execution history (last N events)
get_execution_events() {
  local exec_arn=$1 max=${2:-20}
  aws stepfunctions get-execution-history --execution-arn "$exec_arn" \
    --max-results "$max" --reverse-order \
    --output text \
    --query 'events[].[timestamp,type,id]'
}
```

## Common Operations

### 1. State Machine Inventory

```bash
#!/bin/bash
export AWS_PAGER=""
aws stepfunctions list-state-machines \
  --output text \
  --query 'stateMachines[].[name,type,creationDate]' | sort -k2
```

### 2. Execution Success/Failure Summary

```bash
#!/bin/bash
export AWS_PAGER=""
SMS=$(aws stepfunctions list-state-machines --output text --query 'stateMachines[].stateMachineArn')
for sm in $SMS; do
  {
    name=$(echo "$sm" | sed 's|.*:||')
    running=$(aws stepfunctions list-executions --state-machine-arn "$sm" --status-filter RUNNING --max-results 100 --output text --query 'length(executions)')
    succeeded=$(aws stepfunctions list-executions --state-machine-arn "$sm" --status-filter SUCCEEDED --max-results 100 --output text --query 'length(executions)')
    failed=$(aws stepfunctions list-executions --state-machine-arn "$sm" --status-filter FAILED --max-results 100 --output text --query 'length(executions)')
    printf "%s\tRunning:%s\tSucceeded:%s\tFailed:%s\n" "$name" "$running" "$succeeded" "$failed"
  } &
done
wait
```

### 3. Failed Execution Investigation

```bash
#!/bin/bash
export AWS_PAGER=""
SM_ARN=$1
FAILED=$(aws stepfunctions list-executions --state-machine-arn "$SM_ARN" \
  --status-filter FAILED --max-results 10 \
  --output text --query 'executions[].executionArn')
for exec_arn in $FAILED; do
  aws stepfunctions describe-execution --execution-arn "$exec_arn" \
    --output text \
    --query '[name,status,startDate,stopDate,error,cause]' &
done
wait
```

### 4. Execution Duration Analysis

```bash
#!/bin/bash
export AWS_PAGER=""
SM_ARN=$1
END=$(date -u +"%Y-%m-%dT%H:%M:%S")
START=$(date -u -d "7 days ago" +"%Y-%m-%dT%H:%M:%S" 2>/dev/null || date -u -v-7d +"%Y-%m-%dT%H:%M:%S")
aws cloudwatch get-metric-statistics \
  --namespace AWS/States --metric-name ExecutionTime \
  --dimensions Name=StateMachineArn,Value="$SM_ARN" \
  --start-time "$START" --end-time "$END" \
  --period 86400 --statistics Average Maximum Minimum \
  --output text --query 'Datapoints[*].[Timestamp,Average,Maximum,Minimum]' | sort -k1
```

### 5. Execution Metrics Overview

```bash
#!/bin/bash
export AWS_PAGER=""
SMS=$(aws stepfunctions list-state-machines --output text --query 'stateMachines[].stateMachineArn')
END=$(date -u +"%Y-%m-%dT%H:%M:%S")
START=$(date -u -d "7 days ago" +"%Y-%m-%dT%H:%M:%S" 2>/dev/null || date -u -v-7d +"%Y-%m-%dT%H:%M:%S")
for sm in $SMS; do
  {
    name=$(echo "$sm" | sed 's|.*:||')
    started=$(aws cloudwatch get-metric-statistics \
      --namespace AWS/States --metric-name ExecutionsStarted \
      --dimensions Name=StateMachineArn,Value="$sm" \
      --start-time "$START" --end-time "$END" \
      --period 604800 --statistics Sum \
      --output text --query 'Datapoints[0].Sum')
    failed=$(aws cloudwatch get-metric-statistics \
      --namespace AWS/States --metric-name ExecutionsFailed \
      --dimensions Name=StateMachineArn,Value="$sm" \
      --start-time "$START" --end-time "$END" \
      --period 604800 --statistics Sum \
      --output text --query 'Datapoints[0].Sum')
    printf "%s\tStarted:%s\tFailed:%s\n" "$name" "${started:-0}" "${failed:-0}"
  } &
done
wait
```

## Anti-Hallucination Rules

1. **Standard vs Express** - Standard workflows record full execution history and are billed per state transition. Express workflows are billed by duration and do not retain history in the API (use CloudWatch Logs).
2. **Execution history limits** - Standard workflow execution history is limited to 25,000 events. Express workflows log to CloudWatch only.
3. **list-executions pagination** - Results are paginated and ordered by start date descending. The `--max-results` parameter caps at 100 per page.
4. **Error vs Cause** - `error` is the error code (e.g., States.TaskFailed). `cause` is the detailed message. Both may be null for non-error terminations.
5. **CloudWatch metrics namespace** - Step Functions uses `AWS/States`, not `AWS/StepFunctions`.

## Output Format

Present results as a structured report:
```
Aws Step Functions Report
═════════════════════════
Resources discovered: [count]

Resource       Status    Key Metric    Issues
──────────────────────────────────────────────
[name]         [ok/warn] [value]       [findings]

Summary: [total] resources | [ok] healthy | [warn] warnings | [crit] critical
Action Items: [list of prioritized findings]
```

Target ≤50 lines of output. Use tables for multi-resource comparisons.

## Counter-Rationalizations

| Shortcut | Counter | Why |
|----------|---------|-----|
| "I'll skip discovery and check known resources" | Always run Phase 1 discovery first | Resource names change, new resources appear — assumed names cause errors |
| "The user only asked for a quick check" | Follow the full discovery → analysis flow | Quick checks miss critical issues; structured analysis catches silent failures |
| "Default configuration is probably fine" | Audit configuration explicitly | Defaults often leave logging, security, and optimization features disabled |
| "Metrics aren't needed for this" | Always check relevant metrics when available | API/CLI responses show current state; metrics reveal trends and intermittent issues |
| "I don't have access to that" | Try the command and report the actual error | Assumed permission failures prevent useful investigation; actual errors are informative |

## Common Pitfalls

- **Express workflow history**: Express executions cannot be described via `describe-execution` after completion. Use CloudWatch Logs Insights to analyze them.
- **ARN format**: State machine ARNs and execution ARNs have different formats. Do not construct execution ARNs manually.
- **Concurrent execution limits**: Default is 1,000,000 open executions per account per region. Express workflows have a 100,000 concurrent execution limit.
- **CloudWatch statistics syntax**: Use spaces not commas: `--statistics Average Maximum`.
- **Map state parallelism**: Map states run iterations in parallel by default. Use `MaxConcurrency` to control. Failures in map iterations may not fail the entire execution depending on error handling.