Skip to main content
emnode
Sign up
Compliance Medium severity

AWS Security Hub · Opensearch

Opensearch.4: OpenSearch error logging to CW should be enabled

Written and reviewed by Emnode · Last reviewed

What does AWS Security Hub Opensearch.4 check?

Opensearch.4 fails when a domain is not publishing its error logs (the ES_APPLICATION_LOGS log type) to CloudWatch Logs. This is distinct from slow logs and audit logs, and the control checks specifically for the error log destination.

Why does Opensearch.4 matter?

Error logs are where OpenSearch records write rejections, circuit-breaker trips, and mapping failures. Without them, a domain that misbehaves during an incident is undiagnosable: teams end up restarting clusters blind while the real cause stays hidden. Having the error stream in CloudWatch turns a guessing game into a log search.

How do I fix Opensearch.4?

  1. Create a CloudWatch Logs log group with a sensible retention period.
  2. Attach a resource policy granting es.amazonaws.com permission to write to that log group.
  3. Enable the ES_APPLICATION_LOGS publishing option on the domain in place, then verify logs actually arrive.
  4. Bake the same configuration into your domain template so new domains ship with error logging on.

Remediation script · bash

# Enable CloudWatch log export on a flagged RDS instance, then cap retention.
aws rds modify-db-instance \
  --db-instance-identifier prod-orders-pg \
  --cloudwatch-logs-export-configuration EnableLogTypes=postgresql,upgrade \
  --apply-immediately

aws logs put-retention-policy \
  --log-group-name /aws/rds/instance/prod-orders-pg/postgresql \
  --retention-in-days 90

# Enable audit logging on a Redshift cluster to a policy-attached S3 bucket.
aws redshift enable-logging \
  --cluster-identifier analytics-prod \
  --bucket-name redshift-audit-logs-acct123 \
  --s3-key-prefix analytics-prod/

Full walkthrough (console steps, edge cases and verification) in the lesson Enable database audit and log exports.

Is Opensearch.4 a false positive?

A brand-new domain, or one with no application activity, can sit in FAILED even though error logging is correctly turned on: OpenSearch only creates the CloudWatch log stream when it has an actual error log line to write, so a healthy idle cluster never produces the stream the check infers from, and application error logs can take up to about 30 minutes to first appear after you enable them. Re-evaluate after the domain has handled real traffic before treating the finding as real. A deliberate case worth a documented exception is a throwaway dev or scratch domain you intend to delete shortly: suppress the finding in Security Hub with a note and an expiry rather than standing up a log group and resource policy you will never read.

Full lesson Enable database audit and log exports Step-by-step remediation with CLI, code and persona-specific context.
AWS documentation for Opensearch controls ↗ Check your own account for Opensearch.4 →
Part of the learning path Tighten your databases

More Opensearch controls