RDS logs are being sent to CloudWatch, but you can’t find them, or they’re not showing up.

The core issue is that while you’ve enabled log exports from RDS to CloudWatch, the specific log groups RDS creates aren’t automatically discoverable or queryable with the tools you’re expecting. This is because RDS creates unique, often long, log group names that don’t always align with simple naming conventions.

Here are the common reasons why you might not be seeing your RDS logs in CloudWatch and how to fix them:

1. Incorrect Log Group Name:

  • Diagnosis: RDS creates log groups with a specific format: /aws/rds/cluster/<DB_CLUSTER_IDENTIFIER>/<LOG_TYPE> for Aurora, or /aws/rds/instance/<DB_INSTANCE_IDENTIFIER>/<LOG_TYPE> for non-Aurora. If you’re searching for a generic name like rds-logs or my-database-logs, you won’t find them.
  • Fix: Navigate to the RDS console, select your database instance or cluster, and under the "Logs & events" tab, you’ll see the "Log exports" section. The exact log group names are listed there. To query them in CloudWatch Logs, you must use these precise names. For example, to query the error log for an Aurora cluster named my-aurora-cluster, your query would target logGroupName: /aws/rds/cluster/my-aurora-cluster/error.
  • Why it works: CloudWatch Logs organizes logs into distinct log groups. RDS names these groups according to a predictable but specific pattern, and you must reference them by their exact generated name.

2. Log Type Not Exported:

  • Diagnosis: You might have enabled log exports for some log types but not the specific one you’re looking for (e.g., enabled audit logs but need error logs).
  • Fix: In the RDS console, go to your DB instance or cluster, click "Modify," and scroll down to the "Log exports" section. Ensure the checkbox next to the log type you need (e.g., error, general, slowquery, audit) is selected. Save the changes. RDS will then begin exporting that log type.
  • Why it works: The export functionality is granular per log type. You explicitly tell RDS which categories of logs to push to CloudWatch.

3. Insufficient IAM Permissions:

  • Diagnosis: The IAM role or user that is trying to access or query the CloudWatch Logs might not have the necessary logs:FilterLogEvents, logs:GetLogEvents, and logs:DescribeLogGroups permissions for the specific log groups RDS is writing to.
  • Fix: Attach a policy to the IAM role/user that grants read access to the relevant CloudWatch Log Groups. A minimal policy would look like this:
    {
        "Version": "2012-10-17",
        "Statement": [
            {
                "Effect": "Allow",
                "Action": [
                    "logs:FilterLogEvents",
                    "logs:GetLogEvents",
                    "logs:DescribeLogGroups"
                ],
                "Resource": "arn:aws:logs:us-east-1:123456789012:log-group:/aws/rds/*"
            }
        ]
    }
    
    Replace us-east-1 and 123456789012 with your region and AWS account ID.
  • Why it works: IAM policies are the gatekeepers. Without explicit permission to read from CloudWatch Logs, any attempt to query will be denied, even if the logs are being sent.

4. Log Retention Period:

  • Diagnosis: CloudWatch Logs has a retention period. If your logs have expired based on this setting, they will no longer be searchable.
  • Fix: In the CloudWatch console, navigate to "Log groups," find your RDS log group (e.g., /aws/rds/instance/my-db-instance/error), click on it, and then under "Actions," select "Edit retention and monitoring." Set a retention period that meets your needs (e.g., 7 days, 30 days, or "Never expire").
  • Why it works: CloudWatch Logs doesn’t store data indefinitely by default. Setting a retention period ensures that logs are kept for the duration you specify, making them available for querying.

5. Time Lag in Export:

  • Diagnosis: Log export from RDS to CloudWatch is not instantaneous. There can be a delay of a few minutes. If you’re checking immediately after a log event, it might not have appeared yet.
  • Fix: Wait for 5-10 minutes after the log event occurs or after enabling log export, and then try querying again.
  • Why it works: Network latency, processing, and the batching mechanisms for log delivery introduce a small but normal delay.

6. Incorrect Query Syntax in CloudWatch Logs:

  • Diagnosis: You’re looking at the correct log group but your query syntax is wrong, so no results are returned even if logs are present. For example, trying to filter by message:"connection refused" when the actual log format requires a different field.
  • Fix: Start with a simple query to verify logs are arriving. In CloudWatch Logs, select your RDS log group, and in the "Filter log events" box, enter {} (a single pair of curly braces) and a time range of "Past 15 minutes." If you see log entries, your basic query is working, and you can then refine it to search for specific keywords or patterns relevant to your log type. For example, to find specific SQL statements in the slow query log, you might use SELECT.
  • Why it works: The {} query is a catch-all that returns all log events within the specified time. This is the most basic way to confirm data is flowing and that your filtering is the issue, not the ingestion.

After ensuring all these points are addressed, you should be able to find and query your RDS logs in CloudWatch. The next common hurdle is setting up CloudWatch Alarms based on these log queries.

Want structured learning?

Take the full Rds course →