Setting a notification on S3 helps you react instantly to object changes, security events, and operational signals. With AWS services and native bucket features, you can route these events to email, chat, or custom workflows.
This guide walks through creating, testing, and managing S3 notifications using event-driven features available in the console, CLI, and infrastructure as code. You will learn practical steps for common use cases and how to troubleshoot delivery.
| Notification Type | Destination | Trigger Event | Use Case |
|---|---|---|---|
| Object Created | Amazon SNS | s3:ObjectCreated:* | Alert stakeholders when new files arrive |
| Object Removed | AWS Lambda | s3:ObjectRemoved:Delete | Clean up related resources or index entries |
| Reduced Redundancy Lost Object | Amazon SQS | s3:ReducedRedundancyLostObject | Prioritize recovery for storage class events |
| Object Restore Completed | EventBridge | s3:ObjectRestore:PostEvent | Track archival retrievals from Glacier |
Configuring S3 Event Notifications
Console Setup Steps
In the S3 console, open your bucket and choose Properties, then Event notifications. Create a new rule, assign a name, and select the events you want such as object creation or deletion. Specify a destination like an SNS topic, Lambda function, or SQS queue, then save the configuration.
CLI and Template-Driven Workflows
Use the AWS CLI to define notification configurations as JSON, which keeps settings version controlled. A template-driven pipeline can apply the same event rules across dev, test, and production environments, reducing manual errors and supporting automated reviews.
Choosing the Right Destination
SNS for Broadcast and Alerting
SNS enables you to fan out one event to multiple subscribers including email, SMS, HTTPS endpoints, and other SNS topics. This pattern suits audit alerts, incident response pages, and operations dashboards where many teams need visibility.
Lambda for Real-Time Processing
Lambda runs code in response to S3 events, allowing you to resize images, scan files, update metadata, or trigger downstream workflows. Ensure your function has minimal cold starts and appropriate permissions so notifications are processed reliably and at scale.
Monitoring and Troubleshooting
Delivery Health and Metrics
Monitor CloudWatch metrics for number of notifications sent, errors, and throttles. Enable server access logs and data events for deeper insight, and use dead-letter queues for destinations that fail repeatedly to reduce lost events.
Operational Best Practices
- Define clear naming conventions for event rules, SNS topics, and Lambda functions
- Use infrastructure as code to keep notification definitions versioned and reviewable
- Implement dead-letter queues and alerting on delivery failures
- Test events in a staging environment before promoting to production
- Limit event payloads to essential metadata to reduce downstream processing cost and latency
FAQ
Reader questions
Can I filter notifications so that only specific prefixes trigger an event?
Yes, define an S3 event filter with a prefix or suffix so that notifications fire only for objects matching those path patterns. This keeps traffic and costs down and avoids processing unrelated files.
What happens to notifications if my destination endpoint is temporarily unavailable?
S3 retries delivery for failed events, with retries lasting up to several days depending on the destination type. For critical flows, pair notifications with a dead-letter queue to capture records that cannot be delivered after retries.
How do I secure credentials and permissions for S3 notifications?
Use least-privilege IAM roles and bucket policies, and avoid long-lived access keys. Encrypt environment variables, rotate credentials regularly, and validate resource-based policies so only intended services can assume roles.
Can I send the same event to multiple destinations without duplicating configuration?
Yes, publish events to an SNS topic and subscribe multiple endpoints to that topic, or configure EventBridge rules that target different services. This centralizes event control and makes it easier to add or remove consumers later.