# AWS RDS Audit Visibility This guide walks through enabling audit logging on AWS RDS for every supported engine and routing those logs to CloudWatch, where Monad can ingest them via the [AWS CloudWatch Logs](../inputs/aws/aws-cloudwatch-logs.mdx) input. **Sync Type: Incremental** --- ## How RDS Delivers Audit Logs AWS RDS exposes audit logs through two delivery paths: | Path | Description | |---|---| | **RDS Log Files API** | Audit log files written directly to the instance, downloadable via `DescribeDBLogFiles` / `DownloadDBLogFilePortion` | | **CloudWatch Logs** | Audit log entries streamed to a CloudWatch log group, queryable via standard CloudWatch APIs | This guide focuses on the **CloudWatch path**, which is the recommended approach for centralized, real-time audit log visibility. Once audit logs are flowing into CloudWatch, use the [AWS CloudWatch Logs](../inputs/aws/aws-cloudwatch-logs.mdx) input in Monad to ingest them. > **Engine support:** MySQL, MariaDB, and Oracle support exporting the `audit` log type to CloudWatch. PostgreSQL, SQL Server, and Db2 do not have a dedicated CloudWatch audit export — notes for those engines are included below. --- ## Step 1 — Enable Auditing Per Engine Auditing must be enabled at the database engine level before any logs are generated. Follow the section for your engine. ### MySQL MySQL on RDS uses the **MariaDB Audit Plugin** (`MARIADB_AUDIT_PLUGIN`) delivered via an RDS Option Group. **1. Create an Option Group:** 1. Open the [Amazon RDS Console](https://console.aws.amazon.com/rds) 2. In the left navigation pane, choose **Option groups** 3. Choose **Create group** 4. Fill in the following: - **Name:** `my-mysql-audit` - **Description:** `MySQL audit logging` - **Engine:** `mysql` - **Major engine version:** Select the version that matches your instance (e.g. `8.0`) 5. Choose **Create** **2. Add the audit plugin to the option group:** 1. In the **Option groups** list, select the group you just created 2. Choose **Add option** 3. Under **Option name**, select **MARIADB_AUDIT_PLUGIN** 4. Under **Option settings**, configure: - `SERVER_AUDIT_EVENTS`: `CONNECT,QUERY_DDL,QUERY_DML` - `SERVER_AUDIT_EXCL_USERS`: `rdsadmin` 5. Under **Scheduling**, select **Immediately** 6. Choose **Add option** Recommended `SERVER_AUDIT_EVENTS` values: | Value | What it captures | |---|---| | `CONNECT` | Connection and disconnection events | | `QUERY` | All SQL statements (high volume) | | `QUERY_DDL` | `CREATE`, `ALTER`, `DROP` only | | `QUERY_DML` | `INSERT`, `UPDATE`, `DELETE` only | | `TABLE` | Table-level access | **3. Attach the option group to your instance:** 1. In the left navigation pane, choose **Databases** 2. Select your MySQL instance 3. Choose **Modify** 4. Scroll to **Additional configuration** 5. Under **Option group**, select the option group you created (`my-mysql-audit`) 6. Choose **Continue** 7. Under **Scheduling of modifications**, select **Apply immediately** 8. Choose **Modify DB instance** --- ### MariaDB MariaDB uses the same `MARIADB_AUDIT_PLUGIN` option group mechanism as MySQL. Follow all three MySQL steps above with one difference in step 1: under **Engine**, select `mariadb` and choose the major engine version that matches your MariaDB instance. --- ### PostgreSQL PostgreSQL uses the **pgaudit** extension for structured audit logging. pgaudit events are written into the standard PostgreSQL log (`error/postgresql.log.*`). > **CloudWatch limitation:** PostgreSQL does not support a dedicated `audit` log export to CloudWatch. AWS only supports the `postgresql` and `upgrade` log types for CloudWatch export on PostgreSQL. If you require CloudWatch-based audit visibility for PostgreSQL, configure the [AWS CloudWatch Logs](../inputs/aws/aws-cloudwatch-logs.mdx) input on the `/aws/rds/instance/{instance}/postgresql` log group — pgaudit entries will be present there alongside other PostgreSQL log output. **1. Create a parameter group:** 1. In the left navigation pane, choose **Parameter groups** 2. Choose **Create parameter group** 3. Fill in: - **Parameter group family:** Select the family matching your PostgreSQL version (e.g. `postgres15`) - **Type:** `DB Parameter Group` - **Group name:** `my-postgres-audit` - **Description:** `PostgreSQL pgaudit logging` 4. Choose **Create** **2. Edit the parameter group to load pgaudit:** 1. In the **Parameter groups** list, select `my-postgres-audit` 2. Choose **Edit** 3. Search for `shared_preload_libraries` and set the value to `pgaudit` 4. Search for `pgaudit.log` and set the value to `ddl,role,connection` 5. Choose **Save changes** Recommended `pgaudit.log` values: | Value | What it captures | |---|---| | `ddl` | `CREATE`, `ALTER`, `DROP` and schema changes | | `role` | `GRANT`, `REVOKE`, role membership changes | | `connection` | Login and logout events | | `read` | `SELECT` and `COPY` from tables or sequences | | `write` | `INSERT`, `UPDATE`, `DELETE`, `TRUNCATE` | | `all` | Everything (high volume) | **3. Associate the parameter group with your instance:** 1. In the left navigation pane, choose **Databases** 2. Select your PostgreSQL instance 3. Choose **Modify** 4. Scroll to **Additional configuration** 5. Under **DB parameter group**, select `my-postgres-audit` 6. Choose **Continue** 7. Under **Scheduling of modifications**, select **Apply immediately** 8. Choose **Modify DB instance** **4. Reboot the instance to apply `shared_preload_libraries`:** 1. In the **Databases** list, select your instance 2. Choose **Actions** → **Reboot** 3. Choose **Confirm** **5. Install the extension in each target database:** Connect to your database and run: ```sql CREATE EXTENSION pgaudit; ``` --- ### Oracle Oracle RDS uses the native Oracle Audit Trail, enabled via a DB parameter group. **1. Create or open the parameter group for your instance:** 1. In the left navigation pane, choose **Parameter groups** 2. Either select the existing parameter group attached to your instance, or choose **Create parameter group** to create a new one with the Oracle family matching your version (e.g. `oracle-ee-19`) 3. Choose **Edit** **2. Set the `audit_trail` parameter:** 1. Search for `audit_trail` 2. Set the value to `OS` 3. Choose **Save changes** Supported `audit_trail` values: | Value | Behavior | |---|---| | `OS` | Writes to OS files — required for CloudWatch export | | `DB` | Writes to `SYS.AUD$` — not exported to CloudWatch | | `XML` | Writes to XML files | | `XML,EXTENDED` | XML files with SQL text and bind variables | | `none` | Auditing disabled (default) | **3. If you created a new parameter group, attach it to your instance:** 1. In the left navigation pane, choose **Databases** 2. Select your Oracle instance 3. Choose **Modify** 4. Scroll to **Additional configuration** 5. Under **DB parameter group**, select the parameter group 6. Choose **Continue** → **Apply immediately** → **Modify DB instance** **4. Reboot the instance to apply the parameter change:** 1. In the **Databases** list, select your instance 2. Choose **Actions** → **Reboot** 3. Choose **Confirm** > Oracle audit files on RDS have a 7-day default retention. Routing to CloudWatch is strongly recommended to avoid log loss. --- ### SQL Server — not supported SQL Server audit visibility through Monad is **not supported on RDS.** SQL Server on RDS can export only `error` and `agent` logs to CloudWatch — SQL Server Audit files (`.sqlaudit`) cannot be exported. Because there is no way to get the audit trail into CloudWatch (or otherwise expose it to Monad), enabling a Server Audit on the instance would not result in any audit logs reaching Monad. --- ### Db2 — not supported Db2 audit visibility through Monad is **not supported on RDS.** Db2 on RDS can export only `diag.log` and `notify.log` to CloudWatch — the `db2audit` trail cannot be exported. Because there is no way to get the audit trail into CloudWatch (or otherwise expose it to Monad), enabling Db2 auditing on the instance would not result in any audit logs reaching Monad. --- ## Step 2 — Route Audit Logs to CloudWatch This step applies to **MySQL, MariaDB, and Oracle**. After completing it, audit log entries will stream into CloudWatch and can be ingested by Monad. 1. In the left navigation pane, choose **Databases** 2. Select your instance 3. Choose **Modify** 4. Scroll to **Additional configuration** 5. Under **Log exports**, check the **Audit log** checkbox - For Oracle, also check **Alert log** and **Listener log** as needed 6. Choose **Continue** 7. Under **Scheduling of modifications**, select **Apply immediately** 8. Choose **Modify DB instance** AWS automatically creates the following CloudWatch log groups once the export is enabled: | Engine | CloudWatch Log Group | |---|---| | MySQL | `/aws/rds/instance/{instance-identifier}/audit` | | MariaDB | `/aws/rds/instance/{instance-identifier}/audit` | | Oracle | `/aws/rds/instance/{instance-identifier}/audit` | --- ## Step 3 — Grant IAM Permissions The IAM role or user used by Monad needs permission to read from the CloudWatch log group. **1. Create an IAM policy:** 1. Open the [IAM Console](https://console.aws.amazon.com/iam) 2. In the left navigation pane, choose **Policies** 3. Choose **Create policy** 4. Select the **JSON** tab and paste the following, replacing ``, ``, and `` with your values: ```json { "Version": "2012-10-17", "Statement": [ { "Sid": "CloudWatchDiscoverLogGroups", "Effect": "Allow", "Action": "logs:DescribeLogGroups", "Resource": "*" }, { "Sid": "CloudWatchReadAuditEvents", "Effect": "Allow", "Action": "logs:FilterLogEvents", "Resource": "arn:aws:logs:::log-group:/aws/rds/instance//audit:*" } ] } ``` 5. Choose **Next**, enter a name (e.g. `MonadRDSAuditPolicy`), and choose **Create policy** **2. Create an IAM role for Monad (Role ARN authentication):** 1. In the left navigation pane, choose **Roles** 2. Choose **Create role** 3. Under **Trusted entity type**, choose **AWS account** 4. Enter Monad's AWS account ID and choose **Next** 5. Search for and attach `MonadRDSAuditPolicy` 6. Choose **Next**, enter a role name (e.g. `MonadRDSAuditRole`), and choose **Create role** 7. Open the newly created role and copy its ARN — you will paste this into the Monad connector as **Role ARN** See [AWS Authentication Methods](../inputs/aws/index.mdx#authentication-methods) for details on configuring the trust relationship. **Alternative — static credentials:** 1. In the left navigation pane, choose **Users** 2. Select the IAM user (or create a new one with programmatic access) 3. Choose **Add permissions** → **Attach policies directly** 4. Search for and attach `MonadRDSAuditPolicy` 5. In the user's **Security credentials** tab, choose **Create access key** and save the Access Key ID and Secret Access Key --- ## Step 4 — Connect Monad Once audit logs are flowing into CloudWatch, configure the [AWS CloudWatch Logs](../inputs/aws/aws-cloudwatch-logs.mdx) input in Monad with: - **Region:** the AWS region where your RDS instance is deployed - **Role ARN** (or **Access Key** / **Secret Key**): the credentials created in Step 3 - **Log Group Name Prefix:** the log group name which was automatically created by RDS ## Related Articles - [MySQL audit plugin on RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.MySQL.Options.AuditPlugin.html) - [MariaDB audit plugin on RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.MariaDB.Options.html) - [pgaudit on RDS for PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.pgaudit.html) - [Oracle audit trail on RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.Oracle.Options.Audit.html) - [SQL Server audit on RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_LogAccess.Concepts.SQLServer.html) - [Db2 log access on RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_LogAccess.Concepts.Db2.html) - [Publishing MySQL/MariaDB logs to CloudWatch](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_LogAccess.MySQLDB.PublishtoCloudWatchLogs.html) - [Publishing Oracle logs to CloudWatch](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_LogAccess.Concepts.Oracle.html#USER_LogAccess.Oracle.PublishtoCloudWatchLogs)