EventBridge Event Bus | Overview.

Amazon EventBridge Event Bus - Overview.

Scope:

• Intro,
• Key Concepts,
• Architecture,
• How Amazon EventBridge event bus Works,
• Link to official documentation,
• The concept: Event Bus,
• By default, every AWS account comes with,
• Insights.

Intro:

• Amazon EventBridge event bus is a serverless event router that acts as the central hub in an event-driven architecture. 
• Amazon EventBridge event bus receives events from various sources, then uses rules to filter and route them to specified targets. 

Key Concepts

• Event Sources: Events can come from AWS services (like Amazon EC2 state changes), custom applications, or third-party SaaS partners (such as Salesforce or MongoDB Atlas).
• Event Bus: The core component where events are ingested.
• Default event bus: Automatically receives events from AWS services within twtech account.
• Custom event buses: Created for events from twtech custom applications.
• Partner event buses: Receive events from supported SaaS partners.
• Rules: Rules are attached to an event bus and use event patterns (JSON objects) to match specific incoming events. 
• They define which events should be sent to which targets.
• Targets: When an event matches a rule, EventBridge sends it to a specified destination for processing. 
• Targets can be various AWS services, including AWS Lambda functions, Amazon SQS queues, or AWS Step Functions. 

Architecture:

How Amazon EventBridge event bus Works

1. An event source sends an event to an event bus.
2. EventBridge evaluates the event against all rules associated with that event bus.
3. If an event matches a rule's pattern, EventBridge routes it to the target(s) defined by that rule. 

Link to official documentation:

Amazon EventBridge documentation.

 https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-event-bus.html

The concept: Event Bus

• An Event Bus in Amazon EventBridge is the central routing layer where events land, get filtered, and are then sent to the right destinations.
• Think of it as a message highway:
• Producers (AWS services, SaaS apps, or custom apps) put events on it.
• Rules inspect and match those events.
• Targets (services, apps, workflows) consume them.

By default, every AWS account comes with:

• Default Event Bus – receives events from AWS services.
• Custom Event Buses – twtech can create for its apps or services.
• Partner Event Buses – created automatically when twtech connects an SaaS integration.

 Event Flow in an Event Bus

1. Event Ingestion
• Events arrive from sources (AWS service → e.g., EC2 state change, SaaS partner → e.g., Zendesk ticket, or custom → twtech-app posting JSON).
• The event is JSON structured with source, detail-type, detail, time, id, etc.
2. Event Bus Processing
• The bus itself does not transform events—it just routes.
• Events are passed to Rules attached to that bus.
3. Rule Evaluation
• Each rule defines:
• Event Pattern Matching: Match by fields like source, detail-type, region, or custom JSON fields in detail.
• Optional Input Transformation: Adjust the payload before sending to targets (mask, enrich, remap fields).
• Multiple rules can match the same event → fan-out model.
4. Target Invocation
• Targets can be AWS services (Lambda, Step Functions, SQS, SNS, Kinesis, API destinations, etc.).
• Each rule can have multiple targets.
• EventBridge handles delivery retries (up to 24 hours, with exponential backoff).
• Dead-letter queues (DLQ) or destinations can be configured for failures.

 Insights:

Key Concepts to Deep Dive

1. Event Bus Types

• Default Bus: Always present, can’t be deleted.
• Custom Bus: For organizing custom applications or microservices (e.g., orders-bus, billing-bus).
• Partner Bus: Created when connecting SaaS apps like Shopify, Datadog, Zendesk.

2. Security & Access Control

• Event buses have resource policies.
• twtech can allow or deny which accounts, services, or apps can put events on the bus.
• Enables cross-account event routing (e.g., a centralized logging account receiving events from multiple child accounts).

3. Event Replay

• EventBridge archives can store selected events for replay.
• Useful for debugging, testing, or recovering from downstream outages.

4. Schema Registry

• Captures event schemas automatically.
• Developers can download language-specific bindings (Java, Python, TypeScript, etc.) for strongly-typed integration.

5. Throughput & Scaling

• EventBridge is fully managed, horizontally scalable.
• Soft limits exist (transactions per second), but can be raised.
• Designed for high-fan-out architectures (one event → many targets).

6. Ordering & Delivery

• Events are not guaranteed to be delivered in order.
• At-least-once delivery is guaranteed.
• For strict ordering, use Kinesis or SQS FIFO downstream.

Sample Architecture with a Multi-Bus System (Imagine an e-commerce platform):

• Order Service puts OrderPlaced event on orders-bus.
• Rules:
• One rule matches OrderPlaced → sends to Billing Lambda.
• Another rule matches OrderPlaced → sends to Inventory Step Function.
• Another rule matches OrderPlaced → sends to Analytics Kinesis Stream.
• Shipping Service has its own shipping-bus, but listens to billing confirmation events from orders-bus.
• Cross-account: Analytics team’s AWS account subscribes to replayed events for ML models.

NB:

• This separation of buses helps decouple teams, reduce noisy filtering, and apply least-privilege access policies.

 Best Practices

• Use multiple buses for domain-driven design (e.g., per business unit or bounded context).
• Keep rules lightweight—push heavy processing to Lambda or Step Functions.
• Use Input Transformers to reduce payload before hitting targets (cheaper + faster).
• Archive strategically for replay and auditing.
• Use Cross-account policies for centralized governance.
• Use DLQs (Dead-Letter-Queues) for guaranteed observability of failures.