Skip to content

RDS for MariaDB DB instances should publish logs to CloudWatch Logs

Database logs that never leave the instance are invisible to your security and operations teams. When MariaDB logs ship to CloudWatch Logs, you get centralized search, metric filters for error patterns, and the ability to alarm on suspicious queries or authentication failures. Without this, incident responders have to SSH or connect to the instance directly, which delays triage and may not be possible if the instance is unreachable.

CloudWatch Logs also gives you configurable retention, cross-account sharing via subscription filters, and integration with Logs Insights and OpenSearch. Logs kept only on the RDS instance rotate out on a fixed schedule you cannot extend and are gone entirely if the instance is deleted.

Retrofit consideration

Enabling log exports on an existing instance triggers a modification that can cause a brief connectivity interruption, depending on whether you apply it immediately or defer to the next maintenance window. Enabling the general or audit log also requires parameter group changes, which may require a reboot.

Implementation

Choose the approach that matches how you manage Terraform.

If you use terraform-aws-modules/rds/aws, set the right module inputs for this control. You can later migrate to the compliance.tf module with minimal changes because it is compatible by design.

module "rds" {
  source  = "terraform-aws-modules/rds/aws"
  version = ">=7.0.0"

  allocated_storage      = 20
  db_name                = "myapp"
  db_subnet_group_name   = "example-db-subnet-group"
  engine                 = "mysql"
  engine_version         = "8.0.41"
  family                 = "mysql8.0"
  identifier             = "abc123"
  instance_class         = "db.t3.micro"
  major_engine_version   = "8.0"
  password_wo            = "change-me-in-production"
  skip_final_snapshot    = true
  username               = "dbadmin"
  vpc_security_group_ids = ["sg-12345678"]
}

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

resource "aws_db_instance" "this" {
  allocated_storage               = 20
  enabled_cloudwatch_logs_exports = ["audit", "error", "general", "slowquery"]
  engine                          = "mariadb"
  identifier                      = "pofix-abc123"
  instance_class                  = "db.t3.micro"
  monitoring_interval             = 60
  monitoring_role_arn             = "arn:aws:iam::123456789012:role/example-role"
  password                        = "ChangeMe123!"
  skip_final_snapshot             = true
  username                        = "dbadmin"
}

What this control checks

The aws_db_instance resource must include enabled_cloudwatch_logs_exports with one or more valid MariaDB log types: "audit", "error", "general", or "slowquery". An empty list or omitting the argument entirely fails the control. Setting enabled_cloudwatch_logs_exports = ["audit", "error", "slowquery"] passes.

Note that some log types require matching parameter group settings to produce any output. The audit log requires the MariaDB Audit Plugin enabled via an aws_db_parameter_group with server_audit_logging = 1 and server_audit_events configured. The general log requires general_log = 1. The slowquery log requires slow_query_log = 1. Without these parameter group changes, the export is enabled but the log groups will be empty.

Common pitfalls

  • Audit log requires MariaDB Audit Plugin activation

    Adding "audit" to enabled_cloudwatch_logs_exports does not automatically enable the MariaDB Audit Plugin. You still need an aws_db_parameter_group with server_audit_logging = 1 and server_audit_events set to the desired event types (for example, CONNECT,QUERY,QUERY_DDL). Skip this and the audit log group appears in CloudWatch but stays empty, which looks compliant until someone checks for actual log entries.

  • General and slow query logs need parameter group changes

    general_log = 1 and slow_query_log = 1 must be set in the aws_db_parameter_group before those exports produce anything. The long_query_time parameter controls the slow query threshold (default is 10 seconds). Whether these changes require a reboot depends on each parameter's apply type, check the RDS parameter documentation before applying to production.

  • Control may require specific log types depending on configuration

    Some compliance tooling lets you parameterize which log types are required, not just that at least one is present. If your organization's policy mandates all four types but you only export error, the control fails even though the argument is non-empty. Check how the control is parameterized in whatever tooling you run it through.

  • CloudWatch Logs costs can grow quickly with general log enabled

    The general log records every SQL statement the instance executes. On a busy MariaDB instance that can mean gigabytes of ingestion per day, with real CloudWatch Logs costs to match. Confirm current regional pricing before enabling high-volume log types, and set a retention policy that balances compliance requirements against ongoing storage costs.

Audit evidence

Auditors expect Config rule evaluation results showing RDS MariaDB instances compliant, confirming enabled_cloudwatch_logs_exports includes the required log types. Supporting evidence includes the RDS instance configuration page in the AWS Console showing "Published logs" with the relevant types listed, and the corresponding CloudWatch Logs log groups (typically /aws/rds/instance/<instance-id>/<log-type>) containing recent entries.

For deeper assurance, auditors may review CloudWatch Logs retention policies to confirm logs are kept for the required retention period, and check CloudTrail for ModifyDBInstance events to verify when logging was enabled and that it has not been subsequently disabled.

Framework-specific interpretation

Tool mappings

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

  • Compliance.tf Control: rds_db_instance_mariadb_logging_enabled

  • AWS Config Managed Rule: MARIADB_PUBLISH_LOGS_TO_CLOUDWATCH_LOGS

  • Checkov Check: CKV_AWS_129

  • Powerpipe Control: aws_compliance.control.rds_db_instance_mariadb_logging_enabled

  • Prowler Check: rds_instance_integration_cloudwatch_logs

  • AWS Security Hub Controls: RDS.42, RDS.9

Last reviewed: 2026-03-09