cloudthinker-ai 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.
#!/bin/bash
export AWS_PAGER=""
for sm_arn in $state_machines; do
get_execution_history "$sm_arn" &
done
wait
Helper Functions
#!/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
#!/bin/bash
export AWS_PAGER=""
aws stepfunctions list-state-machines \
--output text \
--query 'stateMachines[].[name,type,creationDate]' | sort -k2
2. Execution Success/Failure Summary
#!/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
#!/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
#!/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
#!/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
- 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).
- Execution history limits - Standard workflow execution history is limited to 25,000 events. Express workflows log to CloudWatch only.
- list-executions pagination - Results are paginated and ordered by start date descending. The
--max-resultsparameter caps at 100 per page. - Error vs Cause -
erroris the error code (e.g., States.TaskFailed).causeis the detailed message. Both may be null for non-error terminations. - CloudWatch metrics namespace - Step Functions uses
AWS/States, notAWS/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-executionafter 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
MaxConcurrencyto control. Failures in map iterations may not fail the entire execution depending on error handling.