LearningTree · AWS · Integration

Amazon EventBridge —
Serverless Event Bus

The intelligent event router that connects AWS services, your applications, and SaaS providers — enabling fully reactive, event-driven cloud architectures without managing infrastructure.

⚡ EventBridge in 30 Seconds

Serverless event bus — routes events between AWS services, apps, and SaaS providers
Rules with pattern matching — intelligently filter and route events by content
No infrastructure to manage — fully managed, scales automatically
Native AWS integration — 200+ AWS services emit events to EventBridge
Enables reactive architectures — systems respond to events instead of polling

Chapter One

What is Amazon EventBridge

The Central Question: How Do Cloud Systems Communicate? Introductory

In a modern cloud architecture, you have dozens of services that need to coordinate: a file is uploaded, an order is placed, a deployment completes, a security alert fires. How do these events flow between systems?

⚠️

Traditional Approach (Problematic)

Services call each other directly via APIs
Each service needs to know about all others
Adding a new consumer requires code changes
Tight coupling creates cascading failures
Polling wastes resources and adds latency

✅

Event-Driven Approach (Modern)

Services emit events to a central event bus
Consumers subscribe to events they care about
Adding a new consumer = just add a rule
Loose coupling — services don't know each other
Reactive — systems respond instantly to events

The Mental Model: An Intelligent Airport Control Tower Introductory

👉 EventBridge is like an intelligent airport control tower. Planes (events) arrive constantly from many sources. The tower examines each plane's details — where it's from, what it's carrying, its priority — and routes it to exactly the right gate (target). No plane needs to know where other planes are going. The tower handles all routing decisions automatically.

Real-world analogies that work well:

🗼

Control Tower

Watches all incoming flights (events), examines their details, and routes them to specific gates (targets) based on intelligent rules.

📮

Mail Sorting Facility

Letters arrive from everywhere. The facility reads the address and routes each letter to the correct destination — senders never coordinate directly.

🧠

Smart Home Hub

"Motion detected in living room" → turn on lights, start recording, send notification. The hub routes events to multiple actions based on rules you define.

What EventBridge Actually Is Introductory

Amazon EventBridge is a fully managed serverless event bus that:

Receives events from AWS services, your applications, and SaaS providers
Evaluates each event against your rules (pattern matching on event content)
Routes matching events to one or more targets (Lambda, SQS, Step Functions, etc.)
Operates without any servers to manage — fully serverless and automatically scalable

The core concept is simple:

EventBridge — Core Concept: Events Flow Through Rules to Targets

What Problems Does EventBridge Solve? Core

EventBridge addresses five fundamental challenges in modern cloud architecture:

🔗

Service Coupling

Without EventBridge, services must know each other's APIs. With EventBridge, services emit events without knowing who consumes them. Complete decoupling.

🔀

Intelligent Routing

Route events based on their content — not just their type. "Route only failed deployment events from production to the on-call Lambda" — all without code.

🔌

SaaS Integration

Native partner integrations let external SaaS apps (Stripe, Zendesk, GitHub) emit events directly into your AWS architecture.

⏰

Scheduled Automation

Create cron-style scheduled rules that trigger targets on a schedule — no EC2 or Lambda cron hacks needed.

Modern Cloud Systems Are Event-Driven Core

Events happen constantly in any real system. Here are examples of events that flow through a typical AWS architecture:

Event Type	Source	Example Event
File uploaded	Amazon S3	`s3:ObjectCreated:Put` in `uploads/` bucket
Instance state change	Amazon EC2	Instance `i-1234` changed from `running` to `stopped`
Deployment completed	AWS CodePipeline	Pipeline `prod-deploy` succeeded
Security alert	AWS GuardDuty	Unusual API call from IP `203.x.x.x`
Payment received	Stripe (SaaS)	Invoice `inv_123` paid: $500
Custom app event	Your application	`OrderPlaced` with orderId `ORD-9876`

EventBridge is the service that captures, filters, and routes all these events to the right destinations — automatically and at scale.

AWS Service Event Sources — Quick Reference Core

Over 200 AWS services automatically send events to the default event bus. Here are the most commonly used:

Service	Event Types	detail-type Example
EC2	Instance state changes	`EC2 Instance State-change Notification`
S3	Object operations	`Object Created`, `Object Deleted`
CloudWatch	Alarm state changes	`CloudWatch Alarm State Change`
CodePipeline	Pipeline execution	`CodePipeline Pipeline Execution State Change`
GuardDuty	Security findings	`GuardDuty Finding`
RDS	DB instance events	`RDS DB Instance Event`
Auto Scaling	Scaling events	`EC2 Instance Launch Successful`
ECS	Task state changes	`ECS Task State Change`
Step Functions	Execution status	`Step Functions Execution Status Change`
Secrets Manager	Rotation events	`AWS API Call via CloudTrail`

👉 No configuration needed: These events flow to the default event bus automatically. Just create rules to match and route them.

🎓 Exam Insight

When an exam question mentions routing events based on content, SaaS integration, cross-account events, or scheduled triggers — the answer is EventBridge. SNS broadcasts to all subscribers; EventBridge routes based on rules. This routing capability is the key differentiator.

👉 Key Takeaway

EventBridge is the intelligent event router of AWS — it watches events from everywhere and routes them to exactly the right targets based on rules you define, all without managing any infrastructure

Chapter Two

Why Event-Driven Architecture Matters

The Traditional Problem: Tightly Coupled Systems Introductory

Before event-driven architecture, systems communicated through direct API calls. This created a tangled web of dependencies:

Traditional Architecture — Direct Service Calls (Tightly Coupled)

⚠️

Problems with Direct Calls

Tight coupling — Order Service code contains logic for all 6 downstream services
Cascading failures — if Inventory API is down, entire order flow might fail
Synchronous blocking — Order Service waits for all 6 calls to complete
Change amplification — adding a 7th consumer requires Order Service code change
Testing nightmare — must mock all dependencies to test Order Service

💰

Hidden Costs

Deployment risk — Order Service deploys more often because of consumer changes
Latency accumulation — user waits while all 6 APIs respond
Reliability math — 99%^6 = 94% effective uptime if each service is 99% available
Team friction — Order team must coordinate with 6 other teams

The Event-Driven Solution: Loose Coupling Core

👉 With event-driven architecture, the Order Service simply emits an "OrderPlaced" event. It doesn't know — or care — who is listening. EventBridge routes the event to all interested consumers based on rules. The Order Service code never changes when new consumers are added.

Event-Driven Architecture — Loose Coupling via EventBridge

The Five Pillars of Event-Driven Architecture Core

🔗

Loose Coupling

Producers and consumers don't know about each other. The Order Service has no dependency on Inventory, Email, or Shipping. They evolve independently.

⚡

Asynchronous Processing

Events are emitted immediately. The producer doesn't wait for consumers to finish. This dramatically improves response times and throughput.

🔄

Reactive Systems

Systems react to events as they happen — no polling. A file upload instantly triggers processing. An alarm instantly triggers remediation.

📈

Independent Scaling

Each consumer scales independently. High load on Analytics doesn't affect Inventory. Each service has its own scaling profile.

🛡️

Failure Isolation

If the Fraud service goes down, Order, Email, and Shipping continue working. No cascading failures. Each component is isolated.

🔧

Extensibility

Adding a new consumer = adding a new EventBridge rule. No code changes to producers. No redeployments of existing services.

Real-World Event-Driven Scenarios Core

Scenario	Without Events	With EventBridge
Order Processing	Order API calls 6 downstream APIs synchronously. User waits 3+ seconds.	Order API emits one event, returns in 50ms. 6 consumers process in parallel.
CI/CD Pipeline	Build script hardcodes Slack webhook, email script, Jira API. Changes require script edits.	Pipeline emits "DeploymentCompleted" event. Rules route to Slack, Email, Jira independently.
Security Response	GuardDuty finding → manual ticket → manual investigation → manual remediation.	GuardDuty → EventBridge → Lambda auto-disables user + creates ticket + alerts security team.
Data Pipeline	Cron job polls S3 every 5 minutes. Wasted API calls. 5-minute delay minimum.	S3 → EventBridge → Lambda triggers instantly when object is created.

Common Mistakes with Event-Driven Systems In-Depth

🚫

Mistake: Using Events for Synchronous Flows

Events are async by nature. If you need a response (e.g., "is this user authorized?"), don't use events — use a direct API call. Events are for "notify and forget."

🚫

Mistake: Giant Event Payloads

Events should be lean notifications, not full data dumps. Include identifiers (orderId), not the entire order object. Consumers can fetch details if needed.

🚫

Mistake: No Dead-Letter Queue

If a consumer fails to process an event, where does it go? Always configure a DLQ so failed events aren't silently lost.

🚫

Mistake: Assuming Order Guarantees

EventBridge does not guarantee event ordering. If order matters, use the detail fields to sequence events or use a different architecture.

🎓 Exam Insight

Key architecture trigger words: When you see "decouple services", "add new consumers without code changes", "react to events in real-time", or "scale services independently" — the answer involves event-driven architecture with EventBridge. This is a fundamental pattern that appears in nearly every AWS architecture exam.

👉 Key Takeaway

Event-driven architecture transforms tightly coupled systems into loosely coupled, independently scalable components — EventBridge is AWS's native service for building this pattern at scale

Chapter Three

How EventBridge Works

The Core Flow: Source → Bus → Rules → Targets Introductory

Every EventBridge interaction follows a simple four-step flow. Understanding this flow is the foundation for everything else:

EventBridge Flow — Events Arrive, Rules Evaluate, Targets Receive

Component 1: Event Bus Core

The Event Bus is the central channel that receives all events. Think of it as the "highway" that events travel on.

🚌

Default Event Bus

Every AWS account has one default bus. All AWS service events (EC2, S3, CloudWatch) flow here automatically. Free to use — no setup required.

🎯

Custom Event Bus

Create separate buses for your applications. Isolate events by domain: orders-bus, payments-bus. Better organization and access control.

🔌

Partner Event Bus

SaaS providers (Zendesk, Datadog, Auth0) can send events to a partner bus. No code required — just enable the integration in the console.

Event Bus Type	Use Case	Event Sources
Default	AWS service events (EC2 state changes, S3 uploads, etc.)	AWS services automatically
Custom	Your application events, domain separation, cross-account buses	PutEvents API from your code
Partner	SaaS integration (Stripe, GitHub, Shopify, etc.)	Partner sends events via integration

Component 2: Events Core

Events are JSON documents that describe something that happened. Every event follows a standard structure:

📋

Event Envelope (Metadata)

Standard fields added by EventBridge:

version — always "0"
id — unique event identifier
source — who sent the event (e.g., aws.ec2)
detail-type — type of event (e.g., EC2 Instance State-change)
time — when the event occurred
region, account, resources

📦

Event Detail (Payload)

The actual event data in the detail field:

Free-form JSON — you define the structure
AWS services have standardized schemas
Maximum event size: 256 KB
This is what rules match against
Contains business data (orderId, status, etc.)

EXAMPLE EVENT — EC2 Instance State Change

{
  "version": "0",
  "id": "12345678-abcd-1234-efgh-1234567890ab",
  "source": "aws.ec2",
  "detail-type": "EC2 Instance State-change Notification",
  "account": "123456789012",
  "time": "2026-05-07T10:30:00Z",
  "region": "us-east-1",
  "resources": ["arn:aws:ec2:us-east-1:123456789012:instance/i-1234567890abcdef0"],
  "detail": {
    "instance-id": "i-1234567890abcdef0",
    "state": "stopped"
  }
}

Component 3: Rules Core

Rules are the intelligence of EventBridge. They watch the event bus and evaluate each event against a pattern. If the event matches, it's sent to the rule's targets.

🎯

Event Pattern Rules

Match events based on content:

Match by source: "aws.ec2"
Match by detail-type: "EC2 Instance State-change"
Match by detail fields: "state": ["stopped"]
Combine conditions with AND logic

⏰

Scheduled Rules

Trigger targets on a schedule (no event needed):

Rate expression: rate(5 minutes)
Cron expression: cron(0 12 * * ? *)
Use for periodic tasks: cleanups, reports
No external scheduler needed

Rules can have up to 5 targets each. One rule can send a matching event to Lambda, SQS, SNS, and Step Functions simultaneously.

Component 4: Targets Core

Targets are the destinations that receive matched events. EventBridge supports 20+ target types:

AWS Lambda

Most common target. EventBridge invokes your function with the event as the payload. Scales automatically with event volume.

🗂️

Amazon SQS

Queue events for reliable, buffered processing. Workers poll at their own pace. Great for high-volume workloads.

📡

Amazon SNS

Fan out to multiple subscribers. EventBridge routes to the topic; SNS broadcasts to all subscribers.

🔄

Step Functions

Start a state machine workflow. Complex multi-step processing triggered by a single event.

🔥

Kinesis / Firehose

Stream events for real-time analytics. Route to S3, Redshift, OpenSearch automatically.

🌐

API Gateway / HTTP

Call external APIs or webhooks. EventBridge can invoke any HTTP endpoint as a target.

AWS Architecture Diagram — Complete Flow Core

EventBridge in AWS — Multiple Sources, Rules, and Targets

Input Transformers — Reshape Events for Targets In-Depth

By default, targets receive the entire event JSON. Input Transformers let you reshape the event payload before it reaches the target:

📋

Input Path

Extract specific fields from the event:

{
  "instance": "$.detail.instance-id",
  "state": "$.detail.state"
}

✨

Input Template

Build custom JSON for the target:

{
  "message": "Instance <instance> is now <state>",
  "severity": "high"
}

Input Transformer — Real-World Examples In-Depth

💬

Example 1: EC2 → Slack Message

Input Path:

{
  "instance": "$.detail.instance-id",
  "state": "$.detail.state",
  "time": "$.time"
}

Input Template:

{
  "text": "🖥️ <instance> is <state> at <time>",
  "channel": "#alerts"
}

📦

Example 2: S3 → SQS Processing

Input Path:

{
  "bucket": "$.detail.bucket.name",
  "key": "$.detail.object.key",
  "size": "$.detail.object.size"
}

Input Template:

{
  "s3_path": "s3://<bucket>/<key>",
  "file_size_bytes": <size>,
  "timestamp": "<aws.events.event.ingestion-time>"
}

👉 Multiple targets with different transformers: One rule can send the same event to multiple targets, each with its own input transformer. Target A gets a human-friendly Slack message; Target B gets structured JSON for processing.

API Destinations — Call External HTTP APIs Directly In-Depth

EventBridge can invoke external HTTPS endpoints directly without writing Lambda code:

🌐

What API Destinations Do

Call any public HTTPS endpoint as a target
Support API key, OAuth, or Basic Auth
Use input transformers to shape payloads
Built-in retry and DLQ support
No Lambda function needed for simple webhooks

⚙️

Setup Steps

1. Create Connection (auth credentials)
2. Create API Destination (endpoint URL)
3. Create rule targeting the API Destination
4. (Optional) Add input transformer for payload

Use Case	Endpoint	Auth Type
Slack notifications	`hooks.slack.com/services/...`	None (URL has token)
PagerDuty alerts	`events.pagerduty.com/v2/enqueue`	API Key header
Custom webhook	`api.yourapp.com/webhooks`	OAuth 2.0
Datadog events	`api.datadoghq.com/api/v1/events`	API Key header

⚠️

API Destination Limitations

Max timeout: 10 seconds
No response handling (fire-and-forget)
Requires internet access (VPC needs NAT)
Max 300 invocations/second per destination

💡

When to Use Lambda Instead

Complex request transformation
Need to call multiple APIs
Response data needs processing
More than 10 second timeout needed

Schema Registry — Automatic Schema Discovery In-Depth

EventBridge automatically discovers and stores schemas for events flowing through your bus:

📋

What Schema Registry Does

Automatically generates JSON Schema for events
Stores schemas for discovery by developers
Tracks schema versions over time
Generates code bindings (TypeScript, Java, Python)

🎯

Benefits

Type safety: Auto-generate typed event classes
Discoverability: See available events without docs
Onboarding: New team members discover events easily
Documentation: Auto-generated from real events

👉 To enable: Default bus auto-discovers AWS service schemas. For custom buses, enable "schema discovery" when creating the bus. Cost: Free for storage; pay for discovery API calls.

🎓 Exam Insight

Event Bus — the highway; events flow through it
Rules — the traffic controllers; filter events by pattern matching
Targets — the destinations; where matching events are delivered
One rule = up to 5 targets — one event can trigger multiple actions
Input Transformers — reshape event payload before delivery
API Destinations — call external HTTP endpoints without Lambda
Schema Registry — auto-discover event schemas for type safety

👉 Key Takeaway

EventBridge = Event Bus (receives) + Rules (filter) + Targets (deliver). Events flow through this pipeline, and rules act as intelligent routers that decide which events reach which destinations.

Chapter Four

Event Routing & Filtering

The Power of Pattern-Based Routing Introductory

EventBridge's most powerful feature is content-based routing. Unlike SNS (which broadcasts to all subscribers), EventBridge examines the content of each event and routes it only to matching targets.

👉 This is the key differentiator: EventBridge doesn't just pass events through — it intelligently filters and routes them based on what's inside. "Send EC2 stopped events to the ops team, but only if the instance is tagged as production."

Event Patterns — The Filtering Language Core

Event patterns are JSON objects that define which events a rule matches. They match against the event envelope and detail fields:

🎯

Basic Matching

Match exact values:

{
  "source": ["aws.ec2"],
  "detail-type": ["EC2 Instance State-change Notification"]
}

Matches all EC2 state change events.

📋

Detail Field Matching

Match on event payload:

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

Matches only stopped or terminated instances.

Advanced Pattern Operators In-Depth

EventBridge supports powerful pattern operators for complex filtering:

Operator	Syntax	Example Use Case
Exact match	`["value1", "value2"]`	Match specific states: `"state": ["stopped"]`
Prefix	`[{"prefix": "prod-"}]`	Match resources starting with `prod-`
Suffix	`[{"suffix": ".jpg"}]`	Match S3 keys ending in `.jpg`
Anything-but	`[{"anything-but": ["test"]}]`	Match all environments except test
Numeric	`[{"numeric": [">", 100]}]`	Match orders over $100
Exists	`[{"exists": true}]`	Match events that have a specific field
Wildcard	`[{"wildcard": "*.example.com"}]`	Match subdomains of example.com

Pattern Matching Examples Core

🚨

Production Alerts Only

Route only production failures:

{
  "source": ["my.app"],
  "detail": {
    "environment": ["production"],
    "status": ["failed", "error"]
  }
}

💰

High-Value Orders

Route orders over $500:

{
  "source": ["orders.service"],
  "detail-type": ["Order Created"],
  "detail": {
    "amount": [{"numeric": [">=", 500]}]
  }
}

🔐

Security Events

Catch unauthorized API calls:

{
  "source": ["aws.guardduty"],
  "detail": {
    "severity": [{"numeric": [">=", 7]}]
  }
}

🖼️

Image Uploads Only

S3 events for images:

{
  "source": ["aws.s3"],
  "detail": {
    "bucket": {"name": ["uploads-bucket"]},
    "object": {
      "key": [{"suffix": ".jpg"}, {"suffix": ".png"}]
    }
  }
}

JSONPath Syntax Reference In-Depth

EventBridge uses JSONPath syntax to extract fields for input transformers and match patterns:

Path	What It Selects	Example Result
`$.detail`	Entire detail object	`{"state":"stopped",...}`
`$.detail.state`	Single field	`"stopped"`
`$.detail.instance-id`	Field with hyphen	`"i-12345678"`
`$.detail.tags.environment`	Nested field	`"production"`
`$.resources[0]`	First array element	`"arn:aws:ec2:..."`
`$.detail.items[0].price`	Nested array element	`99.99`

👉 Built-in variables for input templates: <aws.events.event.ingestion-time> (event time), <aws.events.rule-arn> (rule ARN), <aws.events.rule-name> (rule name)

Complex Event Pattern — Real-World Example In-Depth

Combine multiple operators for sophisticated routing:

🔐

High-Severity Production Security Alerts

GuardDuty or Inspector findings, severity ≥7, production only:

{
  "source": ["aws.guardduty", "aws.inspector"],
  "detail": {
    "severity": [{"numeric": [">=", 7]}],
    "resource": {
      "tags": {
        "environment": ["production"]
      }
    }
  }
}

Matches: source=GuardDuty OR Inspector AND severity≥7 AND env=production

💳

Large Regional Payments

Payments over $10K from specific regions:

{
  "source": ["payments.service"],
  "detail-type": ["PaymentReceived"],
  "detail": {
    "region": ["us-east", "us-west"],
    "amount_usd": [{"numeric": [">", 10000]}]
  }
}

Matches: region=us-east OR us-west AND amount>$10K

Event Filtering Diagram Core

Event Filtering — Rules Selectively Route Events to Targets

Multi-Rule Matching Core

A single event can match multiple rules and be delivered to multiple targets. Each rule evaluates independently:

1️⃣

Event Arrives

An EC2 instance stops. The event enters the event bus and is evaluated against all rules.

2️⃣

Rules Evaluate

Rule A matches (send to Slack). Rule B matches (log to S3). Rule C doesn't match (different source filter).

3️⃣

Targets Receive

The event is delivered to both Slack and S3. Rule C's target receives nothing. No code coordination needed.

Scheduled Rules — Cron Without Servers Core

EventBridge can trigger targets on a schedule without any external event. This replaces traditional cron jobs:

⏰

Rate Expressions

rate(5 minutes) — every 5 minutes
rate(1 hour) — every hour
rate(1 day) — daily

Simple intervals. Always singular: rate(1 day) not rate(1 days)

📅

Cron Expressions

cron(0 12 * * ? *) — daily at noon UTC
cron(0 8 ? * MON-FRI *) — weekdays 8am
cron(0 0 1 * ? *) — first of month

Full cron syntax. Always UTC timezone.

🎓 Exam Insight

"Route based on event content" — EventBridge with event patterns
"Only process production errors" — detail field filtering in the rule
"Replace cron jobs" — EventBridge scheduled rules
SNS filter policies vs EventBridge rules — SNS filters on message attributes; EventBridge filters on the full event body with richer operators

👉 Key Takeaway

EventBridge rules act as intelligent filters — they examine event content and route only matching events to targets. This content-based routing is what makes EventBridge more powerful than simple pub/sub systems.

Chapter Five

EventBridge vs SNS vs SQS

The Integration Services Confusion Introductory

AWS has three major messaging services: EventBridge, SNS, and SQS. They're often confused because they all "send messages between services." The key is understanding their primary purpose:

🔀

EventBridge

"Intelligent event routing"

Routes events based on content. Pattern matching, SaaS integration, scheduling. The smart router.

📡

SNS

"Broadcast notifications"

One message → many subscribers. Push-based fan-out. Simple pub/sub broadcasting.

🗂️

SQS

"Reliable message queue"

One message → one consumer. Pull-based buffering. Durable work queue.

👉 Mental model: EventBridge is the router, SNS is the broadcaster, SQS is the buffer. They solve different problems and work best together.

Full Comparison Table Core

Feature	EventBridge	SNS	SQS
Pattern	Event Bus / Router	Publish / Subscribe	Message Queue
Delivery	Push to targets	Push to subscribers	Pull by consumers
Consumers per message	Multiple (via rules)	Multiple (all subscribers)	One (single consumer)
Filtering	Rich content-based filtering on full event body	Filter policies on message attributes	No filtering
Message retention	No — event bus is transient	No — delivers immediately	Yes — up to 14 days
Ordering	No guarantee	Standard: no / FIFO: yes	Standard: no / FIFO: yes
Scheduling	Yes — cron/rate rules	No	No
SaaS integration	Yes — 35+ partners	No	No
Cross-account	Yes — event bus policies	Yes — topic policies	Yes — queue policies
Schema registry	Yes — automatic discovery	No	No
Archive & replay	Yes — event archive	No	No (DLQ only)
Max message size	256 KB	256 KB	256 KB

When to Use Each Service Core

🔀

Choose EventBridge when…

You need content-based routing
Events from SaaS providers (Stripe, GitHub)
Cross-account event sharing
Scheduled triggers (cron jobs)
AWS service events (EC2, S3, etc.)
Schema discovery and event archive

📡

Choose SNS when…

Simple broadcast to multiple subscribers
Fan-out to SQS queues
Email, SMS, push notifications
High-throughput pub/sub
Simple filter policies are sufficient
Triggering multiple Lambda functions

🗂️

Choose SQS when…

Reliable work queue needed
Consumer may be slow or unavailable
Need message retention
Backpressure handling
One consumer per message
Batch processing with retries

How They Work Together Core

In production architectures, these services are often combined:

EventBridge + SNS + SQS — Working Together

EventBridge vs Kinesis — Event Bus vs Stream Core

Another common confusion: both EventBridge and Kinesis handle events, but they serve different purposes:

Feature	EventBridge	Kinesis Data Streams
Primary use	Event routing to applications	Real-time data streaming
Data model	Events (processed then gone)	Persistent stream (1-365 days)
Replay	Archive + Replay feature	Built-in (any offset)
Ordering	No guarantee	Per-partition ordering
Consumers	Rules fan-out to different targets	All consumers read same data
Filtering	Rich content-based rules	Consumer must filter
Message size	256 KB	1 MB
Data sources	AWS services, apps, SaaS	App logs, IoT, clickstreams
Retention	Not persistent (archive optional)	Persistent (configurable)

🔀

Use EventBridge When

Route events based on content
AWS service or SaaS events
Different events → different targets
Scheduled triggers (cron)
Event-driven microservices

🌊

Use Kinesis When

Stream large volumes of data
Multiple consumers read same stream
Replay from any point in time
Real-time analytics (clickstream, IoT)
Ordering within partitions matters

👉 They complement each other: Kinesis can be an EventBridge event source (via Lambda). Stream high-volume data through Kinesis, then route specific events to EventBridge for application-level routing.

Common Confusion Points Core

Confusion	Clarification
"SNS and EventBridge both fan out — what's the difference?"	SNS broadcasts to ALL subscribers. EventBridge routes based on content — different events go to different targets. Use EventBridge for intelligent routing; SNS for simple broadcast.
"Can EventBridge replace SNS?"	Sometimes. EventBridge has richer filtering but doesn't support email/SMS directly. For simple fan-out to SQS queues, either works. For content-based routing, use EventBridge.
"Where do messages wait if the consumer is down?"	SQS is the only one that buffers. EventBridge and SNS are transient — if delivery fails and retries exhaust, the event is lost (unless you configure archive/DLQ).
"Which has better filtering?"	EventBridge. It can filter on the entire event body with operators (prefix, suffix, numeric, wildcard). SNS filters only on message attributes.
"Can I use them together?"	Yes, and you often should. EventBridge can route to SNS (for fan-out) or SQS (for buffering). This combo gives you routing + broadcasting + durability.

Decision Flowchart Core

❓

Start Here

Need to buffer messages for a slow consumer? → SQS
Need to broadcast one event to many? → SNS
Need to route based on event content? → EventBridge
Need SaaS integration? → EventBridge
Need scheduled triggers? → EventBridge
Need email/SMS notifications? → SNS

🏆

Common Patterns

Simple pub/sub: SNS → multiple Lambda
Reliable fan-out: SNS → multiple SQS queues
Content routing: EventBridge → different targets
SaaS pipeline: EventBridge → Lambda/SQS
Full combo: EventBridge → SNS → SQS → Workers

🎓 Exam Insight

"Route events based on fields in the message body" → EventBridge
"Broadcast to all subscribers" → SNS
"Buffer work for a consumer" → SQS
"Receive events from SaaS like Zendesk" → EventBridge
"Replace cron with serverless" → EventBridge scheduled rule
"Message must survive consumer downtime" → SQS (not SNS/EventBridge alone)

👉 Key Takeaway

EventBridge routes, SNS broadcasts, SQS buffers — they solve different problems and are most powerful when used together. Choose based on whether you need intelligent routing, simple fan-out, or durable queuing.

Chapter Six

EventBridge Architecture Patterns

Production Architecture Patterns Introductory

EventBridge enables several powerful architecture patterns. These patterns appear repeatedly in production AWS systems:

Pattern 1: Serverless Event Pipeline Core

The most common pattern: trigger processing automatically when something happens in AWS.

Serverless Event Pipeline — S3 Upload → EventBridge → Lambda Processing

📤

Trigger

S3 emits PutObject event when a file is uploaded to the bucket.

🔀

Route

EventBridge rule matches .jpg files and routes to Lambda.

⚡

Process

Lambda resizes the image and stores thumbnails in output bucket.

Pattern 2: Multi-Service Automation Core

React to operational events across your AWS infrastructure automatically.

Multi-Service Automation — CloudWatch Alarm → EventBridge → Multiple Actions

Pattern 3: Microservice Communication Core

Services emit domain events without knowing who consumes them. True microservice decoupling.

Microservice Events — Services Communicate via EventBridge

Pattern 4: SaaS Integration Core

Connect external SaaS providers directly to your AWS architecture:

💳

Payment Processing

Stripe → payment.completed
EventBridge routes to Lambda
Lambda updates order status in DynamoDB
Triggers fulfillment workflow

🔔

Support Tickets

Zendesk → ticket.created
EventBridge routes high-priority tickets
SNS pages on-call engineer
Step Functions escalation workflow

🔧

DevOps

GitHub → pull_request.merged
EventBridge triggers CodePipeline
Automated deployment to staging
Slack notification on completion

📊

Monitoring

Datadog → alert.triggered
EventBridge routes to remediation Lambda
Auto-restart unhealthy services
Create incident ticket

Pattern 5: Cross-Account Event Sharing In-Depth

Share events between AWS accounts for multi-account architectures:

Cross-Account Events — Production Account → Central Audit Account

Pattern 6: Scheduled Automation Core

Replace cron jobs with serverless scheduled rules:

🧹

Daily Cleanup

cron(0 3 * * ? *)

Every day at 3 AM UTC → Lambda deletes expired sessions, cleans temp files.

📊

Hourly Reports

rate(1 hour)

Every hour → Lambda aggregates metrics, sends to CloudWatch custom metrics.

💾

Weekly Backup

cron(0 2 ? * SUN *)

Every Sunday 2 AM → Step Functions orchestrates full database backup.

🎓 Exam Insight

S3 → processing → EventBridge rule on S3 events → Lambda
Multi-action response → one EventBridge rule with multiple targets
Microservice events → custom event bus, services publish domain events
SaaS integration → partner event source → EventBridge
Cross-account → event bus policy + cross-account rule target
Cron replacement → EventBridge scheduled rule → Lambda

👉 Key Takeaway

EventBridge enables six core patterns: serverless pipelines, multi-service automation, microservice communication, SaaS integration, cross-account sharing, and scheduled jobs — all without managing servers.

Chapter Seven

EventBridge + Serverless Architectures

The Serverless Event Backbone Introductory

EventBridge is the natural event layer for serverless architectures. It connects Lambda, Step Functions, and other serverless services without any infrastructure management.

👉 EventBridge + Lambda + Step Functions = fully reactive, serverless architecture. Events trigger functions, functions emit events, workflows orchestrate complex processes — all without a single server to manage.

EventBridge + Lambda Core

Lambda is the most common EventBridge target. EventBridge invokes Lambda asynchronously with the full event as the payload:

⚡

How It Works

EventBridge invokes Lambda asynchronously
Full event JSON is passed as the function payload
Lambda scales automatically with event volume
Built-in retry: 2 retries on failure
Configure DLQ for failed invocations

🎯

Best Practices

Use input transformers to send only needed fields
Configure DLQ to capture failed events
Keep Lambda functions idempotent (retries!)
Use reserved concurrency for critical functions
Monitor with Invocations and Errors metrics

EventBridge + Step Functions Core

For complex workflows that span multiple steps, EventBridge triggers Step Functions state machines:

EventBridge → Step Functions — Complex Workflow Orchestration

🔄

When to Use Step Functions

Multi-step business processes (order fulfillment)
Workflows that need retries and error handling
Long-running processes (up to 1 year)
Human approval steps
Parallel processing with aggregation

When to Use Lambda Directly

Single-step processing
Simple transformations
Real-time event reactions
Stateless operations
When 15-minute timeout is sufficient

Event Choreography vs Orchestration In-Depth

Two patterns for coordinating serverless workflows:

Aspect	Choreography (EventBridge)	Orchestration (Step Functions)
Control	Decentralized — each service reacts to events	Centralized — workflow defines all steps
Coupling	Loosely coupled — services don't know each other	Tighter coupling — workflow knows all services
Visibility	Harder to trace end-to-end flow	Clear visualization in Step Functions console
Error handling	Each service handles its own errors	Centralized retry, catch, fallback
Best for	Independent services, high scalability, loose coupling	Complex workflows, sequential steps, error recovery

👉 In practice, use both: EventBridge for triggering and loose coupling, Step Functions for complex orchestration. EventBridge triggers Step Functions, which orchestrates the detailed workflow.

Serverless Architecture Diagram Core

Complete Serverless Architecture — EventBridge as the Event Backbone

EventBridge Pipes — Direct Integration In-Depth

EventBridge Pipes provides point-to-point integrations between sources and targets with optional filtering and transformation:

🔗

What Pipes Do

Connect source → (filter) → (enrich) → target
Sources: SQS, Kinesis, DynamoDB Streams, Kafka
Targets: Lambda, Step Functions, API Gateway, EventBridge
Built-in filtering and transformation
No code required for simple integrations

🆚

Pipes vs Rules

Rules: Fan-out to multiple targets, event bus routing
Pipes: Point-to-point, polling sources, enrichment
Use Pipes for: SQS → Lambda, DynamoDB Streams → Step Functions
Use Rules for: S3 events → multiple consumers, content routing

🎓 Exam Insight

EventBridge + Lambda — asynchronous invocation, automatic retry (2x), configure DLQ
EventBridge + Step Functions — complex workflows, error handling, long-running processes
Choreography vs Orchestration — loose coupling (EventBridge) vs centralized control (Step Functions)
EventBridge Pipes — point-to-point from polling sources (SQS, Kinesis, DynamoDB Streams)
Fully serverless — API Gateway → Lambda → EventBridge → Lambda/Step Functions

👉 Key Takeaway

EventBridge is the event backbone of serverless AWS architectures — connecting Lambda, Step Functions, and other services to create fully reactive systems that scale automatically and require zero server management.

Chapter Eight

Security, Reliability & Scaling

Access Control — Who Can Send and Receive Events Core

EventBridge uses two layers of access control:

🔑

IAM Policies

Control which principals can call EventBridge APIs:

events:PutEvents — send events
events:PutRule — create rules
events:PutTargets — attach targets
events:DescribeEventBus — view bus

Attach to IAM users, roles, Lambda execution roles.

📋

Resource-Based Policies

Control who can send events TO a specific event bus:

Attached directly to the event bus
Required for cross-account event delivery
Allow specific accounts or organizations
Allow AWS services to send events

Essential for multi-account architectures.

Cross-Account Access In-Depth

To receive events from another AWS account, configure a resource policy on the target event bus:

1️⃣

Target Account — Event Bus Policy

Allow the source account to put events:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {
      "AWS": "arn:aws:iam::111111111111:root"
    },
    "Action": "events:PutEvents",
    "Resource": "arn:aws:events:us-east-1:
                 222222222222:event-bus/audit-bus"
  }]
}

2️⃣

Source Account — Rule Target

Create a rule targeting the cross-account bus:

Rule in source account
Target ARN: the remote event bus
IAM role with events:PutEvents on remote bus

Both policy AND IAM role required.

Encryption Core

🔒

Encryption in Transit

All EventBridge API calls use HTTPS/TLS
Events delivered to targets use encrypted connections
No configuration required — always on

🗝️

Encryption at Rest

Custom event buses: optional KMS CMK encryption
Archives: encrypted with KMS
Default bus: AWS-managed encryption
Specify CMK on bus creation for compliance

Reliability — Retries and Dead-Letter Queues Core

EventBridge has built-in reliability mechanisms:

Mechanism	Behavior	Configuration
Automatic Retries	EventBridge retries failed deliveries with exponential backoff	Up to 24 hours of retries by default
Retry Policy	Configure max retries and max event age per target	1-185 retries, 60 seconds to 24 hours age
Dead-Letter Queue	Failed events sent to SQS queue after retries exhausted	Configure per-rule: specify SQS queue ARN

👉 Always configure a DLQ for production rules. Without a DLQ, events that fail all retries are silently dropped. With a DLQ, you can inspect failures, fix issues, and reprocess events.

Event Archive and Replay Core

EventBridge can archive events for later replay — powerful for disaster recovery and debugging:

📦

Event Archive

Archive all events or filter by pattern
Retention: 1 day to indefinite
Stored encrypted in AWS-managed storage
Pay for storage used

🔄

Event Replay

Replay archived events to the event bus
Filter by time range
Replayed events processed by current rules
Use for recovery, testing, or reprocessing

Scaling and Limits Core

EventBridge is designed for massive scale with soft limits that can be increased:

Limit	Default	Adjustable
PutEvents requests	10,000 / second / region	Yes — request increase
Events per PutEvents call	10 events per batch	No
Event size	256 KB	No
Rules per event bus	300	Yes — request increase
Targets per rule	5	No
Invocations per second (Lambda)	Lambda concurrency limits apply	Yes — Lambda limits

Monitoring with CloudWatch Core

EventBridge publishes metrics to CloudWatch automatically at 1-minute granularity:

Metric	Description	Alarm Recommendation
`Invocations`	Events matched by rules	Baseline for normal volume
`FailedInvocations`	Delivery failures (after all retries)	Alarm if >0 for 5 minutes
`TriggeredRules`	Rules that matched events	Monitor unexpected matches
`ThrottledRules`	Rules throttled due to rate limits	Alarm if >0 (request limit increase)
`DeadLetterInvocations`	Events sent to Dead-Letter Queue	Critical alarm if >0
`PutEventsRequestCount`	Events received by event bus	Baseline for cost planning
`PutEventsFailedCount`	Events rejected (invalid format)	Alarm if >0 (coding error)

📊

Where to Find Metrics

CloudWatch → Metrics → AWS/Events
Per event bus, per rule
Some metrics aggregated by bus
1-minute granularity

🔔

Critical Alarm Setup

FailedInvocations > 0 for 5 min → Page ops
DeadLetterInvocations > 0 → Critical alert
ThrottledRules > 0 → Request limit increase
Set SNS action for all alarms

When NOT to Use EventBridge In-Depth

🚫

Don't Use EventBridge For

Synchronous request/response — use API calls
High-frequency streaming — use Kinesis
Message ordering required — use SQS FIFO
Large payloads (>256KB) — store in S3, send reference
Long message retention — use SQS (14 days)

✅

Do Use EventBridge For

Event-driven architectures
Content-based routing
AWS service integration
SaaS event ingestion
Scheduled automation
Cross-account event sharing

Security Best Practices Core

Best Practice	Why It Matters
Use custom event buses for application events	Isolate from AWS service events, easier access control
Apply least-privilege IAM policies	Limit who can create rules and send events
Enable KMS encryption for sensitive events	Compliance requirements, data protection
Configure DLQ on all production rules	Prevent silent event loss on failures
Use resource policies for cross-account	Explicit trust, audit trail
Monitor FailedInvocations metric	Early detection of delivery issues
Archive events for critical workflows	Enable replay for disaster recovery

🎓 Exam Insight

Cross-account events — requires resource policy on target bus + IAM role in source
Events lost after retries? — configure Dead-Letter Queue (SQS)
Replay past events — Event Archive + Replay feature
Rate limit is 10,000 events/sec — can be increased via support request
Max event size is 256 KB — for larger data, store in S3, send reference
Encryption at rest — use KMS CMK on custom event buses

👉 Key Takeaway

EventBridge is secure (IAM + resource policies + KMS), reliable (retries + DLQ + archive), and scalable (10K+ events/sec). Always configure DLQs for production, monitor FailedInvocations, and use archives for critical workflows.

Amazon EventBridge · Complete

EventBridge is a serverless event bus — routes events between AWS services, your apps, and SaaS providers
Core components — Event Bus (receives), Rules (filter/route), Targets (deliver), Events (256 KB JSON)
Content-based routing — pattern matching on event fields (prefix, suffix, numeric, wildcard)
vs SNS vs SQS — EventBridge routes, SNS broadcasts, SQS buffers; use together for best results
Architecture patterns — serverless pipelines, multi-service automation, microservice events, SaaS integration, cross-account, scheduled jobs
Serverless integration — Lambda (async), Step Functions (orchestration), choreography + orchestration patterns
Security — IAM policies + resource-based policies for cross-account, KMS encryption for custom buses
Reliability — automatic retries (24 hrs), configurable retry policy, Dead-Letter Queues (SQS)
Archive & Replay — store events for disaster recovery, replay to reprocess or test
Scaling — 10,000 events/sec default (increasable), 300 rules/bus, 5 targets/rule