AWS Security Hub · Athena
Athena.4: Athena query access is not logged
Written and reviewed by Emnode · Last reviewed
What does AWS Security Hub Athena.4 check?
Athena.4 fails when an Athena workgroup does not have logging enabled, specifically when the workgroup isn't publishing query metrics to CloudWatch. The backing Config rule, athena-workgroup-logging-enabled, reads a single setting and flags the workgroup NON_COMPLIANT when PublishCloudWatchMetricsEnabled is false.
Why does Athena.4 matter?
CloudWatch query metrics are how you see what a workgroup is actually doing: query volume, how many succeed versus fail, queue and execution time, and the bytes each query scans. Without them you're flying blind on a per-workgroup basis: a runaway job scanning terabytes, a spike in failed queries, or a workgroup quietly grinding far more data than it should all go unnoticed until the bill or an incident surfaces them. Publishing these metrics gives you the signals to alarm on cost and anomalous activity, and it's the cheap, intended baseline of observability AWS expects every workgroup to have.
How do I fix Athena.4?
- Inventory workgroups and find those that aren't publishing query metrics to CloudWatch.
- Turn metrics on with update-work-group, setting PublishCloudWatchMetricsEnabled to true, e.g. aws athena update-work-group --work-group <name> --configuration-updates '{"PublishCloudWatchMetricsEnabled": true}'.
- Set EnforceWorkGroupConfiguration so the workgroup configuration overrides client-side settings and users can't turn metrics off per query.
- Once metrics are flowing, build CloudWatch alarms on the per-workgroup signals you care about (data scanned, failed queries, and execution time) so the logging you've enabled actually drives detection.
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-immediatelyFull walkthrough (console steps, edge cases and verification) in the lesson Enable application and API logging.
Is Athena.4 a false positive?
The underlying rule, athena-workgroup-logging-enabled, fails purely on PublishCloudWatchMetricsEnabled being false: it doesn't look at CloudTrail or where your query results land. So a workgroup whose activity is genuinely watched another way can fail while being a deliberate choice: a sandbox or short-lived workgroup that leans on CloudTrail for the API record and skips CloudWatch metrics to avoid the per-workgroup metric cost. A workgroup created with metrics off via the API (rather than the console, which pre-selects the box) lands here too. If you're skipping CloudWatch on purpose and the visibility you need lives elsewhere, document that and suppress the finding rather than enabling metrics you won't use, but confirm first, because for any workgroup you actually rely on, publishing metrics is cheap and is the intended fix.