Inspect the current configuration with get-bucket-notification-configuration. Choose a destination (EventBridge as a central bus is the cleanest default); SNS, SQS or Lambda also work. Set up the required IAM and resource permissions before attaching, as the permission order is what usually breaks the first attempt. Attach the configuration and confirm S3.11 passes.

Compliance Medium severity

AWS Security Hub · S3

S3.11: Buckets should have event notifications enabled

Written and reviewed by Emnode · Last reviewed 27 May 2026

What does AWS Security Hub S3.11 check?

S3.11 checks whether a general-purpose bucket has an event notification configuration. It reports FAILED when the notification configuration is empty, so object-level changes trigger nothing.

Why does S3.11 matter?

Without event notifications, security-relevant actions like object creation or deletion happen with no automated reaction: no alerting, no downstream processing, no audit hook. Wiring notifications gives you a real-time signal you can route to monitoring or response tooling instead of finding out after the fact.

How do I fix S3.11?

Inspect the current configuration with get-bucket-notification-configuration.
Choose a destination (EventBridge as a central bus is the cleanest default); SNS, SQS or Lambda also work.
Set up the required IAM and resource permissions before attaching, as the permission order is what usually breaks the first attempt.
Attach the configuration and confirm S3.11 passes.

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

S3.11 only inspects the bucket's own NotificationConfiguration, so a bucket whose object-change visibility comes from somewhere else still reports FAILED even though it is fully monitored. Buckets watched through CloudTrail S3 data events, EventBridge's default bucket-level event delivery, or a centralised S3 Storage Lens / monitoring pipeline get their real-time signal without any per-bucket notification config; the control simply can't see that. By default the eventTypes parameter is empty, so any non-empty notification configuration makes it pass; where the monitoring genuinely lives elsewhere, document that and suppress the finding rather than bolting on a redundant SNS/SQS/Lambda target just to satisfy the check.

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

AWS documentation for S3 controls ↗ Check your own account for S3.11 →

Part of the learning path See what's happening

S3.1 Account-level S3 public access is not fully blocked
S3.2 Public S3 buckets expose data to anyone on the internet
S3.3 Buckets can be written to by anyone on the internet
S3.5 S3 is accepting unencrypted HTTP requests
S3.6 Bucket policy grants broad access to other AWS accounts
S3.8 Buckets can still be made public; Block Public Access is off
S3.9 No S3 access logs, so reads and writes go unaudited
S3.10 Versioned buckets should have lifecycle configurations
S3.12 ACLs should not be used to manage bucket access
S3.13 Buckets have no lifecycle rules and grow forever
S3.15 Buckets should have Object Lock enabled
S3.17 Buckets should be encrypted at rest with KMS keys