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"toenabled_cloudwatch_logs_exportsdoes not automatically enable the MariaDB Audit Plugin. You still need anaws_db_parameter_groupwithserver_audit_logging = 1andserver_audit_eventsset 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 = 1andslow_query_log = 1must be set in theaws_db_parameter_groupbefore those exports produce anything. Thelong_query_timeparameter 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
generallog 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
Related controls
Elasticsearch domain error logging to CloudWatch Logs should be enabled
API Gateway REST API stages should have AWS X-Ray tracing enabled
Tool mappings
Use these identifiers to cross-reference this control across tools, reports, and evidence.
Compliance.tf Control:
rds_db_instance_mariadb_logging_enabledAWS Config Managed Rule:
MARIADB_PUBLISH_LOGS_TO_CLOUDWATCH_LOGSCheckov Check:
CKV_AWS_129Powerpipe Control:
aws_compliance.control.rds_db_instance_mariadb_logging_enabledProwler Check:
rds_instance_integration_cloudwatch_logsAWS Security Hub Controls:
RDS.42,RDS.9
Last reviewed: 2026-03-09