RDS Cluster - consider enabling CloudWatch log exports

Enabling CloudWatch log exports on an Amazon RDS cluster means setting the enabled_cloudwatch_logs_exports attribute on the aws_rds_cluster Terraform resource so the cluster streams its audit, error, general, or slow query logs into Amazon CloudWatch Logs automatically. Without this attribute set, cluster logs stay on local instance storage, which slows down incident diagnosis and leaves audit and compliance requirements unmet. This policy applies to any Aurora MySQL or Aurora PostgreSQL cluster where a team needs centralized, queryable log history for monitoring, auditing, or incident response.

Policy at a Glance

Why This Policy Matters

How It Helps Reduce Cloud Costs

This policy does not reduce Aurora or RDS compute spend directly. It trades a small, predictable CloudWatch charge for a much larger, unpredictable one: the engineer time spent reconstructing what happened during an incident from logs that were never captured centrally.

A platform engineer troubleshooting a production Aurora cluster without exported logs has to connect to each instance individually, if local log access is even possible, and piece together a timeline after the fact. This is a common source of extended incident response time. Centralized log export removes that step entirely.

Compliance frameworks that require audit trail retention, such as SOC 2 or PCI DSS, generally expect database audit logs to exist somewhere durable and queryable. A cluster with no enabled_cloudwatch_logs_exports configuration frequently becomes an audit finding on its own, regardless of how the database itself is configured.

Potential Savings

Teams commonly report that incident diagnosis without centralized logs takes multiple engineer-hours longer than diagnosis with logs already available in CloudWatch Logs Insights. These figures vary by organization and should be treated as illustrative, not as a guaranteed savings for any specific incident.

Enabling log exports at cluster creation, rather than after an incident forces the issue, also avoids the retroactive work of backfilling audit evidence for a compliance review. Teams that enforce this in a shared Terraform module report zero missing-log-export findings across new Aurora clusters, a concrete and trackable metric for engineering leadership.

Implementation Guide

Infrastructure-as-Code Example (Terraform)

The following examples show an Aurora MySQL cluster with no log export configured, and the corrected version.

Non-compliant configuration: enabled_cloudwatch_logs_exports not set.

resource "aws_rds_cluster" "orders" {
  cluster_identifier = "orders-cluster"
  engine             = "aurora-mysql"
  engine_version     = "8.0.mysql_aurora.3.05.2"
  master_username    = "admin"
  manage_master_user_password = true
  database_name      = "orders"

  # enabled_cloudwatch_logs_exports not set, no logs are exported
}

resource "aws_rds_cluster" "orders" {
  cluster_identifier = "orders-cluster"
  engine             = "aurora-mysql"
  engine_version     = "8.0.mysql_aurora.3.05.2"
  master_username    = "admin"
  manage_master_user_password = true
  database_name      = "orders"

  # enabled_cloudwatch_logs_exports not set, no logs are exported
}

resource "aws_rds_cluster" "orders" {
  cluster_identifier = "orders-cluster"
  engine             = "aurora-mysql"
  engine_version     = "8.0.mysql_aurora.3.05.2"
  master_username    = "admin"
  manage_master_user_password = true
  database_name      = "orders"

  # enabled_cloudwatch_logs_exports not set, no logs are exported
}

With no value set, the cluster generates logs locally but never ships them to CloudWatch. This is a common source of blind spots during an incident, since nobody notices the gap until the logs are actually needed.

Compliant configuration: audit, error, general, and slow query logs exported.

resource "aws_rds_cluster" "orders" {
  cluster_identifier = "orders-cluster"
  engine             = "aurora-mysql"
  engine_version     = "8.0.mysql_aurora.3.05.2"
  master_username    = "admin"
  manage_master_user_password = true
  database_name      = "orders"

  enabled_cloudwatch_logs_exports = ["audit", "error", "general", "slowquery"]
}

resource "aws_cloudwatch_log_group" "orders_slowquery" {
  name              = "/aws/rds/cluster/orders-cluster/slowquery"
  retention_in_days = 30
}

resource "aws_rds_cluster" "orders" {
  cluster_identifier = "orders-cluster"
  engine             = "aurora-mysql"
  engine_version     = "8.0.mysql_aurora.3.05.2"
  master_username    = "admin"
  manage_master_user_password = true
  database_name      = "orders"

  enabled_cloudwatch_logs_exports = ["audit", "error", "general", "slowquery"]
}

resource "aws_cloudwatch_log_group" "orders_slowquery" {
  name              = "/aws/rds/cluster/orders-cluster/slowquery"
  retention_in_days = 30
}

resource "aws_rds_cluster" "orders" {
  cluster_identifier = "orders-cluster"
  engine             = "aurora-mysql"
  engine_version     = "8.0.mysql_aurora.3.05.2"
  master_username    = "admin"
  manage_master_user_password = true
  database_name      = "orders"

  enabled_cloudwatch_logs_exports = ["audit", "error", "general", "slowquery"]
}

resource "aws_cloudwatch_log_group" "orders_slowquery" {
  name              = "/aws/rds/cluster/orders-cluster/slowquery"
  retention_in_days = 30
}

Setting enabled_cloudwatch_logs_exports streams the listed log types to CloudWatch Logs automatically once the cluster is created or modified. Pairing it with an explicit aws_cloudwatch_log_group resource keeps storage cost in check, since RDS-created log groups default to indefinite retention.

Step-by-Step Fix Instructions

1. List every aws_rds_cluster resource in Terraform state or configuration and check whether enabled_cloudwatch_logs_exportsis set.

2. Identify the cluster's engine, since valid log types differ: Aurora MySQL supports audit, error, general, instance, and slowquery; Aurora PostgreSQL supports instance and postgresql.

3. Add enabled_cloudwatch_logs_exports with the log types relevant to the workload. Enable audit only if the workload has a compliance requirement for it, since audit logs are typically the highest-volume log type.

4. Run terraform plan to confirm the change applies without replacing the cluster.

5. Apply the change and confirm in the CloudWatch console that new log groups appear under /aws/rds/cluster/<cluster-identifier>/<log-type>.

6. Add an explicit aws_cloudwatch_log_group resource with retention_in_days set for each exported log type, since RDS creates these log groups with no expiration by default.

7. Add Infracost to CI/CD so any future aws_rds_cluster resource missing this attribute gets flagged before merge.

Best Practices

• Set enabled_cloudwatch_logs_exports as a default in the shared Terraform module used to provision Aurora clusters, rather than relying on each team to remember it.

• Match log types to the engine. Requesting a log type the engine does not support, such as slowquery on an Aurora PostgreSQL cluster, fails at terraform apply.

• Always pair this policy with an explicit retention_in_days value on the resulting log groups. Enabling exports without retention control turns one cost blind spot into another.

• This policy does not apply to workloads that already ship logs through a separate mechanism, such as a sidecar log forwarder, provided that mechanism meets the same audit and access requirements.

Tools and Scripts

How does Infracost detect this automatically?

Infracost supports this policy check in its free trial and paid plans. When Infracost runs in CI/CD, it evaluates aws_rds_cluster resources introduced or modified in a pull request and flags any cluster where enabled_cloudwatch_logs_exports is missing or empty, surfacing the finding as a warning in the PR comment before the code merges.

This gives platform teams a pre-deploy signal instead of discovering the gap mid-incident, when the logs needed to diagnose it were never being captured in the first place. Infracost enables teams to track how many clusters are missing log exports over time, supporting a gradual burn-down of this finding instead of a single audit-driven cleanup.

To check which existing clusters are missing log exports using the AWS CLI:

aws rds describe-db-clusters \
  --query "DBClusters[].{Cluster:DBClusterIdentifier,Logs:EnabledCloudwatchLogsExports}" \
  --output

aws rds describe-db-clusters \
  --query "DBClusters[].{Cluster:DBClusterIdentifier,Logs:EnabledCloudwatchLogsExports}" \
  --output

aws rds describe-db-clusters \
  --query "DBClusters[].{Cluster:DBClusterIdentifier,Logs:EnabledCloudwatchLogsExports}" \
  --output

Examples of Impact

Illustrative example: diagnosing a slow query incident. A platform team investigating an Aurora MySQL performance issue has no slow query log export configured. Engineers connect to each cluster instance individually to pull local logs, losing hours before finding the query at fault. After enabling enabled_cloudwatch_logs_exports with slowquery, the same investigation becomes a CloudWatch Logs Insights query that returns results in minutes.

Illustrative example: a compliance gap surfaced before an audit. A team preparing for a SOC 2 review discovers that an Aurora PostgreSQL cluster handling customer data has never exported its logs, since enabled_cloudwatch_logs_exports was never set on the resource. Enabling postgresql log export ahead of the audit closes the finding proactively rather than during the review itself.

(These are illustrative, composite scenarios, not specific customer accounts.)

Considerations and Caveats

• Log type support depends on engine. Aurora MySQL supports audit, error, general, instance, and slowquery. Aurora PostgreSQL supports instance and postgresql. The upgrade log type is valid for standalone RDS for PostgreSQL instances, not for Aurora PostgreSQL clusters. Requesting an unsupported type for the cluster's engine fails at apply time.

• Audit logging has a separate switch. Exporting the audit log type requires audit logging to be enabled at the engine level through a DB cluster parameter group. Setting enabled_cloudwatch_logs_exports alone does not turn on audit logging if the parameter group has it disabled.

• Log groups default to indefinite retention. Without a matching aws_cloudwatch_log_group resource and an explicit retention_in_days value, exported log storage accumulates cost with no expiration.

• Not retroactive for pre-existing log groups. If a log group already exists outside Terraform's management with its own retention setting, adding this attribute does not change that existing configuration.

• This policy does not apply to workloads with an equivalent logging pipeline already in place, such as a sidecar forwarder shipping logs to a different destination that meets the same audit requirements.

Related Policies and Concepts

• RDS - consider upgrading gp2 storage type to gp3: another Compute-group RDS policy that changes a single Terraform attribute for a meaningful operational improvement, the same low-effort, high-value pattern this policy follows for log visibility.

• EC2 - require Instance Metadata Service Version 2 (IMDSv2): a similarly compliance-driven FinOps policy where the primary benefit is reduced incident and audit risk rather than direct cost savings.

• PostgreSQL - consider using backup retention in non-production projects: a related RDS/Aurora policy focused on not paying for more data retention than a workload actually needs, the inverse discipline of this policy's retention guidance for log groups.

• Amazon CloudWatch - consider using a retention policy to reduce storage costs: directly relevant once this policy is implemented, since the log groups it creates need their own retention setting to avoid unmanaged storage growth.

Frequently Asked Questions (FAQs)

Is this policy supported in Infracost?

Yes. Infracost evaluates aws_rds_cluster resources in pull requests and flags any cluster where enabled_cloudwatch_logs_exports is missing or empty, so the team can add it before merge. This check is available in the free trial and all paid plans.

Can this policy be customized?

Yes. Teams can adjust the enforcement level for this check in Infracost, choosing whether a missing enabled_cloudwatch_logs_exports attribute blocks the pull request or only warns the engineer, and can customize the message shown in the PR comment.

Does Infracost automatically fix violations?

No. Infracost identifies and reports an aws_rds_cluster resource missing enabled_cloudwatch_logs_exports in a pull request. Adding the attribute, and choosing which log types to export, is a decision the team makes and applies manually.

Is this policy cloud-agnostic?

No. This specific policy targets Amazon Aurora and RDS clusters through the aws_rds_cluster Terraform resource. Azure and Google Cloud have their own database log export mechanisms, but the resource and attribute names differ from AWS's.

How often should I review RDS cluster log export compliance?

Teams running Infracost in CI/CD get a check on every pull request that touches an aws_rds_cluster resource. For clusters already running, review log export configuration on a recurring basis, quarterly is a reasonable cadence for most teams.

Does enabling CloudWatch log exports affect RDS cluster performance?

No. Setting enabled_cloudwatch_logs_exports is a logging configuration change. It does not affect cluster compute, storage performance, or failover behavior. The change does add a CloudWatch ingestion and storage cost proportional to log volume.