Deep Dive on Amazon EventBridge - AWS Online Tech Talks

Key Takeaways

hi folks thanks so much for joining our deep dive on Amazon event bridge today I'm really excited to be talking to you about event bridge and going through a couple of use cases that we think will be helpful in showing you how to use the service and how to build your own applications using it a lot of what I'll talk about today revolves around the concept of event-driven architectures and we think this is really important because we've seen that once customers start using the design pattern they love it it makes their team so much more agile it makes it's so much easier to build scalable reliable and resilient systems so try to keep that context as we go through the rest of the slides and the demos today Allyson event bridge is an event bus service that makes it easy to ingest and process data from AWS services your own applications and from SAS apps it removes the friction of having to write point-to-point integrations between services and it's fully managed so we take care of all of the scaling and you only pay for what you what you use so you're charged for events that get published to your event bus for the agenda today we're gonna be running through a couple of demos I'll start off first with an overview of event bridge and how that all works from there I'll jump into a demo of a simple event-driven application and how you can build one yourself we'll then look at how to use API gateway to receive web hooks from stripe a payment processing company and then send those web hooks events to event bridge lastly we'll take a look at one of our partner integrations with Zendesk and show you how to really easily do sentiment analysis on a support ticket that's generated in in Zendesk so starting off with a high-level overview of the different parts of event per agent and kind of how all of those work together the first part that we'll take a look at is an event source and these can be any of 95 AWS services that we support on event bridge custom applications like the ones that you write yourself or SAS applications for SAS applications we have a special special resource called an event source and these provide a logical connection between the partners system and your AWS account without the need to provision or manage cross account I am roles or credentials from there the core of event of event bridge on our event buses if you're familiar with cloud watch events default event bus this is exactly the same thing except that you can create your own custom event buses as well as an event bus dedicated to ingesting partner events once you have an event bus setup you can then create rules and associate rules with that event bus rules allow you to match against values in the metadata or the payload of the events that are ingested and determine which event should get routed to each destination so if you take a look here on the left is an example of an event that enters into our system in this case it's a ticket created so it comes from a particular partner and it's got a payload with the ticket ID the department in which the ticket was created and the user associated with that so on the right hand side here's an example of a rule that we might write and this rule is looking at a particular partner and it's a very basic rule just says any events that come from this partner should trigger this rule so on the left hand side because we see that our event is from that same partner this rule will get triggered making the rule look a little bit more advanced we can add the fact that we're looking either for the billing department or the fulfillment department so if an event comes in and this one on our left has the billing department we know that it'll match against this rule because the billing department is specified in in the rule and then here's an example of a ticket that won't actually match against this particular event I'm sorry a rule that won't match against this event we can see that this rules looking for the ticket resolved but our events on the left hand side is ticket created so that's a bit of background on how rules work we'll jump into that a lot more just now finally once a rule is triggered you can associate multiple targets with that rule and targets are used to send that event to various AWS services so you could do things like invoke a lambda function put a record on a Kinesis data stream or firehose start the execution of a step function workflow or start an ICS or Fargate task there are up to 17 different targets and we're adding to those all the time and so lots of different places you can send your events a quick note on limits our published public limits show that there are that there's a limit of 400 TPS for the put events API that's sending events to an event bus and 750 invocations per second we also limit the number of rules on each event bus and the number of event passes per account I must stress that all of these limits can be increased so 400 TPS especially is one that customers often run into as being a bit too low and we have plenty of customers during tens to hundreds of thousands of TPS with event bridge so if you have a use case that's gonna need large limits than the default ones here please just submit a limit increased request the other thing that we hear customers asking us a lot about is the difference between event bridge and SNS SNS is a great and popular pattern for creating event-driven applications so how does event bridge compare I think that the three most important areas to take a look at our fan-out filtering and latency so for fan-out if your habit you have a use case where you need to send an event to millions of different subscribers then SNS is really well suited to that event bridge allows you to fan out to five targets per rule and of course you could add multiple rules but the use case is not really for event bridge is not really to fan out to thousands or even more than hundreds of targets per particular event on the filtering side event bridge allows you to apply a rule against the entire body the entire payload of an event whereas with SNS you can only filter on the message of tributes lastly latency on event bridge the median latency is five hundred and sixty milliseconds in u.s. East one whereas for SMS it's 25 milliseconds so if you have a use case lies on very low latency processing of events then you might find that SNS and slightly better suited to that okay so we're now going to talk a little bit more about building a very simple event driven application you've probably seen some version of this slide before and many of your applications are likely moving from monomers to micro-services monoliths are difficult to scale both in terms of the throughput as well as the teams that support them if you have a big complex system and you want to be able to effectively leverage dozens or hundreds of engineers to build features in parallel you have to move to a micro services model so if you've made the move to micro services you've probably kind of seen this architecture before this is a ready standard synchronous API based service in the case when a client makes a request to the order service it has to make a downstream request to the invoice service and once it gets a successful response it can respond back to the client with a success message provide a confirmation number and the customer in this case is happy and that works really great if you've got a nice simple system like this but what happens when you start adding a couple of more services to this and other services that want to integrate with your order service and there's nothing wrong with that having a lot of systems that are interested in that data is is totally normal and unexpected but what is problematic is that in an API orientated design is that the order service needs to know about all of these other boxes we talked a lot about how great micro services are because they are decoupled but the owner service still needs to know and locate each of these other endpoints for these services it needs to understand how to make the appropriate API calls what to do if one of those fails and it needs to have appropriate retry logic and error handling and all of that stuff baked in for each of these underlying services that it connects to and that might be ok for three services but again over the longer term you're going to want to add more and more systems that take this data from take from this order service and each time you have to do that those downstream teams are beholden to the order service team to implement that for them so now with event-driven applications our architecture looks a little bit different something like this the order the service here sends an event to event bridge which is configured with a set of rules that determine which downstream service gets a copy of each event so there may be some targets that only care about certain types of events or that only care about orders for a particular account or maybe they want to hear about all events that are getting published by their auto service either way the router in this case event bridge now takes care of the complexity of ensuring these events get propagated appropriately to each downstream service so if another team comes along and decides that they want to consume some subset of the auto services events they can just add a new rule to event bridge without having to wait on the order service team to make an update for them so this allows all of these service teams to act more independently and move faster I'm gonna hop over now shortly to a demo of event bridge and how you can actually build the service similar to this so we're gonna look at the order service and how to send events from a lambda function which is functioning as our order service send those to event bridge and then from there how to consume them as the forecasting service so I'll switch over to my screen share now and you can see here I've got a lambda function it's very basic it requires the AWS SDK with event bridge and we start off by creating the static order over here in your version this order might come from some other place perhaps from an API request from a customer and but for our purposes we're going to start simple and just hard code that order in here so you can see the orders got an order number it's got a product ID a price and then some details about a customer from there we then create the event bridge client using the SDK that we've included above and we say that we're using region US East one just a quick note it is important to include this SDK and not to use the one built in with lambda because lambdas current version doesn't yet support event bridge so make sure you include that SDK manually yourself from there we're going to go ahead and then construct the actual event itself and event bridge events have a particular envelope that we need to follow so there are a couple of required fields the one is the source the next is the detail type which just explains what this particular event is the detail itself and that will contain our payload and then the event bus that we want to send this to so you can see here we've got our order details up above we're just including that in this detail section that's our payload of of our event and then the function simply just puts out the response that we get after we after we send that event so really simple and pretty basic one of the things you'll notice here is that I've got a I've got the section to update the event plus name so I'm first gonna go and actually create an event bus for this particular service I've created the the API command already or the CLI command already but very simply I call the AWS events method and I passed the create event pass action I give it a name and in this case we've called the event pass orders I've also just included my profile so that it sorts on my credentials so when I do that you'll see that I get an event pass on back and that means that my event bus has been created so I can go back to my code here I'm going to update this with the event bus that we'll be using for this service so we call it orders now that I've updated my lambda function I just need to package that up and send it back to two lambda so that we get the correct version so I'll quickly run that command that's our function and then we simply upload it to lambda and update the function code so if I head over to lambda now I'll see that my function is showing I'll just do a quick refresh and you can see we've got that eventbus name of orders added here so what we want to do quickly here while we're just in this in the lambda section here is to double check that we've got all of our permissions set up correctly you can see that because I'm calling Amazon event bridge I need to actually set up permissions for this lambda function to do that so the way that I do that I've done it already but I'll explain it quickly here is to just scroll down to the execution role and view the order services role so I you can see here I've attached a policy and added the Amazon event bridge full access policy so that will allow my lambda function to put events to the event bridge event bus so now that the the function is set up I can actually invoke the function and send make sure that it's sending an event through to Amazon event bridge you so there we go in working my lambda function and you'll see here it's a little bit difficult to pass but we got a response that we echoed out which had zero failed entries and we got a particular ID for the the entry that we sent through so that means that the event has been sent to event bridge but because we don't have any rules added yet that event gets dropped nothing happens with it so if I go to my orders event bus in in Amazon event bridge we can see that there are no rules created so what I'm going to do to just make sure that we're actually getting that that event being sent through is to create a catcher or rule that sends my events to cloud watch logs so I'll call this catch all and it's for the invoice service or for the order service let's make it and then I'm gonna match against a very broad rule pattern so here I'm saying all events that come into this event bus so you can see the pattern that gets generated is saying anything in the isn't that's an event with my account ID will match against this rule we then head down to the target section just quickly making sure that we've selected the correct event bus here so I want the order's event bus and then to the target section so here we can choose cloud watch logs and we will put it in order catch-all so I go ahead and create my rule and we can see that's being created so if I now head over to card watch logs I'm just a quick refresher we have that log group for the casual so I'll go back to my lambda function and simply invoke that so now what happens is my lambda function runs it calls the put events API call we see that it's successfully sent that event and if I go back to my cloud watch logs and refresh that you can see that a new logs been added and there is my event so a couple of fields get added to the event automatically by the system things like account the time I didn't specify so the system takes care of that and the region but my payload that we included that has been added here and we have it the order service as the source and the detail type as new order so that's great we're receiving events on the event bus and we can see them coming through but now we want to do something a little bit more interesting with them we want to send them to the forecasting function so if I go back to lambda I have a forecasting function that I've set up here and this is super basic all it does is receives an event it echoes that event out and then it leaves all the hard work to someone else someone else can come and do the with the fancy forecasting function now before I send an event and create a rule to send to this forecasting function I go back to my lambda code and I realized hmm I'm actually sending some customer information here that might be a little bit too sensitive to send to the forecasting service it's not really needed by that service and ideally I don't want customers addresses floating all over the place so what I'm actually going to do here when I create my rule is use a input transformation to ensure that I only send the relevant parts of the event to that forecasting service so we'll go back to event bridge and create a new rule and we'll call this forecasting service tidy that up a bit and we're gonna match against a specific pattern so in this case we're actually looking for a pattern where we're not wanting to get all events sent to our forecasting service instead we're actually looking for a subset we actually only want events that are from the order service and that are the new order event so the way we do that is by sibi writing up a rule that matches that pattern so we can check that out here by just copying this predefined text that I have so all this says is look for the source of where it's the order service and the detail type that is a new order and I can save that now you might be wondering how do I make sure that I've actually got that rule correct like how do I make sure that it's working correctly well a WS event bridge provider Amazon event bridge provides an API endpoint called the test event had an endpoint and that allows you I'll just put it out here it allows you to pass an event pattern that you've created so this is the event pattern that I've pasted into my rule over here and then it allows you to provide an event and you can see this section is actually just a copy of my event so I I had that event sent through to card watch logs here I can copy that and just paste it into this event section so what I do now is I hit enter on that and I get a response from this test event pad an endpoint that says true so that means that the the rule that I've or the pattern that I've created there will actually match against this particular event so a good way to make sure that the rule that you're creating actually has the correct pattern is to use that API endpoint to test it against the the events that you're actually generating so I now go down and I select my lambda function as the target so that is the forecasting service and as I mentioned earlier I want to configure the input so that I don't send the entire event which is the matched events option here I send just a subset of it so to do that event bridge provides an input transformer that first that lets me set an input path and then from there to generate a template so again I've made a sample one here that I'll copy/paste across and I'll walk through those shortly okay so our first line here is talking about the sending out the fields in our event that we're actually interested in so we talked about the order number field and we map that to the details section of the event and then the order number section and if you go back here you can see that the way that that works is this is our event we have the details section and then as a subsection of that is the order number and we do the same thing for price and for the product ID so that just allows us to access those particular fields in the event JSON that comes in the next part allows us to then construct the actual JSON that we'll send to the forecasting service so here we just take those variables that we've used in the in the field above if we wanted to for some reason rename those variables we could do that those fields we could do that here so if instead the forecasting service expected something like order number we could do that like this over here so once I've added that input transformer I'll create the rule and that rule has been created so what I'm now going to do is generate that event again it'll match against our casual rule and be sent to our cloud watch logs but then we'll also get it to get sent to the forecasting service and the forecasting service remember very simply just echoes out that event so what we'd be hoping to see in the forecasting service is just a couple of those fields that we've specified coming through so I'll go back and invoke my lambda function this calls the put events from our order service we saw that earlier that sends it to the event pass the event the rule on the event pass matches against our particular rule and if we go through two carwash logs and take a look at that lambda function we'll see the events has started so let's give it a few more seconds there it is so we have the order number the Product ID and the price so you can see we've gone from an event that had a whole bunch of additional information that we actually didn't really want to send to the forecasting service and we've removed that using an input transformer great so I'll head back to my slides now so as we saw we created an order service which was a very basic lambda function that emitted an event using the put events API call from the Amazon AWS SDK that got sent to event bridge we had a rule first of all just to help us with some debugging that stored all events in Converse logs and then we created another rule which had an input transformer on it and allowed us to send only a part of that event to the forecasting service so that's a very basic example of building an event from an app if in the future we wanted to add the performance service or the invoicing service they could simply come along and create a new rule on that event bus and determine which events they're they're looking for using that rule and send it to a target that works for them great so now we're gonna hand step over to the next section which is around handling web hooks so a lot of customers have control over the applications they can determine how they send them when they send those events that are being generated by the applications but in some circumstance you can't and you have a third party system that's sending your events in this particular case I'm using stripe which is a payments processing company to receive events from customer from new payment events from customers so someone signs up to my service and in this case we'll say it's a subscription service whenever they start their subscription stripe sends me a web hook event for the invoice being created so I no need to have some sort of a way of capturing that web hook and the most common way to do that is through Amazon API gateway and from Amazon API gateway I actually want to send that event to event bridge and you can imagine that there may be a lot of different events that are coming from stripe so I might want to just put some of those through kinesins firehose into Amazon s3 just so that I have an order trail and a log of all of the events that are being sent to me from stripe but I also in this particular case because this invoice is being created I might want to generate an email to the customer to say hey your invoice has been generated here's some more details for you so for that I'll match against the invoice created events with a rule and send those to a lambda function so for this example we're gonna hop over again back to our browser tell screen share and I have the stripe application here so you can see in the web hooks section I have a web hook set up I'll delete that quickly just so we can start right from from scratch and stripe allows me in my developer console to go and create a new web hook and I can specify which events I want to receive so I might want all the invoicing events I might want all of the customer events so I've selected all of those it's gonna send me 29 events but strikes looking for an endpoint URL to send those events to so what I'm gonna do now is head over to API gateway and create a new API for that's facing the public facing on the internet for stripe to send those events to so I'll click get started here and create a very basic API so we'll call this stripe web hooks and hit create allow add a resource which is the web hook resource and then from there add a new method on that so stripe uses a post method to send web hooks so I'm gonna select post over here so what I have now is a is an API with an endpoint and and that can receive post requests but when I receive that event that web hook from stripe I want to actually send that to event bridge so the way I do that is by selecting AWS service as the integration type I then choose my region so I'm working in US East one at the moment and I choose which service I want to send it to so API gateway still calls of M bridge card watch events as event bridge was previously based on how much events that's when the naming comes from it uses the same API endpoints and the same functionality that existed in card watch events still exists in event bridge so you'll use that on the dropdowns here I'll select any method for the HTTP request and then the action I want this to perform is the put events action so now what you'll see is that API gateway needs an execution role with which to use when calling our put events command or API command on Amazon event bridge so to set that up I head over to I am and I've created a role already but it's very easy for you to do so yourself and then you simply attach the Amazon event bridge full access policy to that role so I got that roll here I'll copy it and head back to API gateway and paste in that that particular role so what I do now is save and that create sets up that post method for me but I'm not quite finished in order to get those events to flow through to to Amazon event bridge the next thing I have to do is just make a little bit of a tweak to the headers and to the template that's used to send the event from API gateway to come as an event bridge so if I go into HTTP headers there's two headers that I need to configure in order to have event bridge accept the request from API gateway the first is the xmz target so I'll paste that in and I've got to set that to the action that were wanting API gateway to perform which in this case is put events after that I need to specify the content type so stripes and the the request to API gateway is application JSON but what we need to send to event bridge is slightly different from that so let me show you that here we use application /x - MZ - json and the version that we're using there so these are ready critical to set in order to get api gateway to use the correct headers when making a call to event bridge the next part that we need to look at is the mapping template so if i head over to the stripe documentation you can see a little bit of detail here on what an invoice request from stripe will look like it's got an ID it's got an object it's got the account that it's related to it's got a whole bunch of details about the customer so there's a whole lot of information that stripes going to be sending through here but the problem is that they're not going to do it using the envelope that event bridge requires so if I go back to that order service that I covered earlier this is kind of the structure that we need to send an event to event bridge in we have to have the source the detail type the event pass name and then that stripe webhook request can all go into the detail section of the envelope so to achieve this we're going to do a bit of a transformation between API gateway an event bridge to do that I come in here and I click add mapping template and I'm saying that I want this template to apply whenever we receive an event from or a request on API gateway that is of content type application JSON I then go down to this section over here and define my mapping template so I've created that already but I'll walk through it quickly here so this sets our input route and then you can see I've constructed that envelope of the Amazon event bridge event that we need it has the outer entries which has an array of entries so you could match a number of events in this case we're gonna just send a single entry that entry has a detailed type and you can see what we're doing here is we're saying that we want the detail type to match to the type field that gets sent through with a stripe web work request we're hard coding the source to stripe because we know that all the events that come to this end point of from stripe and then we specify the event path name so I've created an event pass already called stripe payments lastly we set the detail section remember that's all payload of the event to the actual entire event that we receive from stripe but just to make sure it all works correctly we actually have to escape that JSON when we include it in here so I'll hit save and we now have API gateway receiving an event from stripe and sending that on to event bridge in the particular structure that event bridge needs so the last thing I'll do here is just deploy this API and that'll give me a URL that I can use for stripe so here is my URL I'll copy all of that and then head back over to the stripe dashboard so I can now paste in my endpoint URL I created that method was the web hook method but as we set up earlier here all of the events that I've told stripe that I want to receive so I add that endpoint now if stripe were to send me any web book events at this stage they would go from API gateway to Amazon event bridge but because I don't have any rules set up I won't actually see those events and they'll get dropped so like we did earlier I'm gonna head back to event bridge and create a rule that catches all of the events from stripe that'll allow us to do some debugging and make sure that the events are coming through correctly so I'll call that catch-all and we're gonna go for a ready broad pattern as we did earlier and then we'll head down to the target section and choose much-loved group and we'll call this the stripe catch-all so if I head over to card watch logs now and just refresh those we've got this striped catch-all section over here and at the moment there's no logs in that particular log stream so to generate an event from stripe I can go into their dashboard I'm using the test dashboard here and I can go into the subscription section and create a new subscription so this allows me to select my customer I've previously created a customer I've also previously created a product so I'll select that monthly pan that I've created and it's got that particular customers tests payment details as well so I'll hit the start subscription button and what happens in the background now is stripe sends a webhook request and in this case it might be multiple web requests to that endpoint that we specified in this web book section over here so what I expect is if I go to cloud watch logs and I hit refresh here we should have a couple of new entries and so if I just order those on time and go to the latest one here we can see the most recent one that stripe sent us was a subscription created event I suspect if we go through these we'll see a couple of other ones for the invoice created so there's the invoice created and you can see that the structure of the event that we received has these fields that we set in that mapping template in API gateway so the detail type matches against the type that stripe sent through in their webhook if I scroll down you can see the the type here is invoice created so that's use right up at the top in our detail type section we then hard-coded the source to stripe and the detail section over here contains all of the details all of the data that stripe sent in there webhook request API so this is super cool we're now getting all of our events coming through from API gateway directly to event bridge but I want to go back because logging all of our events and CloudWatch logs is not exactly what we wanted to do we first wanted to send those events to Kinesis firehose so that they could get stored in s3 for auditing purposes so I'll go back to my catch-all rule and edit that and in my target section I'll remove that target of Car Wash logs and add a new target I can put in Kinesis actually I'm looking for a firehose stream and I've previously created a firehose stream for this particular set of events so what Kinesis firehose will do is take all of the events sent from event bridge and store them in an s3 bucket that I've set up previously that way if at any point in the future we need to do an audit of the events we received from stripe they're sitting in s3 for us to use so I'll update that rule and we're now sending all of the events from stripe 2 to that Kinesis firehose ok so the next thing that I want to do is run that lambda function that does sends the invoice to our customers so I have a lambda function here and you can see that it's very basic it simply outputs the event that it receives so it logs that and we've got that lovely to-do to send the invoice to a customer so we could do something a lot more fancier here to generate a really nice-looking PDF or email but we're gonna keep it simple for this case so to match against this particular invoice created event I go back to event bridge and I create a new rule I'll give this this rule name the invoice rule and we're to match against a very specific pattern so here we are looking for a source being stripe which we set all of our bands to earlier and we're looking for the invoice created detailed type so we want to ignore all other requests or other webhook requests from stripe and simply focus on this invoice created one so I had saved there I make sure I'm on the correct event bus and then I choose my invoice service lambda function so I'll go ahead and create that and you can see that rule is now enabled so if I head back to stripe and I create a new subscription again select customer choose the product and create the subscription we'll see again if we go back to all I'll catch all or actually sorry we can't see it here because it's now being sent to Kinesis firehose so while I'm in this log group I will go to my invoicing service you can see that it's got an entry that's just come through now and if I expand that you can see it echoed out the full details of that invoice created event that got sent from stripe so if I look into this text I can see the detail type is in Boise created and this was echoed out by our invoicing service so if I head back to my slides now you can see that we have sent a event from stripe when our invoice was created that has gone to API gateway we've set up an API gateway endpoint that will then send the event to Amazon event bridge it does that transformation to make sure that it's using the correct envelope that event bridge expects and we've added those headers so that the request from API gateway to event bridge actually is able to succeed and is called correctly from there we've created a rule that will store the all of the events as an order plug into s3 using Amazon Kinesis data firehose and then we've added another rule that takes our invoice created events and runs a lambda function so a really cool way to receive events from any application that's generating web hooks and send those over to event bridge so that any team in your organization can start using those events for whatever needs that they have great we're gonna now hop into our last demo which is around connecting Zendesk tickets from Zendesk which is a support ticketing tool and doing sentiment analysis on those tickets so the kind of use case for this is potentially you have tickets that are getting created in your company and you want to understand which of those should be high priority potentially you have managers that should get involved with certain tickets and you might say that while tickets that have negative sentiment where customer is clearly upset and angry need to be prioritized but to do that manually you would have to have someone sitting there and assessing the the kind of sentiment of the ticket and then updating the priority of the ticket so instead what would be really cool is if we could use Amazon comprehend which does sentiment analysis to automatically look at that ticket sentiment and update the ticket if it has negative sentiment so how would we do this if we didn't have a vent bridge one of the ways of bridging the gap between Zendesk alsace application and our downstream micro-services would be to do something like web hooks and we saw that happening with stripe so we could get Zendesk to send events - as an API gateway and from there to a lambda function which then does the sentiment analysis and that works okay but we've seen that there's a bit of effort there in getting api gateway to actually send those events to amazon a bit bridge the other way that we can do it is by polling Zendesk s-- api and this is a fairly common approach to getting data out of systems having a scheduled lambda function run on a certain frequency and check the API Zendesk s-- API for any new tickets that have been created and again that works okay but it's a fair amount for us to have to manage we have to make sure that that polar keeps running if the API changes we have to handle that we have to think about API authentication so there's a fair amount of work there to just keep that infrastructure kind of going so the question is is there a better way and I suspect you'll know the answer we think that there is so again if I switch back to my screen share and you can see here that I'm on the Amazon event bridge page and we saw those concepts we talked about earlier the event buses and and the rules but we have this third section here which is partner event sources so partner event sources allow us to go in and connect a third party partners such as Zendesk and to start receiving events directly onto an event pass from those particular partners without the need to do any polling or to set up API gateway to receive web hooks so I'm gonna click on Zendesk and you can see there's some more detail here about the actual integration some of the use cases that I might be interested in but right now I actually just want to get the set up so that I start receiving events from Zendesk so I click the setup button and there's three simple steps to do this the first is that I have to copy my AWS account ID so I do that and then I head over to my Zendesk admin center I've got that tab set up here but there's an integrations page where I can start setting up the Amazon event bridge connector I'll click connect and then all I need to do is put in my AWS account ID that I copied from the previous step and choose which we I want my eventsource to be created and where I'm going to receive my events I can also select the types of events in this case Zendesk only support sending support tickets so I'll hit connect here and what's happening in the background is Zendesk are sending a request to the event bridge API to say create partner event source and what that does is create a resource in Zendesk secound and makes that resource accessible to my account ID that i provided when i hit connect on that previous screen so if i go back to my event bridge console now to my partner event sources you can see that I have an event source from Zendesk that is in my account accessible to my account and it's in the pending state so at this point Zendesk could start sending events to that event source but because I haven't connected this to an event bus in my account they won't actually flow through and and I won't get charged for any of those events so to make that actually work I select the event source and associated with an event bus that allows me to specify any permissions that I might want and then create the event bus so you can see that event sources now in the active State and if I go to my event buses I have an event bus here for the for the Zendesk event source so from there I now want to send events from Zendesk and trigger my lambda function that does sentiment analysis so if I go over to to my lambda function I've set this up beforehand I've given it access to Amazon comprehend in the permissions section and you can see the function over here it's very basic it takes in an event which we receive from from Zendesk it just sets those out into a couple of variables it then makes a request to Amazon comprehend using the AWS SDK and it says that it wants it to detect the sentiment of the comment that we received from Zendesk if the comment is then determined as negative by a comprehend we want to update 10 desks ticket we want to set the priority to urgent and we add some tags to that to say that it needs priority support and that a manager is required if the response that we get from comprehend is not negative then we'll set the ticket priority to low so to update the ticket on Zendesk we're having to call their api and so that's handled in this update Zendesk section over here so what I'll do is now that I've got this lambda function working is I'll go ahead and create a rule for that so I go and select my Zendesk event bus and click the Create rule button so here I'm gonna keep it really broad and match against any event that comes from Zendesk but I could have cos specify the the type of event that I was I was looking for so I might put in here that I'm actually just looking for the ticket created event but for now we'll keep this simple and just make it a broad rule and then go down and select my Zendesk sentiment analysis lambda function and said that is the target and so that rule has been created and if I go back to mine I'm the function and refresh this page you'll see at the top that it's picked up that we actually have Zendesk acting as a trigger you can pretty easy go in from lambda and add various other triggers you can see AWS services and then any of those event bridge partner event sources that you have created accessible here as well so if I had any of these other partners I could very easily add them from lambda as well we've got Zendesk set up so there's no need for us to go and set that up again so now what I'll do is head over to my Zen desk section and create a new ticket and this might happen on your website somewhere by someone emailing in there's various ways to create a ticket but I'm just gonna do it directly through Zen desks dashboard this is my ticket and I'm gonna say here I'm really sad and disappointed in your service it was bad so I want to make sure that I'm as in comprehend picks this up as a negative ticket so I'll submit that ticket whoops let's see what happen there and you can see my ticket got created so immediately that ticket has been set to urgent and the tags manager required and priority supports have been added so what happened in the background and it goes pretty quickly is event Zendesk sent a request to a ticket to event bridge when the ticket was created that matched against my rule that I'd been created and then the rule sent that to my lambda function the lambda function then did sentiment analysis on the ticket contents determined that it was negative and updated the tags over here so a really simple way to start receiving events from a sass partner and do interesting things with them using AWS services if I head back to my slide show so hopefully you saw there is a better option and if you're interested in getting your company added as a partner you'll join a bunch of our partners that we've launched with you can simply email event bridge - partners at amazon.com so that'll get you set up will respond with some details on how to become a partner for that bridge great if you need any further information we've got some resources out there you can go and take a look at our product page and after that our documentation for event bridge and as I mentioned before we have that event bridge - partners at amazon.com email address so if you're wanting to get in touch about becoming a partner please get in touch and let us know so hopefully that's given you a good overview of how you can start moving your own applications to become more event-driven instead of making API calls between all of your various micro services you can use a mint bridge to start putting events onto event bus and then have those downstream systems select the events that they're interested in we've also shown you how to connect API gateway so that if you have an upstream service that cannot call the put events API you can instead simply give them an HTTP endpoint that they can send their events to and then bring those events into event bridge where we take care of the delivery to all of the downstream services and then finally if you are using a partner at one of those 10 that we support so far and you can very easily hook them up without having to worry about API polling or managing web hooks and get those events direct me into an event bridge event bus read I'll now be taking any questions so please feel free to submit them into the chat and I can answer those from here