Create an SNS topic wired to your on-call fabric. Create an RDS event subscription with create-event-subscription --source-type db-cluster covering at least the maintenance and failure categories. Verify a test cluster event reaches the on-call channel. Encode the subscription in IaC so coverage persists across accounts and regions.

Compliance Low severity

AWS Security Hub · RDS

RDS.19: RDS cluster event notification subscriptions

Written and reviewed by Emnode · Last reviewed 27 May 2026

What does AWS Security Hub RDS.19 check?

RDS.19 is change-triggered against AWS::RDS::EventSubscription. It checks whether an existing subscription covers the DBCluster source type with both the maintenance and failure event categories. It passes if no subscriptions exist at all, and reports FAILED when subscriptions exist but none cover clusters for those categories.

Why does RDS.19 matter?

This is a detection-coverage gap, not an exposure. If a cluster fails over or enters a disruptive maintenance window and no one is subscribed to those events, the first signal is a customer complaint or a dashboard: minutes or hours of blind response on a production cluster. A failover learned about in thirty seconds is a non-event; the same failover discovered forty minutes later can mean lost transactions and an SLA credit. It maps to NIST 800-53 monitoring requirements.

How do I fix RDS.19?

Create an SNS topic wired to your on-call fabric.
Create an RDS event subscription with create-event-subscription --source-type db-cluster covering at least the maintenance and failure categories.
Verify a test cluster event reaches the on-call channel.
Encode the subscription in IaC so coverage persists across accounts and regions.

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.19 a false positive?

A subscription that only covers instance events does not satisfy RDS.19: the control specifically requires the DBCluster source type with maintenance and failure, so teams who "already have RDS alerts" can still fail it.

Full lesson Configure event notifications and subscriptions Step-by-step remediation with CLI, code and persona-specific context.

AWS documentation for RDS controls ↗ Check your own account for RDS.19 →

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