Neptune DB clusters should publish audit logs to CloudWatch Logs

Neptune audit logs record every query, connection, and schema operation against the cluster. Without CloudWatch export, that activity is invisible outside the cluster itself, making it hard to investigate suspicious access patterns or correlate database behavior with other events in your environment. CloudWatch integration also unlocks metric filters, alarms, and subscription filters for automated response.

Graph databases are worth singling out here. Neptune often holds relationship data that reveals sensitive structure: fraud rings, identity graphs, supply chains. An attacker who exfiltrates that data or runs unusual traversal patterns won't leave obvious traces unless you're capturing query activity.

Retrofit consideration

Updating an existing Neptune cluster to add "audit" to enable_cloudwatch_logs_exports is straightforward in Terraform, but that only controls where logs go. Whether the cluster actually emits meaningful audit content depends on engine parameters. If you're not using a custom aws_neptune_cluster_parameter_group, the export may flow but carry little useful data until parameter-level logging is also configured.

Implementation

Choose the approach that matches how you manage Terraform.

Terraform resources

Use AWS provider resources directly. See docs for the resources involved: aws_neptune_cluster.

resource "aws_neptune_cluster" "this" {
  backup_retention_period        = 7
  cluster_identifier             = "pofix-abc123"
  enable_cloudwatch_logs_exports = ["audit"]
  neptune_subnet_group_name      = "example-neptune-subnet-group"
  skip_final_snapshot            = true
}

What this control checks

The aws_neptune_cluster resource passes when enable_cloudwatch_logs_exports includes "audit". The argument takes a list; a missing argument, null value, or empty list all fail.

Common pitfalls

Export configuration and log generation are related but distinct
Configuring export and actually generating audit content are two different things. enable_cloudwatch_logs_exports = ["audit"] on aws_neptune_cluster tells Neptune where to send logs, but engine-level and parameter-group settings control what gets written. A cluster can pass this control while producing sparse or empty audit logs if the underlying logging behavior isn't configured to match.
Default parameter group cannot be modified
Neptune's default parameter group is read-only; you can't modify it in place. If you need non-default logging parameters, create a custom aws_neptune_cluster_parameter_group and reference it via neptune_cluster_parameter_group_name. Be aware that swapping parameter groups on a running cluster may trigger a reboot.
CloudWatch log group retention defaults to never expire
Use an explicit aws_cloudwatch_log_group resource for /aws/neptune/<cluster>/audit and set retention_in_days. When Neptune auto-creates the log group, it defaults to never expire, and log volume on active graph databases adds up fast.
Audit log volume can be significant for busy clusters
Every Gremlin traversal and SPARQL query lands in the audit log. On a busy cluster that's gigabytes per day, and CloudWatch Logs charges for both ingestion and storage. Set retention early, and consider subscription filters to route older logs to S3 for cheaper long-term storage.

Audit evidence

Auditors expect AWS Config rule evaluations showing Neptune clusters as COMPLIANT for neptune-cluster-audit-logging-enabled. More importantly, they'll check that the /aws/neptune/<cluster-name>/audit log group exists and contains recent entries, confirming logs are actually flowing, not just configured to flow. Console screenshots of the cluster's Log exports section with Audit checked work as quick visual confirmation. Some auditors will query the log group directly to verify entries fall within the review period.

Framework-specific interpretation

PCI DSS v4.0: For clusters storing or processing cardholder relationship data, Requirement 10 calls for logging all access to system components. Neptune audit logs provide that trail of database interactions, and CloudWatch export ensures they're centralized and available for the retention periods Requirement 10 specifies.

NIST Cybersecurity Framework v2.0: Neptune audit logs fed into CloudWatch are a direct input to DE.CM continuous monitoring and DE.AE anomaly detection. The Detect function expects visibility into what's happening on your systems; exporting query activity and connection events from graph clusters is how you get that for Neptune.

Tool mappings

Use these identifiers to cross-reference this control across tools, reports, and evidence.

Compliance.tf Control: neptune_db_cluster_audit_logging_enabled
AWS Config Managed Rule: NEPTUNE_CLUSTER_CLOUDWATCH_LOG_EXPORT_ENABLED
Checkov Check: CKV_AWS_101
Powerpipe Control: aws_compliance.control.neptune_db_cluster_audit_logging_enabled
Prowler Check: neptune_cluster_integration_cloudwatch_logs
AWS Security Hub Control: Neptune.2
KICS Query: 45cff7b6-3b80-40c1-ba7b-2cf480678bb8
Trivy Check: AWS-0075

Last reviewed: 2026-03-09