Skip to content
Ask AI about this
Help improve this page

S3 buckets should have event notifications enabled

S3 event notifications are how you trigger automated responses when objects are created, deleted, or modified. Without them, you lose visibility into bucket activity and can't drive workflows like malware scanning, data pipeline ingestion, or access alerting. A bucket without notifications is a blind spot.

In incident response, notifications routed to SNS, SQS, Lambda, or EventBridge deliver near-real-time signals when something changes. Relying on periodic polling or CloudTrail log analysis introduces lag that matters when sensitive data is involved.

Retrofit consideration

Existing buckets may already have notification configurations managed outside Terraform. Applying aws_s3_bucket_notification replaces the entire notification configuration for that bucket, which can break existing integrations without warning.

Implementation

Choose the approach that matches how you manage Terraform.

Use the compliance.tf module to enforce this control by default. See get started with compliance.tf.

module "s3_bucket" {
  source  = "soc2.compliance.tf/terraform-aws-modules/s3-bucket/aws//modules/notification"
  version = ">=5.0.0"

  bucket = "example-bucket-abc123"
}


module "s3_bucket" {
  source  = "pcidss.compliance.tf/terraform-aws-modules/s3-bucket/aws//modules/notification"
  version = ">=5.0.0"

  bucket = "example-bucket-abc123"
}


module "s3_bucket" {
  source  = "nistcsf.compliance.tf/terraform-aws-modules/s3-bucket/aws//modules/notification"
  version = ">=5.0.0"

  bucket = "example-bucket-abc123"
}


module "s3_bucket" {
  source  = "nist800171.compliance.tf/terraform-aws-modules/s3-bucket/aws//modules/notification"
  version = ">=5.0.0"

  bucket = "example-bucket-abc123"
}


module "s3_bucket" {
  source  = "nistcsfv11.compliance.tf/terraform-aws-modules/s3-bucket/aws//modules/notification"
  version = ">=5.0.0"

  bucket = "example-bucket-abc123"
}


module "s3_bucket" {
  source  = "pcidssv321.compliance.tf/terraform-aws-modules/s3-bucket/aws//modules/notification"
  version = ">=5.0.0"

  bucket = "example-bucket-abc123"
}

If you use terraform-aws-modules/s3-bucket/aws//modules/notification, set the right module inputs for this control. You can later migrate to the compliance.tf module with minimal changes because it is compatible by design.

module "s3_bucket" {
  source  = "terraform-aws-modules/s3-bucket/aws//modules/notification"
  version = ">=5.0.0"

  bucket = "example-bucket-abc123"

  eventbridge = true
}

Use AWS provider resources directly. See docs for the resources involved: aws_s3_bucket_notification.

resource "aws_s3_bucket" "this" {
  bucket        = "pofix-abc123"
  force_destroy = true
}

resource "aws_s3_bucket_notification" "this" {
  bucket      = "example-bucket-abc123"
  eventbridge = true
}

What this control checks

The policy checks that each aws_s3_bucket has a corresponding aws_s3_bucket_notification resource with at least one destination configured. Valid destinations are topic (SNS), queue (SQS), lambda_function, or eventbridge = true. A bucket with no aws_s3_bucket_notification referencing it, or one where all destination blocks are absent, fails. The bucket argument must reference the target bucket. Each destination block requires at least an events list (e.g., s3:ObjectCreated:*) and the ARN of the target resource. Setting eventbridge = true enables delivery to EventBridge without explicit event filters. Any single valid destination is sufficient to pass.

Common pitfalls

  • aws_s3_bucket_notification replaces all notifications

    The aws_s3_bucket_notification resource owns the entire notification configuration for a bucket. Apply a new one to a bucket that already has notifications configured outside Terraform, whether via the console or another stack, and it overwrites everything. Run terraform import first, or consolidate every notification definition into one resource block per bucket.

  • Missing destination permissions cause silent failures

    S3 needs permission to publish to the target. An SNS topic requires an aws_sns_topic_policy allowing s3.amazonaws.com to call SNS:Publish. An SQS queue needs an aws_sqs_queue_policy granting sqs:SendMessage. A Lambda function needs aws_lambda_permission with principal = "s3.amazonaws.com". Skip any of these and the notification configuration applies, but event delivery silently fails.

  • EventBridge mode has no event filter requirement

    Setting eventbridge = true on aws_s3_bucket_notification routes all S3 events to EventBridge without an events filter, which passes this control but can generate high event volumes. Create aws_cloudwatch_event_rule resources separately to route and filter what actually matters.

  • Prefix and suffix filters can create gaps

    Filter coverage is easy to scope too narrowly. A destination block limited to a logs/ prefix passes this control while leaving every other prefix in the bucket unmonitored. Before shipping, audit your filter_prefix and filter_suffix values against the actual object paths that matter for your use case.

Audit evidence

Check each in-scope bucket's notification configuration via the AWS Console (Properties tab) or aws s3api get-bucket-notification-configuration. A compliant bucket returns a non-empty response with at least one of TopicConfigurations, QueueConfigurations, LambdaFunctionConfigurations, or EventBridgeConfiguration. Custom or managed Config rules checking notification state provide continuous compliance evidence.

CloudTrail logs for PutBucketNotificationConfiguration show when notifications were established and by whom. Steampipe, Prowler, and Security Hub can consolidate per-bucket findings into a single view.

Framework-specific interpretation

SOC 2: CC7.2 expects monitoring of system components for anomalies. Event notifications on S3 buckets can cover the storage layer under Security criteria and, where applicable, Availability criteria, depending on what the bucket holds.

PCI DSS v4.0: For S3 buckets holding cardholder data, event notifications can tighten detection speed for object-level changes and feed into the monitoring objectives under Requirement 10 (Log and Monitor All Access to System Components and Cardholder Data). They don't satisfy all of Requirement 10's logging and audit trail obligations on their own.

NIST Cybersecurity Framework v2.0: DE.CM calls for continuous monitoring of assets for anomalies. S3 event notifications fit directly into this: they deliver near-real-time signals when object-level changes occur, which is exactly the per-asset detection signal DE.CM expects.

Tool mappings

Use these identifiers to cross-reference this control across tools, reports, and evidence.

  • Compliance.tf Control: s3_bucket_event_notifications_enabled

  • AWS Config Managed Rule: S3_EVENT_NOTIFICATIONS_ENABLED

  • Checkov Check: CKV2_AWS_62

  • Powerpipe Control: aws_compliance.control.s3_bucket_event_notifications_enabled

  • Prowler Check: s3_bucket_event_notifications_enabled

  • AWS Security Hub Control: S3.11

  • KICS Query: e39f87f5-0abf-488b-864c-63ee1f588140

Last reviewed: 2026-03-09