 |
We launched Amazon EventBridge in mid-2019 to make it easy for you to build powerful, event-driven applications at any scale. Since that launch, we have added several important features including a Schema Registry, the power to Archive and Replay Events, support for Cross-Region Event Bus Targets, and API Destinations to allow you to send events to any HTTP API. With support for a very long list of destinations and the ability to do pattern matching, filtering, and routing of events, EventBridge is an incredibly powerful and flexible architectural component.
S3 Event Notifications
Today we are making it even easier for you to use EventBridge to build applications that react quickly and efficiently to changes in your S3 objects. This is a new, “directly wired” model that is faster, more reliable, and more developer-friendly than ever. You no longer need to make additional copies of your objects or write specialized, single-purpose code to process events.
At this point you might be thinking that you already had the ability to react to changes in your S3 objects, and wondering what’s going on here. Back in 2014 we launched S3 Event Notifications to SNS Topics, SQS Queues, and Lambda functions. This was (and still is) a very powerful feature, but using it at enterprise-scale can require coordination between otherwise-independent teams and applications that share an interest in the same objects and events. Also, EventBridge can already extract S3 API calls from CloudTrail logs and use them to do pattern matching & filtering. Again, very powerful and great for many kinds of apps (with a focus on auditing & logging), but we always want to do even better.
Net-net, you can now configure S3 Event Notifications to directly deliver to EventBridge! This new model gives you several benefits including:
Advanced Filtering – You can filter on many additional metadata fields, including object size, key name, and time range. This is more efficient than using Lambda functions that need to make calls back to S3 to get additional metadata in order to make decisions on the proper course of action. S3 only publishes events that match a rule, so you save money by only paying for events that are of interest to you.
Multiple Destinations – You can route the same event notification to your choice of 18 AWS services including Step Functions, Kinesis Firehose, Kinesis Data Streams, and HTTP targets via API Destinations. This is a lot easier than creating your own fan-out mechanism, and will also help you to deal with those enterprise-scale situations where independent teams want to do their own event processing.
Fast, Reliable Invocation – Patterns are matched (and targets are invoked) quickly and directly. Because S3 provides at-least-once delivery of events to EventBridge, your applications will be more reliable.
You can also take advantage of other EventBridge features, including the ability to archive and then replay events. This allows you to reprocess events in case of an error or if you add a new target to an event bus.
Getting Started
I can get started in minutes. I start by enabling EventBridge notifications on one of my S3 buckets (jbarr-public in this case). I open the S3 Console, find my bucket, open the Properties tab, scroll down to Event notifications, and click Edit:
I select On, click Save changes, and I’m ready to roll:
Now I use the EventBridge Console to create a rule. I start, as usual, by entering a name and a description:
Then I define a pattern that matches the bucket and the events of interest:
One pattern can match one or more buckets and one or more events; the following events are supported:
- Object Created
- Object Deleted
- Object Restore Initiated
- Object Restore Completed
- Object Restore Expired
- Object Tags Added
- Object Tags Deleted
- Object ACL Updated
- Object Storage Class Changed
- Object Access Tier Changed
Then I choose the default event bus, and set the target to an SNS topic (BucketAction) which publishes the messages to my Amazon email address:
I click Create, and I am all set. To test it out, I simply upload some files to my bucket and await the messages:
The message contains all of the interesting and relevant information about the event, and (after some unquoting and formatting), looks like this:
{ “version”: “0”, “id”: “2d4eba74-fd51-3966-4bfa-b013c9da8ff1”, “detail-type”: “Object Created”, “source”: “aws.s3”, “account”: “348414629041”, “time”: “2021-11-13T00:00:59Z”, “region”: “us-east-1”, “resources”: [ “arn:aws:s3:::jbarr-public” ], “detail”: { “version”: “0”, “bucket”: { “name”: “jbarr-public” }, “object”: { “key”: “eb_create_rule_mid_1.png”, “size”: 99797, “etag”: “7a72374e1238761aca7778318b363232”, “version-id”: “a7diKodKIlW3mHIvhGvVphz5N_ZcL3RG”, “sequencer”: “00618F003B7286F496” }, “request-id”: “4Z2S00BKW2P1AQK8”, “requester”: “348414629041”, “source-ip-address”: “72.21.198.68”, “reason”: “PutObject” }
My initial event pattern was very simple, and matched only the bucket name. I can use content-based filtering to write more complex and more interesting patterns. For example, I could use numeric matching to set up a pattern that matches events for objects that are smaller than 1 megabyte:
{ “source”: [ “aws.s3” ], “detail-type”: [ “Object Created”, “Object Deleted”, “Object Tags Added”, “Object Tags Deleted” ], “detail”: { “bucket”: { “name”: [ “jbarr-public” ] }, “object” : { “size”: [{“numeric” :[“<=", 1048576 ] }] } } }
Or, I could use prefix matching to set up a pattern that looks for objects uploaded to a “subfolder” (which doesn’t really exist) of a bucket:
“object”: { “key” : [{“prefix” : “uploads/”}] }] }
You can use all of this in conjunction with all of the existing EventBridge features, including Archive/Replay. You can also access the CloudWatch metrics for each of your rules:
Available Now
This feature is available now and you can start using it today in all commercial AWS Regions. You pay $1 for every 1 million events that match a rule; check out the EventBridge Pricing page for more information.
— Jeff;
