Key Takeaways
- RDS is a managed database you cannot agent. AWS runs the host, so you monitor RDS through its logs, not a Wazuh agent.
- Publish RDS logs to CloudWatch: enable the audit, error, general and slow-query logs (per engine) to export to CloudWatch Logs, where Wazuh collects them.
- Enable database audit logging in the RDS parameter group or option group, since meaningful security events are off by default.
- Detect the usual database threats: failed logins and brute force, logins from unexpected hosts, privilege and user changes, and schema tampering.
- Combine with CloudTrail, which covers RDS management actions (create, modify, snapshot, delete) while the engine logs cover in-database activity.
Why RDS Is a Monitoring Blind Spot
Amazon RDS is a managed database service: AWS runs the underlying operating system and database host, and you do not get shell access. That is convenient operationally, but it breaks the usual database-monitoring approach, because you cannot install the Wazuh agent on an RDS instance the way you would on a self-managed database server. Many teams therefore leave RDS unmonitored, which is dangerous given that RDS often holds the most sensitive data in the account.
The answer is to monitor RDS through its logs rather than an agent. RDS can publish database engine logs to CloudWatch Logs, and Wazuh collects them from there. This gives you visibility into database activity, failed logins, privilege changes and more, without needing host access. It is the correct pattern for any managed service you cannot put an agent on.
Enabling and Publishing RDS Logs
Two steps are needed. First, enable the right logging inside the database engine, because the security-relevant logs are off by default. This is done through the RDS parameter group (and, for some engines, the option group). For MySQL and MariaDB, enable the audit log (via the MariaDB Audit plugin option) and the general and slow-query logs as needed; for PostgreSQL, enable connection, disconnection and statement logging, and pgAudit where supported; for SQL Server, enable auditing through the relevant options.
Second, configure RDS to export those logs to CloudWatch Logs, which is a setting on the RDS instance. Once the logs flow to CloudWatch, configure the Wazuh CloudWatch Logs integration to collect the relevant log groups. Wazuh then decodes and applies rules to the database events. The main setup effort is in the engine-level logging configuration; once that is right and exporting to CloudWatch, the Wazuh side is the standard CloudWatch collection described in this series.
Need Your AWS Connected to Wazuh?
Codesecure specialises in Wazuh cloud monitoring: CloudTrail, CloudWatch, Config, VPC Flow Logs, S3, EC2, RDS and MongoDB Atlas, wired into one SOC with least-privilege IAM and tuned detections. ISO/IEC 27001:2022 certified delivery, named OSCP, CEH and CISSP consultants across India, Singapore, UAE and Malaysia.
See Cloud SOC Services →What to Detect in RDS
The detections are the familiar database ones, now applied to your managed databases. Authentication: repeated failed logins (database brute force), successful logins from unexpected hosts or applications, and access at unusual times, especially for privileged accounts. These catch credential attacks against the database directly.
Privilege changes: GRANT and REVOKE statements, new database users and role changes, which can indicate an attacker establishing or escalating access. Schema and data signals: DDL such as DROP and ALTER against production outside change windows, and signs of bulk data access or export. These mirror the detections for self-managed MySQL, PostgreSQL and SQL Server, so RDS joins the same database-monitoring coverage rather than being an exception. The depth depends on how much auditing you enable, balanced against log volume and cost.
RDS Management Events in CloudTrail
The engine logs cover what happens inside the database, but RDS also has a management layer that CloudTrail covers. Actions like creating or deleting an RDS instance, modifying it, changing its security group, making it publicly accessible, creating a snapshot or sharing a snapshot are AWS API calls recorded in CloudTrail, not in the database engine logs.
Some of these are high-risk: making an RDS instance publicly accessible, or sharing or copying a snapshot to another account, are classic data-exposure and exfiltration techniques that bypass the database entirely. So RDS monitoring has two layers in Wazuh: the engine logs via CloudWatch for in-database activity, and CloudTrail for management actions on the instance. Alerting on a snapshot being shared externally or an instance becoming public is as important as detecting a failed login.
Managing Audit Volume
As with any database monitoring, full query auditing on a busy RDS instance can generate large volumes of logs, which flow through CloudWatch (with its cost) into Wazuh storage. The same discipline applies: audit selectively based on the sensitivity of the data. For every RDS instance, log connections, authentication failures and privileged or DDL activity, which are low volume and high value, and reserve detailed statement auditing for the databases that genuinely warrant it.
Be mindful that CloudWatch ingestion and RDS logging both have cost implications, so right-size what you enable. In Wazuh, keep the usual separation of storage and alerting. Done with this balance, RDS monitoring closes a common and serious blind spot, bringing your managed databases into the same detection and compliance coverage as everything else, without needing the agent you cannot install.
Cloud Logs Flowing But No Detections?
Collecting CloudTrail or VPC Flow Logs is only step one. Our SOC lead will review your AWS log coverage and detection gaps on a 30-minute free scoping call. No obligation, no slideware.
Book a Free Scoping Call →The Complete RDS Picture
Monitoring RDS well with Wazuh comes down to a clear pattern. Enable audit and error logging in the engine via the parameter and option groups, export those logs to CloudWatch, and collect them in Wazuh for in-database detections. Monitor RDS management actions through CloudTrail for high-risk changes like public exposure and snapshot sharing. And tune audit depth against volume and cost.
This brings managed databases, often the most sensitive systems in an AWS account, into full monitoring despite the agent constraint. It is a key part of the cloud SOC, complementing EC2 host monitoring for self-managed databases and the broader AWS log sources. For organisations running critical data on RDS, this coverage is essential.
Frequently Asked Questions
Can I install the Wazuh agent on Amazon RDS?
No. RDS is a managed service where AWS runs the underlying host and you do not get shell access, so you cannot install the Wazuh agent on it. Instead you monitor RDS through its database engine logs: enable audit and error logging, publish the logs to CloudWatch Logs, and collect them in Wazuh with the CloudWatch Logs integration.
How do I send RDS logs to Wazuh?
First enable the security-relevant logs inside the engine through the RDS parameter group (and option group for some engines): the audit log, plus general, slow-query, connection or statement logging depending on the engine. Then configure RDS to export those logs to CloudWatch Logs, and point the Wazuh CloudWatch Logs integration at the relevant log groups. Wazuh then decodes and applies rules.
What should I detect in RDS with Wazuh?
The standard database threats applied to managed databases: failed logins and brute force, logins from unexpected hosts or at unusual times, privilege changes (GRANT, REVOKE, new users and roles), and DDL such as DROP or ALTER against production outside change windows, plus signs of bulk data access. These mirror self-managed database detections so RDS joins the same coverage.
Does CloudTrail help monitor RDS?
Yes, for the management layer. CloudTrail records RDS API actions like creating, modifying, deleting or snapshotting an instance, changing its security group, or making it publicly accessible. Some of these are high-risk, making an instance public or sharing a snapshot externally are data-exposure techniques, so RDS monitoring combines engine logs (in-database activity) with CloudTrail (management actions).
How do I control RDS logging cost and volume?
Audit selectively by data sensitivity. For every instance, log connections, authentication failures and privileged or DDL activity, which are low volume and high value, and reserve detailed statement auditing for databases that warrant it. Be mindful that both RDS logging and CloudWatch ingestion have cost implications, and in Wazuh separate storage from alerting to keep history without alerting on routine queries.
Can Codesecure set up RDS monitoring in our Wazuh?
Yes. Codesecure configures RDS engine audit logging, CloudWatch export and Wazuh collection, builds detections for failed logins, privilege changes and schema tampering, and adds CloudTrail monitoring for high-risk management actions like public exposure and snapshot sharing. ISO/IEC 27001:2022 certified delivery with named OSCP, CEH and CISSP consultants across India, Singapore, UAE and Malaysia.
Monitor The Managed Databases You Cannot Agent
Codesecure brings Amazon RDS into Wazuh through engine audit logs over CloudWatch plus CloudTrail for management actions, with detections for failed logins, privilege changes and risky snapshot sharing. Delivered by named OSCP, CEH and CISSP consultants.
