Enabling GuardDuty RDS Data Activity MonitoringDetecting data exfiltration and deletion in Aurora and RDS for PostgreSQL

2. New finding types

Data activity monitoring adds seven finding types. The severities are the defaults listed in the AWS documentation.

For the three AnomalousBehavior types, severity depends on the source and the user who ran the statements.

• LOW: run from an IP address in a private network (except Drop)
• MEDIUM: run from a public IP address (Drop is MEDIUM as soon as anomalous DROPs occur)
• HIGH: the volume is far above normal, and the activity came from a previously unseen public network or was performed by a high-privilege role or administrative client

If the credentials of an application server inside the VPC are used, the source is a private IP, so Exfiltration and Delete findings may come in as LOW. Decide how to handle them in your alert rules (section 7).

3. Supported databases and versions

RDS for PostgreSQL read replicas require the primary instance to be on a supported version and to be replicating successfully. In an account with only MySQL-family databases, data activity monitoring will not produce findings.

4. Enable it in the console

With AWS Organizations, only the delegated GuardDuty administrator account can change this setting (member accounts cannot). We use our dedicated security account as the delegated administrator, so we worked from there.

1. Open the GuardDuty console in the delegated administrator account
2. In the left menu, choose "Protection Plans" → "Configure all enablements"
3. Under "RDS Protection", you'll see "RDS Login Activity Monitoring" and "RDS Data Activity Monitoring"
4. For "RDS Data Activity Monitoring", set "This account" to Enabled and "Auto enable for organization accounts" to "Enable for all accounts"
5. Choose "Save all" → "Confirm and save"

The screen shows "RDS Protection for login activity is required for RDS Protection for data activity to function." In accounts where login activity monitoring is off, enable it first.

"Enable for all accounts" applies to both existing member accounts and accounts that join the organization later. To cover only new accounts, choose "Configure accounts manually" → "Automatically enable for new member accounts".

5. Enable it with the AWS CLI

Data activity monitoring is specified as RDS_DATA_RISK in the AdditionalConfiguration of RDS_LOGIN_EVENTS. All of the following runs in the delegated administrator account (profile example-security).

The delegated administrator account itself

DET=$(aws guardduty list-detectors --query 'DetectorIds[0]' --output text \
        --profile example-security)

aws guardduty update-detector \
  --detector-id $DET \
  --features '[{
    "Name": "RDS_LOGIN_EVENTS",
    "Status": "ENABLED",
    "AdditionalConfiguration": [
      { "Name": "RDS_DATA_RISK", "Status": "ENABLED" }
    ]
  }]' \
  --profile example-security

All accounts in the organization (existing + new)

aws guardduty update-organization-configuration \
  --detector-id $DET \
  --auto-enable-organization-members ALL \
  --features '[{
    "Name": "RDS_LOGIN_EVENTS",
    "AutoEnable": "ALL",
    "AdditionalConfiguration": [
      { "Name": "RDS_DATA_RISK", "AutoEnable": "ALL" }
    ]
  }]' \
  --profile example-security

Set AutoEnable to NEW to cover only new accounts, or NONE to stop auto-enabling.

Specific member accounts only

aws guardduty update-member-detectors \
  --detector-id $DET \
  --account-ids <ACCOUNT_ID_1> <ACCOUNT_ID_2> \
  --features '[{
    "Name": "RDS_LOGIN_EVENTS",
    "Status": "ENABLED",
    "AdditionalConfiguration": [
      { "Name": "RDS_DATA_RISK", "Status": "ENABLED" }
    ]
  }]' \
  --profile example-security

On success, UnprocessedAccounts is returned as an empty array. To keep login activity monitoring on and turn off only data activity monitoring, set the Status of RDS_DATA_RISK to DISABLED.

Apply to every region at once

for r in $(aws ec2 describe-regions --query 'Regions[].RegionName' --output text \
             --profile example-security); do
  DET=$(aws guardduty list-detectors --region $r \
          --query 'DetectorIds[0]' --output text --profile example-security)
  aws guardduty update-organization-configuration --region $r \
    --detector-id $DET \
    --auto-enable-organization-members ALL \
    --features '[{"Name":"RDS_LOGIN_EVENTS","AutoEnable":"ALL",
      "AdditionalConfiguration":[{"Name":"RDS_DATA_RISK","AutoEnable":"ALL"}]}]' \
    --profile example-security
done

6. Check that it's enabled

Right after enabling it, the console showed the delegated administrator account itself as Enabled (Free trial: 30 days), but "Active organization member accounts" stayed at 0/3. As the AWS documentation notes, it can take up to 24 hours for the configuration to reach member accounts.

# status of the delegated administrator account itself
aws guardduty get-detector --detector-id $DET --profile example-security \
  --query 'Features[?Name==`RDS_LOGIN_EVENTS`]'

# status of each member account
aws guardduty get-member-detectors --detector-id $DET \
  --account-ids <ACCOUNT_ID_1> <ACCOUNT_ID_2> --profile example-security \
  --query 'MemberDataSourceConfigurations[].[AccountId, Features[?Name==`RDS_LOGIN_EVENTS`].AdditionalConfiguration[]]'

You're done when the Status of RDS_DATA_RISK is ENABLED. In the console, the "Accounts" page in the left menu has an "RDS data activity" column showing the status of each account.

7. Review your alert rules

The alert rule from our previous article (GuardDuty findings aggregated in Security Hub with severity MEDIUM or higher and not yet handled) doesn't filter by finding type, so it alerts on the new findings with no extra setup.

However, as noted in section 2, reads and deletes from inside the VPC may be reported as LOW and won't be caught by this rule. Review LOW findings regularly in the Security Hub console, or, where the database is critical, consider a separate rule that alerts on LOW findings for RDS only.

You can test alerts with GuardDuty sample findings. Specifying a HIGH-severity finding type lets you check whether a MEDIUM-or-higher rule sends an alert.

aws guardduty create-sample-findings \
  --detector-id $DET --finding-types "Impact:RDS/MaliciousIPCaller" \
  --profile example-security

Archive the sample findings once you've checked.

8. Costs and caveats

• There is a 30-day free trial. Even accounts already using login activity monitoring get a 30-day free trial per account and region when they enable data activity monitoring for the first time. It is not disabled automatically when the trial ends, so check the monthly estimate on the "Usage" page of the GuardDuty console during the trial.
• Cost scales with database size. It is billed separately from login activity monitoring, based on the vCPUs of your database instances (ACUs for Aurora Serverless v2). Prices vary by region, so check the GuardDuty pricing page.
• You can't see the query logs. GuardDuty doesn't make data activity logs available to you. To find out which rows of which tables were read when a finding appears, you need database-side audit logs, for example with pgAudit.
• Detection is a starting point, not a fix. The response AWS recommends is to change the database user's password, check the scope in the audit logs, restore from backups if needed, and keep the database in a private subnet with security groups limiting the sources. Before any finding appears, check that the database isn't exposed to the internet and that application users don't have DROP privileges.