Eventbridge rules - what they are and debugging them.

Eventbridge rules are the back bone of an event driven, serverless architecture in AWS.
The majority of AWS Services emit events to EventBridge when they take place, for example when a parameter is updated in systems manager.

Using eventBridge rules, we can listen for these events, and trigger an action.

The rules let us describe which events we would like to listen for, allow us to filter by the details of the event, and even to transform the event before sending it to a target.

Creating a rule

Creating rules is simple, and at first it’s best to use the console, as it shows you loads of details like sample events that can help guide your pattern.

Go to event bridge in whatever region you want to deploy the rule, and click on “rules” in the side menu.
click “create rule”
Give your rule a name and description, select your default eventBus and “Rule with event pattern” - the other choice “Schedule” would let you create a cron like task, but this is better achieved with eventbridge scheduler.
Now we’re starting to build our pattern.
We’re going to select “AWS Events or EventBridge Partner Events”.
Note: Even if you’re tempted to view all events for some reason, don’t! You can easily end up with circular logic and extremly high costs (for example, you output all events to the logs - but that creates log events which will be written to the logs and so on ad infinitum).
Select the service that you wish to respond to events from.
In this case I have selected SSM as my end goal might be to do something like initiate a codePipeline when parameters change.
At this point one would be able to specify not just the service to listen to, but also the event type, for example “Parameter Store Change” will match whenever parameters are created/edited/deleted.
Optionally fine tune your pattern.
Clicking ‘edit pattern’ will enable you to edit the json that makes up the pattern. There is a convenient panel of sample events to look, or you can refer to the docs.
A handy dropdown for selecting less trivial matching, such as prefix or suffix matching is also available.
Tip: It’s a good idea to get as specific as you can, as filtering here is cheaper than sending irrelevant events to the target and filtering them there!
Selecting a target.
Now we’ve mathced our events, we want to forward them somewhere to intiate some action - we need to create a target (you can have multiple targets for the same rule!).
For each Target there are three options: - Another event bus (perhaps in another account?) - An EventBridge Api Destination - An AWS Service (for example, codePipeline, Lambda, SNS) We’re going to select Cloudwatch Logs as for now we just want to write all the events to CLoudwatch Logs and ensure that our patterns worked.
You can type in the log group name, it will take care of creating it and permissions itself.
Additional Settings:
You can toggle the “Additional Settings” panel to
- specify a retry policy How long/often to retry evetns,and what to do with unprocessed ones (a deadletter queue)
- Configure the input target. Here we can specify what payload is sent to the target: - Matched Events: The whole event.
  - Part of the Matched Event: Use JSON path to match part of the event.
  - Constant (JSON text): Send a pre-determined SON payload.
  - Input Transformer: Using JSON and JSON path create an “input path” which extracts variables from your event, and a “template” which uses those variables.
    See this post about using eventBridge to notify Slack for a good example of this in action.
Wrapping it up:
Next you’ll be asked to tag your resources, review your selections and finally save it.
After this, you’ll see the rule listed, and it should be working.

Turning it off

It’s worth knowing that rules have a status, and can be disabled - if you have, for example, a debug rule, or a misbehaving rule, tha you don’t wish to delete, you can simply disable it.

Debugging Event Bridge events

Sometimes, it’s inevitable, you’ll need to debug it - perhaps a rule isn’t executing when it should.

Though there is an event history in cloudtrail, but not all eventBridge events will appear there.
A really simple way to debug is to simply temporarily forward the events to Cloudwatch logs, and you will have a copy of the events that take place to test your patterns against.
You don’t need to create a new rule for this as a rule can have multiple targets.

You can also forward your transformed events here, to see what would be being sent to an api for example.