EventBridge Rules vs EventBridge Schedules

Trying to understand the difference between AWS EventBridge Rules and EventBridge Schedules? This is the article for you.

In a recent article, I wrote about the newly announced EventBridge Scheduler feature. Some of you noted that the feature sounds a lot like standard EventBridge Rules. In this article, I’d like to clarify the difference between these two features of EventBridge.

We’ll start out with a brief summary of EventBridge Rules before jumping into how EventBridge Schedules differ.

So let’s get into it.

EventBridge Rules Overview

EventBridge Rules have two primary functions that you can choose to utilize:

1. Event Pattern Reaction – Allows you to react to various types of events. When a matching event occurs, the event is routed to the targets associated with the rule (i.e. a Lambda Function, SQS Queue, or other service). A rule can be associated with one or more targets.
2. Event Scheduling – Create a recurring schedule that periodically triggers an event at a specified time interval.

Regardless of what triggers your event, you can route your event to multiple different targets during processing. This allows you to run concurrent operations in parallel in reaction to the initial event.

Another pre-requisite of using either of these two features is that you are required to leverage an Event Bus. An EventBus is a component created through the EventBridge service that lets you receive, filter, transform, route, and deliver events.

Let’s dig a little bit more into these two different features offered through EventBridge Rules.

Event Pattern Reaction

Event Pattern Reaction allows you to listen for specific types of events that you are interested in, and trigger a corresponding action. These types of events can originate from AWS services, external AWS partners (like DataDog, PagerDuty, and more), or be based on custom events that you publish to your event bus.

The general idea is that you write a special statement called an event pattern. Event patterns are like content based filters. As part of your event pattern, you can specify certain conditions that you are interested in. For example, if you would like your system to react to when an EC2 instance switches to the terminated state, you would write a event pattern like this:

{
  "source": ["aws.ec2"],
  "detail": {
    "state": ["terminated"]
  }
}

The source specifies which service you are listening to.

The detail field contains the keys and values you are interested in reacting to.

And below is an actual event that will be automatically sent to your EventBus that will trigger this pattern.

Note the highlighted areas source and state. Their values match the corresponding event pattern that we specified earlier.

This is an extremely simple example of the capabilities of Event Pattern Reaction. You can write much more complex pattern matching rules using operators like exists, begins with, ends with, and, or, empty, and much more. For a more detail on writing event patterns check out the aws documentation here. For more information about EventBridge overall and how it compares to services like SNS or SQS, check out my other article right here.

Once a matching event is triggered, EventBridge will automatically invoke the corresponding targets. As mentioned before, this can be a SNS Topic, Lambda Function, Glue Job, Step Function Workflow, and many many more.

Also note is that you can integrate with events that originate outside of aws. For example, EventBridge natively integrates with partners such as Stripe, Github, Shopify, Datadog, and many more. This way, you can write patterns that match those types of events and trigger the respective targets.

The TLDR of EventBridge Rules Pattern Matching is that you write rules that parse AWS events, and trigger corresponding targets when a matching event occurs.

EventBridge Rules Schedules

EventBridge Rules Schedules on the other hand allow you to set specific intervals to fire an event at. There are two variations, rate and cron.

Rate is simple concept to understand. You simply provide the unit type (minutes, hours, or days), and the corresponding unit value (i.e. 1, 5, 24). For example, here’s me creating a rate based schedule that will trigger every 5 minutes.

The other event type is cron. For those of you familiar with unix cron jobs, this should be no surprise. Cron based events allow you to write more sophisticated patterns that trigger events at certain times. For example, you could write an event that triggers at 8AM every Monday.

The cron method allows you to be much more flexible with when your events are triggered as opposed to using a simple rate based configuration.

Regardless of whether you choose rate or cron, you have the option of selecting the target you would like to invoke in response to this event. Similar to EventBridge Pattern Reaction, you can trigger pretty much any AWS service, or you can send a different event bus for reaction.

Note that when you create the rule, you have the option of enabling it immediately or at some point after. You do not have the ability to enable the rule at a specific time – you must either come into the console to enable it or do so programmatically. Another gap is that using EventBridge Rules, you cannot create singular triggers that fire at a specific time and are thrown away.

To address both of these two gaps, AWS released EventBridge Scheduler. Lets dig into that now.

EventBridge Scheduler Overview

Imagine that you own an e-commerce application and a customer places an order. 1 month later, you would like to send them an email with a discount code. This used to be a really complicated thing to do in AWS with no dedicated service to do so.

This type of problem is what is directly addressed by using EventBridge Scheduler.

The feature allows you to create two types of events: one-time schedules or recurring schedules.

One-time schedules are single instances of an event that will fire at a specific time, and be thrown away afterwards. For example, trigger an event at 3:00AM UTC.

If we bring this back to our initial example, creating a reminder email that fires 30 days after the initial order is a trivial task. We would just create an instance of a one-time schedule that fires 30 days after the order is placed – easy!

Also included in EventBridge Scheduler is the possibility of creating recurring schedules. Recurring schedules are almost exactly the same as EventBridge Rules Schedules as outlined above – They both contain the concept of rate or cron based expressions.

However, the distinction is that with EventBridge Scheduler, you get access to a bunch of extra features including when to start and end the schedule.

For example, if we use an EventBridge Scheduler’s recurring schedule, we can create a configuration that will trigger an event every 5 minutes, but only between March 1st and 31st. Once you create the schedule, the service will automatically begin firing events once we reach March 1st with no action from you! Do note that you can also specify the timezone of the events.

Also included in EventBridge Scheduler are a couple other features around message delivery and resiliency. You get access to Flexible Time Windows that allow you to create variance in when your message is delivered to the target. This allows you to stagger the invocation of your events so you don’t get bursty workloads all firing at the precise minute of a certain day. Note that this feature is optional.

The resilience features of EventBridge Scheduler include setting a retry policy and a dead-letter queue (DLQ) as seen below.

These features allow you to be a bit smarter in terms of what to do when EventBridge cannot trigger the corresponding target. For example, say you are trying to trigger a Lambda function but it is currently being throttled. By setting a retry policy, you can ensure EventBridge attempts to deliver the message multiple times before failing and writing the message to a DLQ for later analysis.

Bringing it all together

EventBridge Rules are an older AWS feature that allowed us to listen + react to certain events, or fire events at a specific rate for us to react to later. This was useful feature for a lot of applications but lacked precise schedule controls such as start time, stop time, and singular events that fire once and are thrown away later.

EventBridge Scheduler on the other hand is a huge improvement over EventBridge Rules. You get access to missing features as well as resiliency controls that can keep you informed in case of target outages. The addition of one-time events is a really powerful concept that has applications in tons of different use cases.

The following table from AWS summarizes the differences between these two offerings nicely:

In my opinion, EventBridge Scheduler will most likely totally replace the recurrence component of EventBridge Rules. Honestly there doesn’t seem like much of a reason to use EventBridge Rules if you’re looking to trigger an event at a certain interval – especially with all the built in protections like retry policies and DLQs.

The increase in quotas (1 million for scheduler vs 300 rule limit for rules) and difference in TPS (transaction per second) is also a huge game changer. EventBridge Scheduler looks to have been built to handle high throughput applications and the features reflect that.

If you’d like to see EventBridge Scheduler in action, check out my tutorial article here.

If you enjoyed this article, check out some of my other related ones:

• AWS SQS vs SNS vs Eventbridge – When to Use What?
• How To Prevent System Failure with Monitoring and Traceability