Is EventBridge - Event-Driven Architecture at Scale free to learn on DevOps Network?

Yes - this topic, like everything on DevOps Network, is 100% free with no paywall or sign-up gate.

EventBridge - Event-Driven Architecture at Scale

Q: What does the EventBridge - Event-Driven Architecture at Scale topic cover?

Build event-driven architectures with EventBridge rules, custom event buses, Schema Registry, and EventBridge Pipes to connect AWS services without glue code.

What you will learn

What event-driven architecture is and why it decouples services better than direct calls
EventBridge event buses — Default, Partner, and Custom
Schedule rules — running tasks on a timer without managing cron servers
Event pattern rules — reacting automatically when something happens in AWS
How to write event pattern filters to match exactly what you need
Schema Registry — auto-discovering event structure for type-safe code
EventBridge Pipes — connecting sources to targets with filtering and transformation
Cross-account and cross-region event routing
Real production patterns — security alerting, deployment triggers, data pipelines

Why this matters

At Zerodha, when a trade is executed, twelve downstream systems need to know — ledger, tax records, SMS notification, email, portfolio analytics, risk management, audit log, and more. Calling each one directly from the trade service creates tight coupling. Any slow or failed downstream call slows or fails the trade confirmation. EventBridge lets the trade service publish one event. Every downstream system subscribes independently. The trade service does not know or care who is listening.

At Razorpay, when the root IAM user logs in at any time, the security team gets an immediate alert. When a production EC2 instance is terminated, an incident is auto-created. None of this requires custom polling or cron jobs. EventBridge watches AWS and reacts instantly.

What is Amazon EventBridge

EventBridge is a serverless event bus. Services publish events. Rules decide what to do with each event. Targets receive and act on them.

◈ DIAGRAM

Something happens anywhere
    ↓
Event published to EventBridge
    ↓
Rules evaluated — does this event match any pattern?
    ↓
Matching rules send the event to their targets
    ↓
Targets act: Lambda runs, SQS receives message, Step Functions starts

The key insight: the publisher does not know who is listening. Adding a new consumer never requires changing the publisher. This is loose coupling.

Three Event Buses

Default Event Bus:

Receives all events from AWS services automatically. EC2 state changes, S3 uploads, CodeBuild results, CloudTrail API calls, RDS snapshots — all flow here with zero configuration.

◈ DIAGRAM

EC2 instance stopped → event automatically on Default Bus
S3 object created    → event automatically on Default Bus
IAM user created     → event automatically on Default Bus

Partner Event Bus:

Third-party SaaS services send events directly into your AWS account. Datadog, GitHub, Stripe, Zendesk, PagerDuty — when something happens in their system, an event appears in your EventBridge.

◈ DIAGRAM

GitHub pull request merged → GitHub sends event to your Partner Bus
Stripe payment succeeded   → Stripe sends event to your Partner Bus

Custom Event Bus:

Your own applications publish custom events here. One application publishes. Multiple applications subscribe. No direct calls between them.

◈ DIAGRAM

Order Service publishes: { "source": "devops.orders", "detail-type": "OrderPlaced", ... }
Fraud Service subscribes → gets the event
Email Service subscribes → gets the event
Analytics subscribes     → gets the event

Two Ways to Use EventBridge

Schedule Rules — run on a timer:

Like a managed cron job in the cloud. No server needed. Runs a Lambda, starts a Step Functions workflow, or sends a message to SQS on a schedule.

◈ DIAGRAM

Every day at 2 AM → trigger Lambda → clean up old logs
Every 5 minutes   → trigger Lambda → check health of external payment API
First day of month → start Step Functions → generate monthly invoices
Every weekday 8:30 AM → send SQS message → scale up trading infrastructure

Two schedule formats:

TEXT

Rate expression:  rate(5 minutes)   rate(1 hour)   rate(7 days)
Cron expression:  cron(0 2 * * ? *)  (2 AM UTC every day)

Event Pattern Rules — react to something that happened:

Watch for specific events and trigger a response automatically.

Bash

Root user signs into AWS console
    ↓ EventBridge sees: source=aws.signin, userIdentity.type=Root
    ↓ Rule matches
    ↓ SNS sends email to security team immediately
 
EC2 instance terminated
    ↓ EventBridge sees: source=aws.ec2, detail-type=EC2 Instance State-change, state=terminated
    ↓ Rule matches
    ↓ Lambda creates a PagerDuty incident
 
CodeBuild build fails
    ↓ EventBridge sees: source=aws.codebuild, detail.build-status=FAILED
    ↓ Rule matches
    ↓ Slack notification sent via Lambda

Writing Event Patterns

An event pattern is a JSON filter. An event matches if all specified fields match.

Match any EC2 state change:

JSON

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

Match only EC2 terminations:

JSON

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

Match root user login (security critical):

JSON

{
  "source": ["aws.signin"],
  "detail-type": ["AWS Console Sign In via CloudTrail"],
  "detail": {
    "userIdentity": {
      "type": ["Root"]
    }
  }
}

Match S3 uploads to a specific prefix:

JSON

{
  "source": ["aws.s3"],
  "detail-type": ["Object Created"],
  "detail": {
    "bucket": {
      "name": ["devops-uploads-prod"]
    },
    "object": {
      "key": [{ "prefix": "invoices/" }]
    }
  }
}

Patterns support: exact match, prefix, suffix, anything-but, numeric ranges, and exists/not-exists checks.

EventBridge Targets — Where Events Go

Target	What happens
Lambda function	Function invoked with event as input
SQS queue	Message added to queue
SNS topic	Notification published to all subscribers
Step Functions	Workflow execution started
ECS task	New container task launched
API Gateway	HTTP request made
Kinesis Data Streams	Record added to stream
Another EventBridge bus	Event forwarded (cross-account)
CodeBuild	Build triggered
CodePipeline	Pipeline execution started

One rule can have up to 5 targets. The same event is delivered to all matching targets simultaneously.

Schema Registry — Know Your Event Structure

EventBridge can automatically discover the structure of every event flowing through your buses. The Schema Registry stores these structures and generates typed code in Python, Java, TypeScript, or Go.

◈ DIAGRAM

Events flow through EventBridge
    ↓
Schema Registry discovers their structure automatically
    ↓
You download a generated code binding
    ↓
Your Lambda already knows: event.detail.orderId is a string
                           event.detail.amount is a number
No manual JSON parsing. Type-safe code from the start.

Finding schemas:

◈ DIAGRAM

EventBridge → Schema Registry → Discovered schemas
Or search the AWS schema registry: 100+ pre-built schemas for all AWS services

EventBridge Pipes — Simple Point-to-Point Connections

Pipes connect a source directly to a target with optional filtering and transformation in between. No Lambda glue code needed for simple routing.

◈ DIAGRAM

Source (SQS, Kinesis, DynamoDB Streams, Kafka)
    ↓
Filter (optional — only pass matching events)
    ↓
Enrichment (optional — Lambda adds data to the event)
    ↓
Target (Lambda, Step Functions, SQS, HTTP endpoint)

Example without Pipes:

◈ DIAGRAM

DynamoDB Streams → Lambda (reads stream, filters, formats) → SQS
You write and maintain the Lambda glue code

Same flow with Pipes:

◈ DIAGRAM

DynamoDB Streams → Pipe (filter + transform) → SQS
No Lambda. No code. Just configuration.

Cross-Account and Cross-Region Events

EventBridge can route events between AWS accounts and regions.

Cross-account:

◈ DIAGRAM

Account A (Production) → Custom Bus → EventBridge Rule
    ↓ Send to Account B
Account B (Security) → receives all production events
Security team monitors all accounts from one central bus

Useful for: centralising security events, aggregating audit logs, sharing events between team accounts.

Cross-region:

◈ DIAGRAM

ap-south-1 (primary) → event published
    ↓ rule forwards to
ap-southeast-1 (secondary) → local processing

Useful for: DR architectures, replicating events to a standby region.

Real Production Patterns

Pattern 1 — Security alerting:

◈ DIAGRAM

CloudTrail logs any API call → EventBridge Default Bus
Rule: match any action by Root user OR any DeleteBucket call
Target: SNS → email to security team
Response time: under 30 seconds from action to alert

Pattern 2 — Auto-tagging new resources:

◈ DIAGRAM

EC2 instance launched without required tags
Rule: match EC2 RunInstances without Department tag
Target: Lambda → adds default tags automatically
No manual compliance enforcement needed

Pattern 3 — Deployment pipeline trigger:

◈ DIAGRAM

Developer merges PR to main branch
GitHub (Partner Event Bus) sends PullRequestMerged event
Rule matches
Target: CodePipeline → deployment starts automatically

Pattern 4 — Scheduled data pipeline:

◈ DIAGRAM

Every night at midnight
EventBridge schedule fires
Target: Glue job → transforms yesterday's data from S3 to Parquet
No cron server. No EC2. Fully serverless.

Hands-on Lab — Schedule Rule and Security Alert Rule

Step 1 — Create an SNS topic for alerts

◈ DIAGRAM

SNS → Topics → Create topic
Type: Standard    Name: devops-security-alerts
Create topic
 
Subscribe your email:
Subscriptions → Create subscription → Email → your email → Create
Confirm from inbox before continuing.

Step 2 — Create a Schedule Rule (runs every 5 minutes)

◈ DIAGRAM

EventBridge → Rules → Create rule
Name: devops-health-check
Rule type: Schedule
Schedule pattern: Rate → 5 minutes
Next
 
Target: SNS topic → devops-security-alerts
Message: Health check ping from EventBridge
Create rule
 
Within 5 minutes an email arrives. EventBridge is running your schedule.

Step 3 — Create a Security Alert Rule (root login)

◈ DIAGRAM

EventBridge → Rules → Create rule
Name: root-login-alert
Rule type: Event pattern
Event source: AWS events
 
Event pattern — paste:

JSON

{
  "source": ["aws.signin"],
  "detail-type": ["AWS Console Sign In via CloudTrail"],
  "detail": {
    "userIdentity": {
      "type": ["Root"]
    }
  }
}

◈ DIAGRAM

Next → Target: SNS topic → devops-security-alerts
Create rule
 
Test it: log in as root user → within 60 seconds an email arrives.

Step 4 — Create a Custom Event Bus

◈ DIAGRAM

EventBridge → Event buses → Create event bus
Name: devops-orders-bus
Create event bus
 
EventBridge → Rules → Create rule
Event bus: devops-orders-bus (not the default)
Name: new-order-processor
Event pattern:

JSON

{
  "source": ["devops.orders"],
  "detail-type": ["OrderPlaced"]
}

◈ DIAGRAM

Target: SNS → devops-security-alerts (reusing for demo)
Create rule

Step 5 — Publish a custom event and test

Bash

aws events put-events \
  --entries '[{
    "EventBusName": "devops-orders-bus",
    "Source": "devops.orders",
    "DetailType": "OrderPlaced",
    "Detail": "{\"orderId\": \"ORD-001\", \"city\": \"Mumbai\", \"amount\": 450}"
  }]' \
  --region ap-south-1

TEXT

Check your email — the order event triggers the SNS notification.
Your custom application event flowing through EventBridge to a target.

Step 6 — Cleanup

◈ DIAGRAM

EventBridge → Rules → delete devops-health-check and root-login-alert
EventBridge → Event buses → delete devops-orders-bus
SNS → devops-security-alerts → Delete topic

Common Mistakes to Avoid

Common Mistake
Putting business logic rules in the wrong event bus. Custom application events belong on a Custom Event Bus — not the Default Bus. The Default Bus is for AWS service events. Mixing them makes filtering complex and creates unnecessary noise.

Common Mistake
Using EventBridge Schedules and forgetting they still run when your Lambda has errors. A schedule fires whether or not the previous execution succeeded. If your Lambda fails, the next schedule fires and tries again. Build idempotent targets that can safely run multiple times.

Tip
EventBridge archives let you replay past events. Enable archiving on your event bus and you can replay any event from the past — debugging a production issue, testing a new rule against real historical events, recovering from a consumer outage. Turn it on from day one — you cannot replay events that were not archived.