Amazon EventBridge (formerly called CloudWatch Events) - Overview & Hands-On.
Scope:
- Intro,
- Key Concepts,
- Evolution from CloudWatch Events,
- Common Use Cases,
- Link to official documentation,
- The concept: EventBridge,
- Event Flow & Architecture,
- Event Types,
- Key Features,
- Common Use Cases,
- Comparison of EventBridge vs. SNS vs. SQS,
- Pricing,
- Project: Hands-On.
Intro:
- Amazon EventBridge is a serverless event bus service that was formerly known as Amazon CloudWatch Events.
- Amazon EventBridge provides a real-time stream of system events from AWS services, twtech applications, and software as a service (SaaS) applications.
- Amazon EventBridge delivers real-time stream to various targets for automated actions.
- EventBridge makes it easy to connect applications using events.
- Think of Amazon EventBridge as the “glue” for event-driven architectures inside AWS and beyond.
- Event Bus: The primary router that receives events from various sources and delivers them to targets based on rules.
- The default event bus, as well as rules created in the previous CloudWatch Events console, are available within the EventBridge console.
- Rules: Rules define criteria for matching incoming events (using event patterns) and specify the target services that should be triggered when a match occurs.
- Targets: These are the destinations (e.g., AWS Lambda functions, Amazon SNS topics, Amazon SQS queues) where EventBridge sends events.
- Amazon EventBridge is the evolution of CloudWatch Events and is fully backward compatible, using the same API.
- Existing code and templates using the CloudWatch Events API continue to work with EventBridge.
- Integration with third-party SaaS partners (like Zendesk, PagerDuty, and Auth0).
- A schema registry that helps manage event schemas.
- EventBridge Pipes, which are designed for simple, point-to-point integrations with optional data transformation and enrichment.
- Automating AWS services: Responding to state changes in AWS resources, such as an EC2 instance changing from
pendingtorunning. - Monitoring and Auditing: Acting on AWS API calls recorded by AWS CloudTrail to enhance security and operational posture in near real-time.
- Decoupling Applications: Building event-driven architectures that make it easier to decouple application services and make systems more extensible.
- Scheduling: Using cron or rate expressions to trigger actions on a defined schedule.
https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html
1. The concept: EventBridge
- Event Router / Event Bus: Central service for capturing events and routing them to targets.
- Fully Managed: No infrastructure to run, scales automatically.
- Event Sources: Can come from AWS services, twtech applications, or SaaS integrations.
- Rules: Define patterns to match specific events.
- Targets: Where events get delivered (Lambda, Step Functions, SNS, SQS, Kinesis, API destinations, etc.).
2. Event Flow & Architecture
1. Event Sources → AWS service events, custom events, SaaS partner events.
2. Event Bus → Default event bus or custom buses for isolation.
3. Rules → Pattern-based filtering (JSON matching).
4. Targets → One event can be sent to multiple targets.
3. Event Types
- AWS
Service Events: e.g., EC2 state changes, S3 object
events, DynamoDB table updates.
- Custom
Events: Published from twtech applications (via
PutEvents API). - SaaS Partner Events: From integrated vendors (Datadog, Auth0, etc.).
- Archive / Replay: twtech
can store and replay past events for troubleshooting/testing.
- AWS Service Events: e.g., EC2 state changes, S3 object events, DynamoDB table updates.
- Custom
Events: Published from twtech applications (via
PutEventsAPI). - SaaS Partner Events: From integrated vendors (Datadog, Auth0, etc.).
- Archive / Replay: twtech can store and replay past events for troubleshooting/testing.
4. Key Features
- Schema Registry:
Automatically discovers event structures (schemas) and
makes them available as code bindings (Java, Python, TypeScript).
- Cross-Account / Cross-Region: Events can
be routed across AWS accounts and regions.
- API Destinations: Send events outside AWS via
HTTP endpoints with connection management.
- Replay Capability: Reprocess
historical events (great for debugging).
- Dead
Letter Queues (DLQs): Handle
failed event deliveries.
- Schema Registry: Automatically discovers event structures (schemas) and makes them available as code bindings (Java, Python, TypeScript).
- Cross-Account / Cross-Region: Events can be routed across AWS accounts and regions.
- API Destinations: Send events outside AWS via HTTP endpoints with connection management.
- Replay Capability: Reprocess historical events (great for debugging).
- Dead Letter Queues (DLQs): Handle failed event deliveries.
5. Common Use Cases
- Decoupled Microservices: Services
react asynchronously to events.
- Audit & Compliance: Capture
changes across accounts (CloudTrail → EventBridge → SIEM/S3).
- Ops Automation: Auto-remediation (e.g.,
instance unhealthy → auto restart).
- SaaS Integration: Ingest
3rd-party events into AWS workflows.
- Data Pipelines: Trigger
ETL or analytics jobs when new data arrives.
- Decoupled Microservices: Services
react asynchronously to events.
- Audit & Compliance: Capture changes across accounts (CloudTrail → EventBridge → SIEM/S3).
- Ops Automation: Auto-remediation (e.g., instance unhealthy → auto restart).
- SaaS Integration: Ingest 3rd-party events into AWS workflows.
- Data Pipelines: Trigger ETL or analytics jobs when new data arrives.
6. Comparison of EventBridge vs. SNS vs. SQS
|
Feature |
EventBridge |
SNS |
SQS |
|
Routing |
Pattern-based
filtering |
Topic-based |
Queue-based |
|
Targets |
Many
AWS services + SaaS + APIs |
Subscribers (Lambda,
SQS, HTTPS) |
Polling
consumers |
|
Fan-out |
Yes (multi-target) |
Yes |
No (one
queue per consumer group) |
|
Replay |
Yes |
No |
No |
|
Schema Registry |
Yes |
No |
No |
7. Pricing
- Charged per event published +
optional archive storage + schema
registry lookups.
- Free tier: 100,000 events/month.
- Charged per event published + optional archive storage + schema registry lookups.
- Free tier: 100,000 events/month.
Project: Hands-On.
- How twtech uses Amazon EventBridge to provide a real-time stream of system events from AWS services, its applications, and software as a service (SaaS) applications.
Search for aws service: Eventbridge.
Rules
A rule watches for specific types of events.
When a matching event occurs, the event is routed to the targets associated with the rule. A rule can be associated with one or more targets.
Create rule: way
to respond to events.
Define rule detail (Rule detail)
Name: twtechInstanceRule
- Build event pattern
Select target(s) Permissions:
- When using the EventBridge console, EventBridge will automatically configure the proper permissions for the selected targets.
- If twtech is using the AWS CLI, SDK, or CloudFormation, it needs to configure the proper permissions.
- Added Permissions:
- Additional settings
Configure tags - optional
- Review and create
- Create rule: twtechInstanceRule
- How twtech creates schedule rules for its instance to: Run Every Hour
Define rule detail
- Name: twtechEC2RunEveryHour
- Continue in EventBridge Scheduler:
- Specify schedule detail: This takes configuration to a different UI (from Buses to Sheduler)
- Schedule
patter
- Settings - optional
- Review and create schedule
- How twtech creates Custom event buses: twtechCustomEvenBus
Create
event bus: Event bus detail
Name: twtechCustomEvenBus
- How twtech create Replay events: for Debugging if need arise
- Start new replay
- Partner Events sources that twtech may also use (Third-Party Partners)
API destinations: How twtech sends rules to specified destinations outside aws.
- API destinations are third-party partner targets that twtech can invoke using an HTTP endpoint.
- This lets twtech to seamlessly integrate its applications with a range of SaaS partners without having to write code or deploy additional infrastructure.
- With API destinations, twtech can easily build modern SaaS-connected solutions, and reduce data silos by simplifying information exchange between applications.
- Each API destination uses a Connection that defines the authorization method and credentials to use to connect to the HTTP endpoint.
- When twtech configures the authorization settings and create a connection, it creates a secret in AWS Secrets Manager to securely store the authorization information.
- twtech can also add additional parameters to include in the connection as appropriate for its application.
- Schema available to twtech registry in aws: these provide the type of Json file that can be used in the events.
- For example: aws.ecs@ECSContainerInstanceStateChange
# Sample-Schema-aws.ecs@ECSContainerInstanceStateChange.json
{
"openapi":
"3.0.0",
"info": {
"version":
"1.0.0",
"title":
"ECSContainerInstanceStateChange"
},
"paths": {},
"components":
{
"schemas": {
"AWSEvent": {
"type":
"object",
"required": ["detail-type", "resources",
"id", "source", "time", "detail",
"region", "version", "account"],
"x-amazon-events-detail-type":
"ECS Container Instance State Change",
"x-amazon-events-source": "aws.ecs",
"properties": {
"detail": {
"$ref":
" #/components/schemas/ECSContainerInstanceStateChange"
},
"detail-type":
{
"type": "string"
},
"resources": {
"type": "array",
"items": {
"type": "string"
}
},
"id":
{
"type": "string"
},
"source": {
"type": "string"
},
"time": {
"type": "string",
"format": "date-time"
},
"region": {
"type": "string"
},
"version": {
"type":
"string"
},
"account": {
"type": "string"
}
}
},
"ECSContainerInstanceStateChange": {
"type":
"object",
"required": ["registeredResources",
"remainingResources", "agentConnected",
"versionInfo", "version", "clusterArn",
"containerInstanceArn", "status", "updatedAt"],
"properties": {
"versionInfo": {
"$ref": "#/components/schemas/VersionInfo"
},
"ec2InstanceId": {
"type":
"string"
},
"attachments": {
"type": "array",
"items": {
"$ref": "#/components/schemas/AttachmentDetails"
}
},
"registeredResources": {
"type": "array",
"items": {
"$ref": "#/components/schemas/ResourceDetails"
}
},
"remainingResources": {
"type": "array",
"items": {
"$ref": "#/components/schemas/ResourceDetails"
}
},
"runningTasksCount": {
"type": "number"
},
"registeredAt": {
"type": "string",
"format": "date-time"
},
"agentConnected": {
"type": "boolean"
},
"agentUpdateStatus": {
"type": "string"
},
"version": {
"type": "number"
},
"pendingTasksCount": {
"type": "number"
},
"clusterArn": {
"type": "string"
},
"attributes": {
"type": "array",
"items": {
"$ref": "#/components/schemas/AttributesDetails"
}
},
"containerInstanceArn": {
"type": "string"
},
"status": {
"type": "string"
},
"statusReason": {
"type": "string"
},
"updatedAt": {
"type": "string",
"format":
"date-time"
},
"accountType": {
"type": "string"
}
}
},
"VersionInfo": {
"type":
"object",
"properties": {
"dockerVersion": {
"type": "string"
},
"agentHash": {
"type": "string"
},
"agentVersion": {
"type": "string"
}
}
},
"AttachmentDetails": {
"type":
"object",
"properties": {
"id":
{
"type": "string"
},
"type": {
"type": "string"
},
"status": {
"type": "string"
},
"details": {
"type": "array",
"items": {
"type": "object",
"properties": {
"name": {
"type": "string"
},
"value": {
"type": "string"
}
}
}
}
}
},
"AttributesDetails": {
"type":
"object",
"properties": {
"name": {
"type": "string"
},
"value": {
"type": "string"
}
}
},
"ResourceDetails":
{
"type":
"object",
"required": ["name", "type"],
"properties": {
"integerValue": {
"type": "number"
},
"longValue": {
"type": "number"
},
"doubleValue": {
"type": "number"
},
"name": {
"type": "string"
},
"stringSetValue": {
"type": "array",
"items": {
"type": "string",
"nullable": true
}
},
"type": {
"type": "string"
}
}
}
}
}
}
No comments:
Post a Comment