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
Implementation
Choose the approach that matches how you manage Terraform.
Use the compliance.tf module to enforce this control by default. See get started with compliance.tf.
This control is enforced automatically with Compliance.tf modules. Start free trial
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
SOC 2: CC7.1 and CC7.2 call for monitoring system components for anomalies. Centralized database logs in CloudWatch are what examiners ask to see as evidence that the organization can detect and investigate security events affecting data stores.
PCI DSS v4.0: Requirements 10.2 and 10.3 call for audit log generation covering user access, authentication events, and administrative actions. MariaDB audit and error logs in CloudWatch cover all three for databases that may store cardholder data, and CloudWatch's retention controls support 10.3's log protection requirements.
HIPAA Omnibus Rule 2013: For MariaDB instances holding ePHI, 45 CFR 164.312(b) requires audit controls that track system activity. Shipping logs to CloudWatch lets you monitor access patterns, detect unauthorized queries, and retain evidence of who accessed health data and when.
ISO/IEC 27001:2022: A.8.15 wants logs produced and protected; A.8.16 wants monitoring for security events. CloudWatch handles both: it stores and retains the exported MariaDB logs and gives you the tooling to alert on them.
GDPR: Article 32 doesn't name specific tools, but centralized database logging contributes to, but doesn't fully cover, the technical measures it requires for securing personal data processing. The logs also feed directly into the 72-hour breach notification window under Article 33 when you need to establish what data was accessed and by whom.
NIS2 Directive (EU 2022/2555): NIS2's incident handling requirements expect entities to detect and investigate anomalous activity. Exporting MariaDB logs to CloudWatch is one approach to meeting the detection capability requirements for systems where database integrity or availability is in scope.
NIST SP 800-53 Rev 5: AU-2 (Event Logging), AU-3 (Content of Audit Records), AU-6 (Audit Record Review), and SI-4 (System Monitoring) all apply. The export satisfies AU-2 and AU-3; Logs Insights, metric filters, and alarms address the review and monitoring requirements in AU-6 and SI-4.
FedRAMP Moderate Baseline Rev 4: AU-2 and AU-6 require audit records to be generated and centrally reviewed. Publishing MariaDB logs to CloudWatch satisfies both: the export produces the records, and Logs Insights provides the review and analysis capability FedRAMP Moderate expects.
Related controls
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