DocumentDB Cluster Not Exporting Logs to CloudWatch

Amazon DocumentDB is a managed document database that speaks the MongoDB API. Like most managed databases, it runs the engine for you and hides the underlying instances, which means the only practical window into what is happening inside the database is the logs it chooses to surface. If your cluster is not configured to export those logs to CloudWatch, that window is closed.

The docdb_logexport check looks at each DocumentDB cluster and verifies whether log exports to CloudWatch Logs are enabled. When they are not, you have no durable record of authentication events, slow queries, or administrative actions. That gap tends to go unnoticed until the day you actually need the data, which is usually the worst possible time to discover it is missing.

---

What this check detects

The check inspects the EnabledCloudwatchLogsExports attribute on every DocumentDB cluster in the account and region. DocumentDB supports two log types for export:

• audit — records authentication attempts, DDL operations, user management, and other security-relevant events.
• profiler — records slow operations based on a configurable execution-time threshold, useful for performance and abuse analysis.

If the cluster has neither log type listed in EnabledCloudwatchLogsExports, the check fails. A cluster passes once at least one log type (typically audit) is being exported.

---

Why it matters

Logs are the evidence trail for a database. Without them, you are guessing.

You lose your forensic baseline

Say a credential leaks and an attacker connects to your DocumentDB cluster using a valid application user. With audit logging exported to CloudWatch, you can see the connection source, the authentication event, and the operations that followed. Without it, you have no record that the connection ever happened. Incident response turns into speculation, and you cannot scope the breach or prove what data was touched.

Compliance frameworks expect database audit trails

PCI DSS, HIPAA, SOC 2, and most internal security standards require audit logging on systems that store sensitive data, along with retention and tamper resistance. CloudWatch Logs gives you a durable, access-controlled destination with retention policies. A DocumentDB cluster with no exported logs will fail an audit on this control alone.

Performance problems stay invisible

The profiler log captures operations that exceed a latency threshold. Those slow queries are often the same ones that get abused for denial-of-service style load or that signal a missing index. Without profiler export, you find out about them through customer complaints rather than dashboards.

---

How to fix it

There are two pieces: enable the export on the cluster, and make sure the parameter group actually produces the logs.

Step 1: Turn on log generation in the parameter group

DocumentDB clusters reference a cluster parameter group. If yours uses the default group, create a custom one first, since the default cannot be edited.

aws docdb create-db-cluster-parameter-group \
  --db-cluster-parameter-group-name docdb-audit-enabled \
  --db-parameter-group-family docdb5.0 \
  --description "DocumentDB parameter group with audit and profiler enabled"

aws docdb modify-db-cluster-parameter-group \
  --db-cluster-parameter-group-name docdb-audit-enabled \
  --parameters \
    "ParameterName=audit_logs,ParameterValue=enabled,ApplyMethod=pending-reboot" \
    "ParameterName=profiler,ParameterValue=enabled,ApplyMethod=pending-reboot" \
    "ParameterName=profiler_threshold_ms,ParameterValue=100,ApplyMethod=pending-reboot"

Confirm the engine family matches your cluster version. Run aws docdb describe-db-engine-versions if you are unsure which family string to use.

Step 2: Attach the parameter group and enable the export

aws docdb modify-db-cluster \
  --db-cluster-identifier my-docdb-cluster \
  --db-cluster-parameter-group-name docdb-audit-enabled \
  --cloudwatch-logs-export-configuration '{"EnableLogTypes":["audit","profiler"]}' \
  --apply-immediately

Then reboot each instance in the cluster so the parameter changes apply:

aws docdb reboot-db-instance --db-instance-identifier my-docdb-instance-1

Verify the export

aws docdb describe-db-clusters \
  --db-cluster-identifier my-docdb-cluster \
  --query 'DBClusters[0].EnabledCloudwatchLogsExports'

You should see ["audit","profiler"] returned. Within a few minutes a log group named /aws/docdb/<cluster-id>/audit will appear in CloudWatch Logs and begin receiving events.

Doing it in the console

1. Open the Amazon DocumentDB console and select your cluster.
2. Choose Modify.
3. Under Log exports, check Audit logs and Profiler logs.
4. Set the cluster parameter group to one where audit_logs and profiler are enabled.
5. Apply the change, choosing immediate or next maintenance window, then reboot the instances.

---

How to prevent it from happening again

Fixing one cluster by hand does not stop the next one from being created without logging. Bake the setting into the way clusters are provisioned.

Terraform

resource "aws_docdb_cluster_parameter_group" "audit" {
  family      = "docdb5.0"
  name        = "docdb-audit-enabled"
  description = "Audit and profiler enabled"

  parameter {
    name         = "audit_logs"
    value        = "enabled"
    apply_method = "pending-reboot"
  }
  parameter {
    name         = "profiler"
    value        = "enabled"
    apply_method = "pending-reboot"
  }
  parameter {
    name         = "profiler_threshold_ms"
    value        = "100"
    apply_method = "pending-reboot"
  }
}

resource "aws_docdb_cluster" "main" {
  cluster_identifier              = "my-docdb-cluster"
  engine                          = "docdb"
  master_username                 = var.master_username
  master_password                 = var.master_password
  db_cluster_parameter_group_name = aws_docdb_cluster_parameter_group.audit.name
  enabled_cloudwatch_logs_exports = ["audit", "profiler"]
  storage_encrypted               = true
}

With enabled_cloudwatch_logs_exports set in the module, every cluster your team stands up inherits logging by default.

CloudFormation

{
  "Type": "AWS::DocDB::DBCluster",
  "Properties": {
    "DBClusterIdentifier": "my-docdb-cluster",
    "DBClusterParameterGroupName": "docdb-audit-enabled",
    "EnableCloudwatchLogsExports": ["audit", "profiler"],
    "StorageEncrypted": true
  }
}

Policy as code in CI

Catch the misconfiguration before it merges. An Open Policy Agent (Conftest) rule against Terraform plan output works well:

package main

deny[msg] {
  resource := input.resource_changes[_]
  resource.type == "aws_docdb_cluster"
  exports := resource.change.after.enabled_cloudwatch_logs_exports
  not exports
  msg := sprintf("DocumentDB cluster '%s' must export logs to CloudWatch", [resource.address])
}

deny[msg] {
  resource := input.resource_changes[_]
  resource.type == "aws_docdb_cluster"
  exports := resource.change.after.enabled_cloudwatch_logs_exports
  count(exports) == 0
  msg := sprintf("DocumentDB cluster '%s' has empty log exports", [resource.address])
}

---

Best practices

• Always export audit logs. Treat it as a non-negotiable default for any DocumentDB cluster that touches real data, not an optional extra.
• Set retention deliberately. Match the CloudWatch Logs retention period to your compliance obligations, then archive to S3 if you need cheaper long-term storage.
• Tune the profiler threshold. Too low and you flood CloudWatch with noise and cost. Too high and you miss real slow queries. Start around 100ms and adjust based on your workload.
• Lock down log access. Audit logs contain sensitive operational detail. Scope IAM permissions on the log groups so only your security and operations teams can read them, and consider a separate KMS key for encryption.
• Build alarms on top of the logs. Exporting logs is the foundation. Add CloudWatch metric filters and alarms for repeated authentication failures or spikes in profiler entries so the data drives action instead of sitting idle.
• Enable encryption at rest as well. Logging answers the question of who did what. Encryption protects the data itself. They are complementary controls, so do not stop at one.

Enabling log export is a small, low-risk change with an outsized payoff. The cost is a few CLI commands and a maintenance-window reboot. The benefit is that when something goes wrong, you have the evidence to understand it instead of a silent cluster and a lot of unanswerable questions.