Amazon RDS log analysis: natural language queries with Kiro and MCP

Database administrators and developers face a persistent challenge: efficiently analyzing vast amounts of database logs to identify performance bottlenecks, security issues, and operational anomalies. Amazon Relational Database Service (Amazon RDS) generates multiple log types that provide critical insights into database performance, errors, and security events. However, traditional log analysis methods often require complex queries, deep knowledge of log formats, and time-consuming manual investigation through the AWS Management Console or Amazon CloudWatch Log Insights.

In this post, we demonstrate an approach to review RDS logs using Kiro, an AI-powered conversational assistant combined with the Model Context Protocol (MCP) server from awslabs.cloudwatch-mcp-server. This solution transforms log analysis from a technical, query-based process into a natural language conversation, delivering actionable insights instantly.

Understanding RDS log types

Amazon RDS supports multiple database engines, each generating specific log types that you can publish to Amazon CloudWatch for centralized monitoring and analysis. The following table shows the log types available for each engine.

Solution overview

This solution uses Kiro with MCP to enable natural language querying of Amazon RDS logs stored in Amazon CloudWatch. The architecture consists of three layers. Kiro CLI communicates with Amazon Bedrock (Anthropic’s Claude model) to interpret your natural language input. The CloudWatch MCP server (awslabs.cloudwatch-mcp-server) translates those interpreted requests into AWS API calls. Amazon CloudWatch returns the relevant RDS log data for analysis.

Kiro

Kiro is an AI-powered conversational assistant designed to assist developers and IT professionals, including DBAs, with tasks ranging from coding to troubleshooting. Available on the command-line interface (CLI), Visual Studio Code, JetBrains IDEs, and mobile apps, it supports natural language queries to generate code, optimize resources, and interact with AWS services. With Kiro you can:

• Write and optimize SQL queries based on natural language prompts.
• Analyze database schemas and generate documentation or diagrams.
• Suggest performance optimization by accessing execution plans and metrics.
• Integrate with AWS services such as Amazon CloudWatch, Amazon RDS for SQL Server/MySQL/PostgreSQL, or Amazon Aurora.

MCP

The Model Context Protocol (MCP) developed by Anthropic is an open protocol that standardizes how applications provide context to large language models (LLMs). MCP enables Kiro to connect to external data sources and tools through lightweight MCP servers. The Kiro CLI acts as an MCP client, facilitating communication between the LLM and the MCP server to Amazon CloudWatch, as shown in the following figure.

Prerequisites

Estimated time to complete: 30 minutes.

Before you begin, make sure you have the following:

• An AWS account. Create one if you don’t already have one.
• Access to an AWS account through the AWS Management Console and the AWS Command Line Interface (AWS CLI).
• Kiro CLI installed on your system.
• The uv utility from Astral or the GitHub README.
• Python version 3.14 installed using the uv utility.

  uv python install 3.14

• A database instance with logs configured to stream to Amazon CloudWatch for monitoring and analysis.

  Note: For more details, see Amazon CloudWatch Logs billing and cost.

• This solution works with multiple AI models available through Amazon Bedrock. For this post, we use Anthropic’s models in Amazon Bedrock. For more information, see Add or remove access to Amazon Bedrock foundation models.

Configuring MCP servers

The following steps walk you through configuring the AWS MCP server for use with Kiro CLI.

1. Set up your AWS profile:

   aws configure --profile Profile Name
   AWS Access Key ID: [Your access key]
   AWS Secret Access Key: [Your secret key]
   Default region name: [your-region]
   Default output format: json

2. Verify your Kiro CLI version is 1.9.x or later to use MCP features. You can check the Kiro CLI version by running kiro-cli --version in your terminal.
3. Configure the Amazon CloudWatch MCP server. Kiro CLI supports two levels of MCP configuration:
   • Global configuration: ~/.kiro/settings/mcp.json applies across all your projects.
   • Local configuration: .kiro/settings/mcp.json is specific to the current project.

   Choose your preferred configuration level and add the following CloudWatch MCP server configuration to the corresponding mcp.json file. Replace the AWS_PROFILE and AWS_REGION placeholders with your specific AWS profile and Region.

   {
       "mcpServers": {
           "awslabs.cloudwatch-mcp-server": {
               "autoApprove": [],
               "disabled": false,
               "command": "uvx",
               "args": [
                   "awslabs.cloudwatch-mcp-server@latest"
               ],
               "env": {
                   "AWS_PROFILE": "[The AWS Profile Name you used in step 1 for AWS access]",
                   "AWS_REGION": "Add your AWS Region",
                   "FASTMCP_LOG_LEVEL": "ERROR"
               },
               "transportType": "stdio"
           }
       }
   }

4. Start the conversation with the command kiro-cli. For more information, see Using chat on the command line. Use the /tools command to view available tools and capabilities.

The following screenshot shows Kiro CLI in action, analyzing error logs for an Amazon RDS for MySQL instance.

The following example shows a sample prompt and the response from Kiro CLI analyzing RDS error logs:

> Analyze error logs for RDS instance mysql8032 from last 7 days and identify top
  5 recurring errors with remediation steps

Let me fetch the RDS error logs for your MySQL instance. First, I'll check the
available log files.

Running aws cli command (using tool: aws):

Service name: rds
Operation name: describe-db-log-files
Parameters:
- db-instance-identifier: "mysql8032"
- filename-contains: "error"
Region: us-east-1
Label: List RDS log files for mysql8032

Allow this action? Use 't' to trust (always allow) this tool for the session. [y/n/t]:

> t

- Completed in 4.52s

> Here's the full analysis of RDS instance mysql8032 over the last 7 days.

================================================================================
Top 5 Recurring Errors/Warnings - RDS Instance mysql8032
================================================================================

1. [MY-013068] / [MY-013287] - Deprecated validate_password plugin syntax (4 occurrences)

The syntax 'validate password plugin' is deprecated and will be removed in a
future release. Please use validate_password component instead.

This fires on every shutdown and startup cycle.

- Migrate from the legacy plugin to the component-based architecture:

  UNINSTALL PLUGIN validate_password;
  INSTALL COMPONENT 'file://component_validate_password';

- Update your RDS custom parameter group: set validate_password parameters using
  the component syntax (e.g., validate_password.policy instead of
  validate_password_policy).
- This will become a hard error in a future MySQL release.

================================================================================

2. [MY-000067] - Unknown Group Replication variables (4 occurrences)

unknown variable 'loose-group_replication_enforce_update_everywhere_checks=1'
unknown variable 'loose-group_replication_single_primary_mode=0'

These appear on every startup. The loose- prefix prevents a crash, but they
indicate stale config.

- If you're not using Group Replication (and RDS MySQL doesn't support it),
  remove these from your custom parameter group:
  loose-group_replication_enforce_update_everywhere_checks
  loose-group_replication_single_primary_mode

- These were likely carried over from a migration or template. Clean them up via
  the RDS console or CLI:

  aws rds modify-db-parameter-group --db-parameter-group-name <your-pg> \
    --parameters "ParameterName=loose-group_replication_enforce_update_everywhere_checks,ParameterValue=,ApplyMethod=pending-reboot"

================================================================================

3. [MY-013640] - Self-signed CA certificate (2 occurrences)

CA certificate (rootCAcerts/rds-metadata/server.pem is self-signed)
Fires on every startup.

- This is for RDS-managed TLS. RDS uses its own CA file inside. No action needed
  unless you're enforcing custom CA validation.
- If your clients need to trust the RDS CA, download the appropriate CA bundle
  and configure your connection strings with --ssl-ca.
- Severity: safe to ignore.

================================================================================

4. [MY-013898] - Deprecated --ssl-fips-mode (2 occurrences)

'--ssl-fips-mode' is deprecated and will be removed in a future release.

- This is set by the RDS platform internally, not by your parameter group.
  You cannot directly change it.
- AWS will update this in a future RDS engine version.
- If you're on an older minor version, consider upgrading to the latest
  MySQL 8.0.x patch where this may be resolved.

================================================================================

5. Auto-start after exceeding max stop duration - Forced thread close
   (1 occurrence each, but operationally significant)

DB instance is being started due to it exceeding the maximum allowed time
being stopped.
Closing close of thread / user 'rdsadmin'

The instance was stopped for 7+ days and RDS auto-started it. During the
restart cycle, an rdsadmin thread was forcibly closed.

- RDS auto-starts stopped instances after 7 days. If you need it stopped
  longer, automate re-stopping with a Lambda + EventBridge rule:

  import boto3
  def lambda_handler(event, context):
      boto3.client('rds').stop_db_instance(DBInstanceIdentifier='mysql8032')

- The forced thread close of rdsadmin is benign - it's RDS's internal
  management user being cleaned up during shutdown. No action needed.
- If this instance isn't needed, consider snapshotting and deleting it to
  avoid charges.

================================================================================
Summary
================================================================================

| # | Error Code              | Severity | Occurrences | Action Required                            |
|---|-------------------------|----------|-------------|--------------------------------------------|
| 1 | MY-013068/MY-013287     | Warning  | 4           | Yes - migrate to validate_password component |
| 2 | MY-000067               | Warning  | 4           | Yes - clean up parameter group             |
| 3 | MY-013640               | Info     | 2           | No - expected RDS behavior                 |
| 4 | MY-013898               | Info     | 2           | No - RDS platform managed                  |
| 5 | Auto-start + thread close | Notice | 1 each      | Optional - automate stop or delete instance |

The instance is otherwise healthy - no client-level errors, no InnoDB corruption,
and backups are completing successfully (daily backups running consistently from
May 30-31). The two actionable items are cleaning up the parameter group
(items 1 and 2).

Important: Validate MCP recommendations against your managed service’s supported configuration. Not every suggested action is applicable or executable within its scope.

Example prompts using Kiro CLI

The following are example prompts you can use with Kiro CLI to analyze different RDS log types:

• Error log: Analyze error logs for RDS instance [instance name] in [region] from last 7 days and identify top 5 recurring errors with remediation steps.
• Audit log: Review audit logs for RDS instance [instance name] in [region] and identify failed logins, unauthorized access, and privilege escalation events.
• Slow query logs: Analyze slow query logs for RDS instance [instance name] in [region] exceeding 5 seconds in the last 1 hour.
• General log: Examine general logs for RDS instance [instance name] in [region] from last 24 hours and analyze connection patterns and DDL statements.
• Agent log: Analyze SQL Server Agent logs for RDS instance [instance name] in [region] and identify failed jobs with optimization recommendations.
• Diagnostic log: Review diagnostic logs for RDS instance [instance name] in [region] and identify critical system events with performance tuning recommendations.
• Notify log: Analyze notify logs for RDS instance [instance name] in [region] and summarize administrative notifications and operational events.
• IAM authentication error log: Analyze IAM authentication error logs for RDS instance [instance name] in [region] and detect any error patterns with security recommendations.
• Upgrade log: Review upgrade logs for RDS instance [instance name] in [region] and provide comprehensive upgrade success report with lessons learned.
• Alert log: Analyze Oracle alert logs for RDS instance [instance name] in [region] and identify ORA errors with troubleshooting steps.
• Trace log: Examine Oracle trace logs for RDS instance [instance name] in [region] and analyze wait events with query optimization recommendations.
• Listener log: Analyze Oracle listener logs for RDS instance [instance name] in [region] and track connection attempts with network configuration recommendations.
• Oracle Management Agent log: Analyze Oracle Management Agent logs for RDS instance [instance name] in [region] and identify communication failures with troubleshooting steps.

Best practices

The following best practices cover two areas: operational guidance on how to safely act on AI-generated findings, and security guidance on how to protect sensitive log data when using Kiro and MCP for RDS log analysis.

Operational

Do not run any mitigation without first understanding its impact. This is the most important rule in this workflow. Kiro can surface findings, summarize logs, and propose remediation steps, but you must evaluate any suggested action before applying it.

Before executing a change based on an AI-generated recommendation:

• Understand what the change does. Read the command, query, or parameter change in full.
• Validate the assumption behind the recommendation. AI-assisted analysis is pattern-based. The root cause it suggests may be reasonable but not correct for your environment.
• Test in non-production first whenever the change is mutating (for example, parameter group updates, index rebuilds, terminate session commands, schema changes).
• Keep a human in the loop for any production action. Automation is a multiplier, not a substitute for judgment, especially on stateful systems like databases.

Security

When you implement natural language queries for RDS log analysis using Kiro and MCP, you must address security considerations to protect sensitive data and maintain compliance. Database logs can contain personally identifiable information (PII), authentication credentials, IP addresses, query patterns revealing business logic, and schema information that could expose vulnerabilities. The current architecture downloads logs to local workstations through CLI calls, creating risks including data breach exposure, lack of audit trails, and potential violations of compliance frameworks such as HIPAA, PCI-DSS, and GDPR.

To mitigate these risks, implement the following security controls:

Infrastructure security

• Deploy Kiro on Amazon Elastic Compute Cloud (Amazon EC2) instances within the same VPC as your RDS instances rather than local laptops.
• Implement security groups restricting access to only necessary ports and IP ranges.

Access control

• Use IAM roles with least privilege permissions instead of long-term access keys.
• Grant only rds:DescribeDBInstances, logs:DescribeLogGroups, logs:DescribeLogStreams, logs:FilterLogEvents.
• Implement resource-based policies limiting access to specific RDS instances and log groups.

Cleanup

Follow these steps to remove the resources and configurations created during this walkthrough.

Configuration cleanup:

• Remove or comment out the MCP server configuration from the mcp.json file.
• Delete the AWS profile configurations if you created them specifically for this setup.

Software cleanup:

• Uninstall the CloudWatch MCP server: kiro-cli mcp remove cloudwatch.
• Remove Kiro CLI if no longer needed.

File cleanup:

• Remove configuration files (mcp.json, AWS credentials).
• Delete any generated reports or analysis outputs.

Warning: Before deleting analysis outputs, ensure you have archived any reports needed for compliance, auditing, or historical reference. Once deleted, this data cannot be recovered. Consider backing up critical analysis results to Amazon Simple Storage Service (Amazon S3) before deletion.

Although this walkthrough uses an Amazon RDS for MySQL instance, the same approach applies to all RDS and Aurora engine types listed in the log types table.

Conclusion

In this post, you learned how to use Kiro to query Amazon RDS logs through Amazon CloudWatch using natural language. With this approach, you can discover resources (list all RDS log groups), perform time-based analysis (analyze logs between specific date ranges), investigate performance issues (identify slow queries exceeding configurable thresholds such as 10 seconds), diagnose database-specific problems (analyze SQL Server deadlocks), and generate comprehensive error reports for specific instances. This eliminates the need for complex CloudWatch Log Insights queries or manual console navigation, providing actionable insights through conversational commands that target specific instances, time periods, and performance criteria.

To get started, install the Kiro CLI and configure the CloudWatch MCP server. For more information about publishing RDS logs to Amazon CloudWatch, see Publishing database logs to Amazon CloudWatch Logs.

About the authors