EventBridge
Last updated
Last updated
EventBridge receives events from sources such as AWS services or third-party applications. A serverless event bus evaluates the data against sets of rules, and then – provided that the data matches a rule – forwards it in real-time to other AWS services, event buses, HTTP endpoints, or SaaS applications.
This primarily enables the construction of event-driven applications, but more importantly, from a security perspective, it enhances monitoring and auditing capabilities and allows for automated incident response.
Changes are constantly occurring in your AWS environment, whether user-driven or part of natural lifecycles. A user may upload an object to an S3 bucket, or an auto-scaling group may launch an EC2 instance.
These changes generate events, and most AWS services send these events to your default event bus in EventBridge. Events can also be sent from external applications and event buses in other AWS regions or accounts. Wherever they come from, all events are sent through an event bus.
Each event bus is simply a separate pipeline that receives events. The bus evaluates each event against an associated set of rules, where a rule might say “match any event logging an API call with the s3:CreateBucket operation”. If the event matches a rule, the bus forwards the event data to targets.
A default event bus is automatically enabled in each region, and AWS services send default events to the bus at no extra cost. Rules and delivery are also free. Even with additional functionality enabled, EventBridge is still cheap; it costs $1 USD for every million custom events published to your bus or sent to another bus. You can find more information on EventBridge pricing here.
The diagram below highlights the process:
An AWS service, an AWS partner, or an event bus in another account or region sends an event to a bus.
The bus compares the event against sets of rules.
If the event matches a rule, the event data is forwarded to targets such as another AWS service or an API endpoint.
Many of EventBridge’s core features focus on building event-driven applications from a development and operational perspective; however, there are some core security features that are also worth considering:
Availability – the underlying infrastructure for EventBridge buses is handled by AWS. By default, it’s scalable, highly available, and fault-tolerant, meaning monitoring tools can rely on it.
Event archive – the event archive stores event data for replay at a later date. This can be useful when debugging issues and auditing.
Event forwarding – the option to forward events to other buses allows for centralized monitoring, while the ability to stream data through to other AWS services like Lambda or SNS enables automated responses to operational changes in your AWS environment.
Compliance – EventBridge adheres to the GDPR, ISO, and DoD standards, along with many others, so can be integrated into your systems while remaining compliant.
EventBridge enables monitoring of API calls and operational changes to your AWS estate. Some of the core benefits include:
Monitoring – it’s important to maintain insight into changes in your resources, identify failures, and detect malicious activity. By streaming data on operational changes in your AWS estate, EventBridge boosts monitoring capabilities.
Centralization – further to the above, EventBridge offers centralization of monitoring across regions and accounts, with the option to forward events to a central bus. HTTP endpoint support means events can also be forwarded to external SIEM tools for alerting.
Privacy and encryption – EventBridge supports VPC endpoints, and data is encrypted in transit with TLS 1.2, meaning that sensitive event data can be forwarded securely across AWS.
Auditing – event buses can be monitored by CloudWatch metrics, which can report on how often an event matches a rule. This enables auditing across longer time frames to identify patterns of behavior.
Incident response – real-time streaming of events to other AWS services can expedite the incident response process. For example, events forwarded to SNS could notify an operator of unexpected behavior, or a Lambda function could be triggered to automatically remediate an issue.
