What Is Amazon EventBridge? Event Buses, Rules, Pipes and Scheduler

Amazon EventBridge is AWS's event router: events arrive on an event bus, rules match them by their content, and matching events are delivered to targets such as Lambda functions, SQS queues, Step Functions or HTTP endpoints. It grew out of CloudWatch Events, and today it also includes Pipes for point-to-point integrations and Scheduler for timed invocations.

For backend developers, EventBridge shows up in three ways: reacting to things AWS services do, receiving events from SaaS products, and connecting your own services through a custom bus. This guide covers how each part works, how it compares to SNS and SQS, and where application events fit better elsewhere.

Amazon EventBridge at a glance

How event buses and rules work

An event is a JSON document with standard fields such as source, detail-type and time, and an application-specific detail object. AWS services write to the default bus automatically, and applications publish to a custom bus with PutEvents.

A rule attaches an event pattern to a bus, and patterns match on exact values, prefixes, numeric ranges, the existence of a field or anything but a value, so a rule can select OrderPlaced events from one source where detail.total is above 100. Each rule sends matching events to up to five targets, and an input transformer can reshape the event for each one. Event patterns are the core of EventBridge, since routing logic lives in rules rather than in the publishing code.

Delivery is at least once, so consumers should be idempotent. When a target fails, EventBridge retries with backoff for up to 24 hours by default, and a dead-letter queue on the target captures events that still fail.

Pipes and Scheduler

EventBridge Pipes connect a single source, such as an SQS queue, a DynamoDB stream or a Kinesis stream, to a single target, with optional filtering and an enrichment step that can call Lambda or an API in between. They replace small Lambda functions that only move data from one service to another.

EventBridge Scheduler creates schedules with cron or rate expressions in a chosen time zone, or one-time schedules at a specific timestamp, with flexible windows that spread invocations. Targets include Lambda, ECS tasks, SQS, Step Functions and many AWS API actions directly. It replaced scheduled rules on the event bus as the recommended way to run tasks on a schedule on AWS.

EventBridge vs SNS vs SQS

A common AWS pattern combines them: EventBridge or SNS fans out an event, and each consumer has its own SQS queue so it can process at its own pace with a dead-letter queue.

Pricing

Custom and partner events are billed per million published, and AWS service events on the default bus are free, with separate prices for archive storage, replay, Pipes and Scheduler invocations. The EventBridge pricing page lists the current numbers. For most backends the event charges are small compared with the Lambda or compute that processes the events.

Application events and schedules with Encore

Encore combines an open source infrastructure SDK with a platform that provisions and deploys into your own AWS or GCP account. For events between your own services, Encore uses typed Pub/Sub topics declared in TypeScript or Go instead of a bus with JSON rules, and for schedules it uses cron jobs declared in code:

import { api } from "encore.dev/api";
import { CronJob } from "encore.dev/cron";
import { Subscription, Topic } from "encore.dev/pubsub";

interface OrderPlaced {
  orderId: string;
  total: number;
}

// SNS topic on AWS, with an SQS queue and dead-letter queue per subscription.
export const orderPlaced = new Topic<OrderPlaced>("order-placed", {
  deliveryGuarantee: "at-least-once",
});

// Each subscription receives every event, like separate rule targets.
const _receipts = new Subscription(orderPlaced, "send-receipt", {
  handler: async (e) => {
    // send the receipt
  },
});

const _review = new Subscription(orderPlaced, "flag-large-orders", {
  handler: async (e) => {
    if (e.total <= 100) return; // filtering happens in code
    // flag for review
  },
});

// Run by the Encore platform, no extra cloud resources.
export const nightlySummary = api({}, async (): Promise<void> => {
  // build the daily summary
});

const _nightly = new CronJob("nightly-summary", {
  title: "Build the daily order summary",
  schedule: "0 2 * * *",
  endpoint: nightlySummary,
});

On AWS, Encore provisions an SNS topic with an SQS queue and dead-letter queue for each subscription, and it provisions an IAM role for the service, per the AWS infrastructure docs. Cron jobs are managed by the Encore platform and need no extra cloud infrastructure, as described in the infrastructure overview. The Pub/Sub and cron docs cover retries, ordering and schedules. Event types are checked by the compiler, and encore run delivers events locally, which an EventBridge rule cannot do without a deployed bus.

EventBridge remains the right tool for AWS service events and SaaS partner events, which an Encore service can consume through the AWS SDK or by having a rule target an SQS queue that the app reads.

Best fit: teams whose events are mostly between their own services and who want typed topics, retries and schedules declared in code and testable locally.

When to use EventBridge

Use EventBridge when the events come from AWS services or SaaS partners, when routing should change without redeploying publishers, when you need archive and replay, or when Scheduler's time zones and one-time schedules fit the job. For high-throughput fan-out between your own services, SNS with SQS queues or a typed Pub/Sub layer in the application is usually simpler and faster.

Related guides

• Pub/Sub vs SQS
• Message queues vs Pub/Sub
• Cron jobs on AWS without Terraform
• What is AWS Lambda?
• What is Amazon API Gateway?