AWS Security Hub · StepFunctions
StepFunctions.1: State machines should have logging on
Written and reviewed by Emnode · Last reviewed
What does AWS Security Hub StepFunctions.1 check?
StepFunctions.1 checks that a Step Functions state machine has logging enabled. It reports FAILED when a state machine has no LoggingConfiguration, which is the default for Standard workflows.
Why does StepFunctions.1 matter?
How much you lose without logging depends on the workflow type. Express Workflows don't record execution history in Step Functions at all, so with logging off they run dark: there is no record of which state transitioned where or with what payload, making incident investigation guesswork. Standard Workflows do retain full execution history in Step Functions itself (viewable in the console and via the API for up to 90 days), but routing it to CloudWatch Logs is what gives you durable, queryable, longer-lived records for debugging and security auditing across both workflow types.
How do I fix StepFunctions.1?
- Audit which state machines have no LoggingConfiguration.
- Choose a log level: ALL for full visibility, or ERROR/FATAL to capture only failures and reduce volume.
- Grant the state machine's execution role the CloudWatch Logs delivery permissions it needs.
- Enable logging with a non-disruptive update-state-machine call that does not interrupt running executions.
Remediation script · bash
# Verify the prerequisite first: API Gateway's account-level CloudWatch role.
# Without it, the logging setting saves but no logs ever flow.
aws apigateway get-account --query 'cloudwatchRoleArn' --output text
# Enable ERROR-level execution logging on every stage of a REST API.
REST_API=a1b2c3d4e5
for STAGE in $(aws apigateway get-stages --rest-api-id $REST_API \
--query 'item[].stageName' --output text); do
aws apigateway update-stage --rest-api-id $REST_API --stage-name $STAGE \
--patch-operations op=replace,path=/*/*/logging/loglevel,value=ERROR
done
# Cap retention on the log group so storage stays bounded (do this every time you enable logging).
aws logs put-retention-policy \
--log-group-name "API-Gateway-Execution-Logs_${REST_API}/prod" \
--retention-in-days 90
# Example for a managed database: publish engine logs to CloudWatch (no per-event charge).
aws rds modify-db-instance --db-instance-identifier prod-db \
--cloudwatch-logs-export-configuration 'EnableLogTypes=["error","audit"]' --apply-immediately Full walkthrough (console steps, edge cases and verification) in the lesson Enable application and API logging.
Is StepFunctions.1 a false positive?
If you configure the control's `logLevel` parameter to ALL, a state machine that deliberately logs only ERROR or FATAL (a high-volume, well-understood workflow where you cap log spend and noise by capturing failures only) will report FAILED even though its LoggingConfiguration is intentional and present. Standard workflows also already retain full execution history independent of CloudWatch logging, so a Standard state machine you have chosen to run with logging OFF is a deliberate trade-off rather than a workflow running blind. Decide the minimum log level your environment actually requires, set the `logLevel` parameter to match, and suppress the finding for state machines whose lower (or absent) logging is a documented, accepted choice rather than raising every workflow to ALL to clear the control.