-: So now let's talk about Amazon EventBridge
and what is EventBridge?
Well, it is the next evolution of CloudWatch events.
So by default, we have the default event bus
in EventBridge and is generated by default by AWS services
which is the exact same event bus
as the ones we get from CloudWatch events.
But EventBridge is an evolution, and therefore
we're going to get a partner event bus to receive events
from software service providers
or applications such as Zendesk, DataDog,
Segment, Auth zero.
You can also create your own event bus.
So it's called a custom event bus and it's for
your own application to send events through EventBridge.
These event buses can also be accessed
by other AWS accounts
and we'll see how thanks to resource policies.
Now with Event Bridge, we get enhanced features.
So we can actually archive events
with all of them or a filter sent
to an event bus for an indefinite or a set period.
That means that your events can be seen over time and saved.
And that's very, very handy in case you need to
actually replay these archived events
to see what went wrong or what went right.
Okay. And finally while EventBridge,
just like CLoudwatch events have rules
and rules say how to process the events and how to in
to which service we wanna redirect these events.
Another feature of Amazon EventBridge
I think is really good is schema registry.
So when events are sent to EventBridge
the service itself will analyze the events
in your bus and infer this schema
and this schema registry is going to generate code
for your application.
So that's your application knows
in advance how the data is structured in your event bus.
And this is what the UI looks like.
And then the schemas can be versioned
now I mentioned about cross account access.
And this is resource based policy for Amazon EventBridge.
So just like we have S3 bucket policies for event bridge
for S3 bucket, excuse me, or SQS resource policy for SQSQs
we can get resource based policy for Amazon EventBridge.
So we manage the specific permissions a bus itself.
And that means that thank to for example
a resource based policy We can allow
or deny events from other accounts or regions.
How does that work? Well, thanks to this.
We can, for example, aggregate into an
essential event bus all the events
from your organization or from different regions.
So let's take an example.
This is this account and it's going to
to be my central event bus
and I'm going to apply this resource based policy on it
which allows the action, put events from a principle
which is another AWS accounts.
So effectively we allow events from another
from another accounts.
And so the other accounts which is defined right here has
for example, lender function and that lender
the function can use the put events API
to send data into my central event bus.
And that is possible thanks to resource based policy.
So if we compare Amazon EventBridge
and CloudWatch events, while EventBridge builds
upon and extends CloudWatch events
it's the next evolution behind the scene.
It uses the same service API and endpoint
and the same underlying service infrastructure.
But then thanks to EventBridge.
As mentioned, we can extend our event buses to
have custom applications or third party SaaS apps
and event bridge has these schema registry capability
as well as replaying and archiving
and resource based policy.
So the name was said to something different
so that the new capabilities are marked in stone.
And so this is why CloudWatch events.
Now has the next evolution as Amazon EventBridge.
And over time, all the things in the material
that you see out there will have seen
the CloudWatch events name
be replaced with EventBridge over time.
In this course I will use interchangeably
EventBridge or CloudWatch events
except when I talk about a specific EventBridge feature.
Okay. So that's it for this lecture
I hope you liked it and I will see you in the next lecture.