S3 Event Notifications

Overview

S3 Event Notifications let you automatically react to events happening in your S3 buckets. When an object is created, deleted, restored, or replicated, S3 can send a notification to a target service that processes the event. This is the foundation of event-driven architectures built on top of S3.

The classic use case: a user uploads an image to S3 → S3 sends an event notification → a Lambda function generates a thumbnail → the thumbnail is stored back in S3. All fully automated, no polling required.

Events are typically delivered within seconds, but sometimes it can take a minute or longer. You can create as many event notifications as desired on a single bucket, each with different event types, filters, and destinations.

Event Types

S3 can generate notifications for many event types. You choose which events to react to:

You can also use wildcard events like s3:ObjectCreated:* to catch all creation events regardless of the method (Put, Post, Copy, or MultipartUpload).

Filtering by Prefix and Suffix

You can narrow down which objects trigger notifications:

This is useful when you only want to process certain types of files. For example, trigger thumbnail generation only for .jpg and .png uploads, not for .csv data files.

Four Notification Destinations

┌──────────────────────────────────────────────────────────────┐
│                S3 EVENT NOTIFICATION TARGETS                  │
│                                                               │
│                    ┌──────────────────────────────────┐      │
│                    │  1. SNS Topic                    │      │
│                    │     Fan-out to subscribers       │      │
│                    └──────────────────────────────────┘      │
│  ┌──────────┐     ┌──────────────────────────────────┐      │
│  │          │────▶│  2. SQS Queue                    │      │
│  │  Amazon  │     │     Decouple & buffer processing │      │
│  │    S3    │     └──────────────────────────────────┘      │
│  │  Event   │     ┌──────────────────────────────────┐      │
│  │          │────▶│  3. Lambda Function              │      │
│  │          │     │     Serverless processing        │      │
│  └──────────┘     └──────────────────────────────────┘      │
│       │           ┌──────────────────────────────────┐      │
│       └──────────▶│  4. Amazon EventBridge           │      │
│    (all events)   │     18+ destinations, advanced   │      │
│                    │     filtering, archive, replay   │      │
│                    └──────────────────────────────────┘      │
└──────────────────────────────────────────────────────────────┘

Traditional Targets: SNS, SQS, Lambda

When to Use Which Traditional Target

EventBridge Integration

EventBridge is the newer, more powerful option. When enabled, all S3 events are automatically sent to EventBridge (not just the ones you configure). From there, you create rules to route events to destinations:

┌──────────┐   ALL events    ┌──────────────┐   Rules    ┌──────────────────┐
│  Amazon  │────────────────▶│  Amazon      │───────────▶│  18+ AWS Services│
│    S3    │                 │  EventBridge │            │                  │
│          │                 │              │            │  - Step Functions │
│  Every   │                 │  ┌────────┐  │            │  - Kinesis Streams│
│  event   │                 │  │ Rule 1 │──┼───────────▶│  - Firehose      │
│  goes    │                 │  ├────────┤  │            │  - Lambda        │
│  here    │                 │  │ Rule 2 │──┼───────────▶│  - SQS, SNS      │
│          │                 │  ├────────┤  │            │  - ECS Tasks     │
│          │                 │  │ Rule 3 │──┼───────────▶│  - API Gateway   │
│          │                 │  └────────┘  │            │  - and more...   │
└──────────┘                 └──────────────┘            └──────────────────┘

IAM: Resource Access Policies (Not IAM Roles)

This is a critical distinction for the exam. S3 Event Notifications use resource-based policies on the target service to authorize S3 to send events. You do NOT attach an IAM role to S3.

┌──────────────────────────────────────────────────────────────┐
│              RESOURCE ACCESS POLICIES                         │
│                                                               │
│  S3 Bucket ──▶ SNS Topic                                     │
│                └── SNS Resource Policy:                       │
│                    "Allow s3.amazonaws.com to sns:Publish"    │
│                                                               │
│  S3 Bucket ──▶ SQS Queue                                     │
│                └── SQS Resource Policy:                       │
│                    "Allow s3.amazonaws.com to sqs:SendMessage"│
│                                                               │
│  S3 Bucket ──▶ Lambda Function                                │
│                └── Lambda Resource Policy:                    │
│                    "Allow s3.amazonaws.com to lambda:Invoke"  │
│                                                               │
│  ⚠️  NOT IAM roles — RESOURCE-BASED policies on the TARGET!  │
└──────────────────────────────────────────────────────────────┘

These resource-based policies work similarly to S3 bucket policies — they define who (which AWS service or principal) can perform which actions on the resource. The key difference is that the policy lives on the target (SQS queue, SNS topic, Lambda function), not on S3.

Hands-On: S3 → SQS Event Notification

Step-by-Step Walkthrough

1. Create an S3 Bucket

Create a new bucket (e.g., my-events-demo-bucket) in your preferred region. Default settings are fine.

2. Create an SQS Queue

Go to Amazon SQS → Create queue → Name it DemoS3Notification → Create with default settings.

3. Update SQS Access Policy

This is the critical step that most people miss. Go to the SQS queue → Edit → Access Policy. You need to allow S3 to send messages to this queue.

Use the AWS Policy Generator:

• Policy Type: SQS Queue Policy
• Effect: Allow
• Principal: * (any principal — permissive for demo purposes)
• Action: SQS:SendMessage
• ARN: paste the SQS queue ARN

The generated policy looks like:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": "*",
      "Action": "SQS:SendMessage",
      "Resource": "arn:aws:sqs:eu-west-1:123456789012:DemoS3Notification"
    }
  ]
}

"Condition": {
  "ArnLike": {
    "aws:SourceArn": "arn:aws:s3:::my-bucket-name"
  }
}

4. Create Event Notification on S3

Go to S3 bucket → Properties → scroll to Event Notifications → Create event notification:

• Name: DemoEventNotification
• Event types: All object create events (s3:ObjectCreated:*)
• Destination: SQS Queue → select DemoS3Notification
• Save changes — this time it succeeds because the SQS policy allows S3

S3 sends a test event to verify connectivity. You'll see a test message in the SQS queue.

5. Upload a File and Verify

Upload any file to the S3 bucket (e.g., coffee.jpg). Then go to SQS → your queue → Send and receive messages → Poll for messages.

You'll see a message with the event payload:

{
  "Records": [
    {
      "eventVersion": "2.1",
      "eventSource": "aws:s3",
      "eventName": "ObjectCreated:Put",
      "s3": {
        "bucket": {
          "name": "my-events-demo-bucket"
        },
        "object": {
          "key": "coffee.jpg",
          "size": 12345
        }
      }
    }
  ]
}

The eventName is ObjectCreated:Put and the key is coffee.jpg — confirming the event notification is working.

6. Enable EventBridge (Optional)

In the same Properties section, under Amazon EventBridge, click Edit → set to On. Once enabled, all events from this bucket are automatically sent to EventBridge. You can then create EventBridge rules to route events to any of 18+ AWS services.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": "*",
      "Action": "SQS:SendMessage",
      "Resource": "arn:aws:sqs:eu-west-1:123456789012:DemoS3Notification"
    }
  ]
}

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": { "Service": "s3.amazonaws.com" },
      "Action": "SQS:SendMessage",
      "Resource": "arn:aws:sqs:eu-west-1:123456789012:DemoS3Notification",
      "Condition": {
        "ArnLike": { "aws:SourceArn": "arn:aws:s3:::my-bucket-name" }
      }
    }
  ]
}

Event Delivery Characteristics

S3 Event Notifications vs EventBridge — Decision Guide

┌─────────────────────────────────────────────────────────────────┐
│  Do you need advanced filtering (metadata, size, JSON fields)? │
│  ├── YES ──▶ Use EventBridge                                   │
│  └── NO                                                        │
│      │                                                         │
│      Do you need more than SNS/SQS/Lambda as destinations?     │
│      ├── YES ──▶ Use EventBridge                               │
│      └── NO                                                    │
│          │                                                     │
│          Do you need to archive/replay events?                 │
│          ├── YES ──▶ Use EventBridge                           │
│          └── NO ──▶ Use Traditional Event Notifications        │
│                     (simpler setup, lower overhead)             │
└─────────────────────────────────────────────────────────────────┘

Questions & Answers