Amazon EventBridge: The Event Bus

Sven's team had built their order system on SNS. Then a new requirement came in: when an order was placed, also send the event to a third-party fraud detection SaaS. And when a customer signed up, the same kind of routing. And when inventory dropped below threshold. Every new use case was another SNS topic, another subscription, another piece of glue.

This is exactly the problem Amazon EventBridge solves. It's not just another pub/sub service — it's a routing layer for events across an entire AWS estate and beyond.

What EventBridge Is

EventBridge is a serverless event bus. Events flow into the bus from many sources; rules match events and route them to many targets. The mental model:

• A bus is the central pipe — every AWS account starts with a default bus;
• Sources publish events to a bus — AWS services, your own apps, SaaS providers;
• Rules match events based on patterns;
• Targets receive the matched events — Lambda, SQS, Step Functions, Kinesis, ECS tasks, other EventBridge buses, more than 20 target types in total. An event is a JSON document with a defined structure: source, detail-type, detail, and standard metadata.

EventBridge vs SNS: The Real Difference

The two look similar from a distance. The differences that matter:

• Sources — SNS expects you to publish; EventBridge has hundreds of AWS services and SaaS partners (Auth0, Datadog, MongoDB Atlas, Stripe, Zendesk) that publish events directly;
• Filtering — SNS filtering is simple attribute matching; EventBridge has rich content-based filtering with prefix, suffix, exists, numeric ranges, IP matching;
• Schema registry — EventBridge has a schema discovery feature that auto-generates type-safe code bindings;
• Replay and archive — EventBridge can archive events and replay them later. SNS cannot;
• Throughput — SNS scales to higher throughput per topic; EventBridge has lower default limits but is rarely the bottleneck. The rule of thumb: SNS for simple fan-out within your own system, EventBridge when you need integration with AWS services or SaaS partners, complex routing, or event archive.

Rule Patterns

A rule pattern is JSON that matches events. Example:

{
  "source": ["aws.s3"],
  "detail-type": ["Object Created"],
  "detail": {
    "bucket": { "name": ["acme-uploads"] }
  }
}

This rule fires only when an object is created in the acme-uploads bucket. The same rule could trigger a Lambda, a Step Function workflow, or both — all configured in one place.

Pattern operators supported:

• Exact match — ["aws.s3"];
• Prefix — [{ "prefix": "us-east" }];
• Suffix — [{ "suffix": ".jpg" }];
• Numeric — [{ "numeric": [">=", 100] }];
• Exists — [{ "exists": true }];
• IP range — [{ "cidr": "10.0.0.0/8" }].

Custom Event Buses

Beyond the default bus, you can create:

• Custom buses — for your own application events, isolated from AWS service events;
• Partner event buses — auto-created when you subscribe to a SaaS partner. The pattern many teams use: one custom bus per major domain (orders-bus, users-bus, inventory-bus), with rules routing between them as needed.

EventBridge Pipes

A newer feature, EventBridge Pipes, provides point-to-point integration between a source (SQS, Kinesis, DynamoDB Streams, MSK, and others) and a target — with optional filtering and enrichment along the way. It is an alternative to writing a Lambda just to move data from one place to another.

The flow: Source → Filter → Enrichment (optional Lambda or Step Function) → Target.

Scheduled Rules

EventBridge replaces the old "CloudWatch Events" scheduled rules. You can trigger a target on a cron expression or rate expression:

• cron(0 12 * * ? *) — every day at noon UTC;
• rate(5 minutes) — every 5 minutes. This is the modern way to run scheduled Lambdas — cleaner than the old CloudWatch Events syntax, integrated with the rest of EventBridge.

Sven's Refactor

Sven moved off SNS for the routing case. The new architecture:

• A custom EventBridge bus called commerce-events;
• Lambda publishes order.placed, user.signed_up, inventory.low events to the bus;
• Rules route each event type to its targets — internal Lambdas, SQS queues, and (via API Destinations) the fraud detection SaaS;
• New requirements add new rules, not new topics. Net result: every new event source and consumer changes one rule, not five integrations.

For the Exam

DVA-C02 hits these patterns:

• EventBridge vs SNS: when to pick which;
• Event patterns and how matching works;
• Scheduled rules with cron and rate expressions;
• Custom buses for domain isolation;
• Integration with SaaS partners and AWS services. If a question mentions "events from AWS services" or "third-party SaaS event integration" or "routing rules" — the answer is almost always EventBridge.