Skip to main content
emnode / learn
Compliance Low severity

AWS Security Hub · RDS

RDS.21: RDS parameter-group event notifications

Written and reviewed by Emnode · Last reviewed

What does AWS Security Hub RDS.21 check?

RDS.21 checks for an AWS::RDS::EventSubscription whose source type is db-parameter-group and whose categories include configuration change. If at least one subscription exists in the account but none covers parameter-group config changes, it reports FAILED.

Why does RDS.21 matter?

A parameter group is the config file for the database engine — max_connections, rds.force_ssl, log_statement, durability knobs — and one group is usually attached to many instances at once. Editing a single value can quietly reshape the behaviour of a whole fleet the next time the change applies. Parameter changes are high-blast-radius and easy to make by accident during a tuning session; the notification turns invisible config drift into a message in a channel so the team hears it from an alert, not an incident.

How do I fix RDS.21?

  1. Create an RDS event subscription with source type db-parameter-group covering the configuration change category, pointed at a watched SNS topic.
  2. Verify a test parameter edit produces a notification.
  3. Keep the subscription in IaC alongside your other RDS event coverage.

Remediation script · bash

# One SNS topic, then one RDS subscription per source type with the required categories.
TOPIC=$(aws sns create-topic --name ops-pager --query TopicArn --output text)

aws rds create-event-subscription --subscription-name rds-instance-critical \
  --sns-topic-arn "$TOPIC" --source-type db-instance \
  --event-categories "maintenance" "configuration change" "failure" --enabled   # RDS.20

aws rds create-event-subscription --subscription-name rds-cluster-critical \
  --sns-topic-arn "$TOPIC" --source-type db-cluster \
  --event-categories "maintenance" "failure" --enabled                           # RDS.19

aws rds create-event-subscription --subscription-name rds-pg-critical \
  --sns-topic-arn "$TOPIC" --source-type db-parameter-group \
  --event-categories "configuration change" --enabled                            # RDS.21

aws rds create-event-subscription --subscription-name rds-sg-critical \
  --sns-topic-arn "$TOPIC" --source-type db-security-group \
  --event-categories "configuration change" "failure" --enabled                  # RDS.22

# S3: EventBridge is the lowest-friction destination, no per-bucket policy needed.
aws s3api put-bucket-notification-configuration --bucket acme-customer-uploads \
  --notification-configuration '{"EventBridgeConfiguration":{}}'                 # S3.11

# Then smoke-test the wire: reboot a non-prod DB and confirm the page lands.
aws rds reboot-db-instance --db-instance-identifier staging-postgres-1

Full walkthrough (console steps, edge cases and verification) in the lesson Configure event notifications and subscriptions.

Is RDS.21 a false positive?

By a quirk of the rule, an account with zero event subscriptions passes RDS.21 — there is nothing to evaluate. The control only fails partial setups that have subscriptions for other source types but not for parameter groups.

Part of the learning path See what's happening
  • RDS.1 An RDS snapshot is shared publicly
  • RDS.2 An RDS instance is publicly accessible from the internet
  • RDS.3 RDS DB instances should be encrypted at rest
  • RDS.4 RDS snapshots should be encrypted at rest
  • RDS.5 RDS DB instances should use multiple AZs
  • RDS.6 RDS lacks enhanced monitoring
  • RDS.7 RDS clusters should have deletion protection
  • RDS.8 RDS DB instances should have deletion protection
  • RDS.9 RDS engine logs are not shipped to CloudWatch
  • RDS.10 RDS relies on long-lived database passwords
  • RDS.11 RDS instances should have automatic backups
  • RDS.12 IAM auth should be configured for RDS clusters