- Hi, my name Talia Nassi,
and I'm a senior developer advocate here at AWS Serverless.
This video is about building an event-driven application
with Amazon EventBridge.
In event-driven architecture,
services interact with each other through events.
An event is something that happened in your application.
For example, an item was put into a shopping cart,
a new order was placed.
Events are JSON objects that tell you information
about something that happened in your application.
In event-driven architecture,
each component of the application raises an event
whenever anything changes.
Other components listen and decide what to do with it
and how they would like to react.
When you build applications with event-driven architecture,
you decouple your event sources and event targets.
This can enable teams to act more independently
because your services are loosely coupled.
When you add new features to your applications,
you raise new events and then decide
on the event source and event target.
The event source is what emits the event
and the event target is what subscribes to
or receives the event.
Decoupling event sources and event targets
can greatly speed up development time
and it can simplify making changes to your application.
Decoupling your application can allow
for more seamless cross team collaboration.
For example, let's say you're a developer
at an e-Commerce company
and you're building a serverless e-Commerce application.
Your team is in charge of the account creation
and authentication process.
You build the login flow and raise an event
when a new user creates an account.
When the event is raised, other teams can be alerted.
The marketing team can listen
for the account created event and act on it.
For example, they can send promotional emails.
In this decoupled architecture,
event producers and consumers
don't have to know about each other.
They only have to listen to events and act accordingly
when they're interested in that event.
This can be speed up development
by reducing the complexity caused by building new features.
In event-driven applications, you have the event producer,
the event bus and the event consumer.
The event producer is the event source
that the events come from.
This can be an AWS service, it can be a custom event
or an event that comes from a third party SaaS app.
The event bus acts as an event router to route the events.
The event consumer listens for events
and acts only upon the events they're interested in.
In AWS, events are choreographed
through Amazon EventBridge rules.
A rule matches incoming events from an event source
and sends them to event targets for processing.
EventBridge accepts events from many different event sources
including over 200 AWS services,
custom events from your Lambda functions or applications,
and third party SaaS applications.
You specify an action to take
when EventBridge receives an event
that matches the event pattern in the rule.
When an event is raised that matches the rule,
EventBridge sends the event to the specified target
and triggers the action defined in the rule.
To route events from these sources to the correct target,
the events must be placed on a corresponding event bus.
There are three types of event buses.
The first type is the default bus,
which is always available in every account,
and it's where AWS events are routed to.
The second type is a custom event bus.
You can create custom event buses
for your own applications to meet your business needs.
Lastly, you can also create SaaS event buses,
which are created when you configure SaaS applications
as an event source.
There are many potential event targets.
Event targets are what the event bus routes to
once a corresponding event happens.
Targets include AWS Lambda, Amazon Kinesis,
AWS Step Functions, Amazon API Gateway,
and even event buses in other accounts.
This flexible design allows you
to create a wide variety of integration patterns
based on your specific needs.
This tutorial sends an event from Amazon S3,
the event source, to AWS Lambda, the event target,
using an event rule.
In this tutorial,
you learn how to configure events with EventBridge
by deploying an AWS Serverless Application Model template.
The AWS Serverless Application Model, or SAM,
is an OpenSource framework
for building serverless applications.
It provides shorthand syntax to express functions,
APIs, databases, and event source mappings.
SAM is an extension of CloudFormation,
which is the AWS infrastructure as code tool.
You define resources using CloudFormation
in your SAM template
and use the full suite of resources, intrinsic functions
and other template features
that are available in CloudFormation.
First, you're gonna upload images to an S3 bucket.
This raises an event which invokes a Lambda function,
which resizes the image and places it
in a different S3 bucket.
The only prerequisite for this tutorial
is to have the SAM CLI installed on your machine.
Note that if you're using Cloud9,
this is already installed for you.
First, navigate to the Serverless Land Patterns Collection
at serverlessland.com/patterns, filter by SAM,
and then choose the services EventBridge and S3.
Choose the pattern S3 to EventBridge to Lambda.
This SAM template deploys an S3 bucket,
a Lambda function, an EventBridge rule,
and the IAM resources required to run the application.
click on the cloning instructions to copy it.
Then paste the cloning instructions in your terminal
and run SAM deploy--guided to deploy the pattern.
Once the stack has finished deploying,
you'll see the success message.
Navigate to the EventBridge console
and choose rules from the left panel.
Then choose the rule that was created by AWS SAM
starting with SAM app.
The event source is S3, and the rule is invoked
when an image is put into the source bucket in S3.
Next, notice that the event target is the Lambda function
that you created from the SAM template.
Navigate to the S3 console
and choose buckets from the left panel.
Then choose the bucket that was created for you,
choose the properties tab
and note that the integration with EventBridge is on.
From the objects tab, choose upload and upload an image.
Navigate to the Lambda console
and choose your Lambda function.
Select the monitor tab and choose view logs in CloudWatch.
You can see the event
that triggered the Lambda function in the logs.
In the previous example, you add an EventBridge rule
that routes events from S3, the event source,
to Lambda, the event target, using an event bus.
Now let's add another rule.
From the EventBridge console,
choose rules and then create rule.
Enter a name and description for the rule.
Next, you'll need to define the event pattern
that's used to invoke the event targets.
For service provider, choose AWS,
and for service name, choose S3.
For event type, choose Amazon S3 event notification.
And in the event dropdown, choose object created.
You are configuring the event source
to be an object created in your S3 bucket.
Select either the default AWS event bus
or a custom event bus.
Select the event target.
In this example, I configure an Amazon CloudWatch log group.
Enter any name for the log group,
which is created automatically,
and then choose create.
Next, upload an image to the S3 bucket.
Navigate to the Amazon CloudWatch console
and choose log groups from the left panel.
Choose the log group and then choose a log stream.
You can see now that the event is logged to CloudWatch logs.
What's important to notice here
is that adding a second event rule
did not change the event source's behavior
or affect other event targets.
To learn more about event-driven architecture
and Amazon EventBridge, head to serverlessland.com,
where you'll find more content from me and my team.
I'm Talia Nassi.
Thanks for tuning in.