Aws event bus

Aws event bus DEFAULT

First event bus and targets

In this module, you will create a custom EventBridge event bus, Orders, and an EventBridge rule, OrderDevRule, which matches all events sent to the Orders event bus and sends the events to a CloudWatch Logs log group, /aws/events/orders. See the diagram below:

Simple Event Bus

The technique of logging all events to CloudWatch Logs is useful when implementing EventBridge rules.


Step 1: Create a custom event bus

  1. Open the AWS Management Console for EventBridge in a new tab or window, so you can keep this step-by-step guide open.

  2. On the EventBridge homepage, open the left hand navigation.

    EventBridge Console

  3. Select Event buses from the left-hand menu.

  4. Click Create event bus.

    Create Bus

  5. Name the event bus .

  6. Leave the Permissions blank.

    Create Bus

  7. Click Create.

Step 2: Set up Amazon CloudWatch target (for development work)

A simple way to test, and get rapid feedback for, the rules you create for your event bus is to use Amazon CloudWatch as a target. We will create a rule for the Orders bus that will act as a “catch-all” for every event passed to the bus, irrespective of source.

  1. From the left-hand menu, select Rules.

  2. From the Event bus dropdown, select the Orders event bus.

  3. Click Create ruleNew rule

  4. On the Create rule page

    • add as the Name of the rule
    • add for Description
  5. Under Define pattern

    • Choose Event pattern
    • Under Event matching pattern, select Pre-defined pattern by service and the All Events from the Service provider dropdown.

    Take this opportunity to familiarize yourself with some the options available for AWS services, there are many examples of pre-defined patterns that are used for service events.

    You’ll be creating your own custom event patterns in the next section.

    Create Bus

  6. Ensure that you have selected Orders from the Select event bus panel

    Select event bus panel

  7. Select your rule target:

    • From the Target dropdown, select CloudWatch log group
    • Name your log group /aws/events/

    CloudWatch log group

  8. Leave the Tags blank.

    Create Bus

  9. Click Create.

Step 3: Test your dev rule

  1. Open the Event Generator for EventBridge in a new tab or window, so you can keep this step-by-step guide open.

  2. Make sure that the Event Generator is populated with the following (if you clicked the link above then you should see this pre-populated):

    • Event Bus selected to
    • Source should be
    • In the Detail Type add
    • JSON payload for the Detail Template should be:
  3. Click Publish.

    CloudWatch log group

  4. Open the AWS Management Console for CloudWatch in a new tab or window, so you can keep this step-by-step guide open.

  5. Choose Log groups in the left navigation and select the /aws/events/orders log group.

    CloudWatch log group entry

  6. Select the log stream from the list of Log streams.

    CloudWatch log group streams

  7. Expand the log event from the list of Log events and verify the log event send from Event Generator.

    CloudWatch log group entry

Step 4: Review event structure

Take note of the event structure and data! A sample event is provided below for your reference. The event is comprised of envelope attributes (version, id, source, detail-type, etc) and custom data in the detail attribute. It is very important to match the nested event attribute structure when writing EventBridge Rules.

In the following sections, you will use event data to implement EventBridge custom rules to route events. Due to the OrdersDevRule that you created in this section, all events to the Orders event bus will be sent to CloudWatch Logs, which you can use to view sample data in order to implement and troubleshoot rules matching logic.

CONGRATULATIONS! Your have configured your first target, let’s configure some more targets for our Order event bus. In the next section, Working with EventBridge Rules, you will look more closely at how to use the event pattern matching and integration with other services.

Sours: https://event-driven-architecture.workshop.aws/2-event-bridge/1-simple-bus/sb.html

Event-Driven with EventBridge

Event Bridge

Amazon EventBridge is a serverless event bus service that makes it easy to connect your applications with data from a variety of sources. EventBridge delivers a stream of real-time data from your own applications, Software-as-a-Service (SaaS) applications, and AWS services and routes that data to targets such as AWS Lambda. You can set up routing rules to determine where to send your data to build application architectures that react in real time to all of your data sources.

EventBridge simplifies the process of building event-driven architectures. With EventBridge, your event targets don’t need to be aware of event sources because you can filter and publish directly to EventBridge. There is no set up required. Event-driven architectures are loosely coupled and distributed, which improves developer agility as well as application resiliency.

Concepts

  • Events - An event indicates a change in an environment. This can be an AWS environment, an SaaS partner service or application, or one of your own custom applications or services.

  • Rules - A rule matches incoming events and routes them to targets for processing. A single rule can route to multiple targets, all of which are processed in parallel. Rules aren’t processed in a particular order. This enables different parts of an organization to look for and process the events that are of interest to them. A rule can customize the JSON sent to the target, by passing only certain parts or by overwriting it with a constant.

  • Targets - A target processes events. Targets can include Amazon EC2 instances, Lambda functions, Kinesis streams, Amazon ECS tasks, Step Functions state machines, Amazon SNS topics, Amazon SQS queues, and built-in targets. A target receives events in JSON format.

  • Event buses - An event bus receives events. When you create a rule, you associate it with a specific event bus, and the rule is matched only to events received by that event bus. Your account has one default event bus, which receives events from AWS services. You can create custom event buses to receive events from your custom applications. You can also create partner event buses to receive events from SaaS partner applications.

In this module, you will use EventBridge to learn how to create an event bus, route events to targets using rules, and use scheduling expressions to create recurring events.

Sours: https://event-driven-architecture.workshop.aws/2-event-bridge.html
  1. H1b rejection rate 2019
  2. Osrs combat level
  3. Diocese of lansing seminarians
  4. 5ge vs 5g

Sending and Receiving Events Between AWS Accounts

Note

Amazon EventBridge is the preferred way to manage your events. CloudWatch Events and EventBridge are the same underlying service and API, but EventBridge provides more features. Changes you make in either CloudWatch or EventBridge will appear in each console. For more information, see Amazon EventBridge.

You can set up your AWS account to send events to other AWS accounts, or to receive events from other accounts. This can be useful if the accounts belong to the same organization, or belong to organizations that are partners or have a similar relationship.

If you set up your account to send or receive events, you specify which individual AWS accounts can send events to or receive events from yours. If you use the AWS Organizations feature, you can specify an organization and grant access to all accounts in that organization. For more information, see What is AWS Organizations in the AWS Organizations User Guide.

The overall process is as follows:

  • On the receiver account, edit the permissions on the default event bus to allow specified AWS accounts, an organization, or all AWS accounts to send events to the receiver account.

  • On the sender account, set up one or more rules that have the receiver account's default event bus as the target.

    If the sender account has permissions to send events because it is part of an AWS organization that has permissions, the sender account also must have an IAM role with policies that enable it to send events to the receiver account. If you use the AWS Management Console to create the rule that targets the receiver account, this is done automatically. If you use the AWS CLI, you must create the role manually.

  • On the receiver account, set up one or more rules that match events that come from the sender account.

The AWS Region where the receiver account adds permissions to the default event bus must be the same region where the sender account creates the rule to send events to the receiver account.

Events sent from one account to another are charged to the sending account as custom events. The receiving account is not charged. For more information, see Amazon CloudWatch Pricing.

If a receiver account sets up a rule that sends events received from a sender account on to a third account, these events are not sent to the third account.

Enabling Your AWS Account to Receive Events from Other AWS Accounts

To receive events from other accounts or organizations, you must first edit the permissions on your account's default event bus. The default event bus accepts events from AWS services, other authorized AWS accounts, and calls.

When you edit the permissions on your default event bus to grant permission to other AWS accounts, you can specify accounts by account ID or organization ID. Or you can choose to receive events from all AWS accounts.

Warning

If you choose to receive events from all AWS accounts, be careful to create rules that match only the events to receive from others. To create more secure rules, make sure that the event pattern for each rule contains an field with the account IDs of one or more accounts from which to receive events. Rules that have an event pattern containing an Account field do not match events sent from accounts that are not listed in the field. For more information, see Event Patterns in CloudWatch Events.

To enable your account to receive events from other AWS accounts using the console

  1. Open the CloudWatch console at https://console.aws.amazon.com/cloudwatch/.

  2. In the navigation pane, choose Event Buses, Add Permission.

  3. Choose AWS Account or Organization.

    If you choose AWS Account, enter the 12-digit AWS account ID of the account from which to receive events. To receive events from all other AWS accounts, choose Everybody(*).

    If you choose Organization, choose My organization to grant permissions to all accounts in the organization of which the current account is a member. Or choose Another organization and enter the organization ID of that organization. You must include the prefix when you type the organization ID.

  4. Choose Add.

  5. You can repeat these steps to add other accounts or organizations.

To enable your account to receive events from other AWS accounts using the AWS CLI

  1. To enable one specific AWS account to send events, run the following command:

    To enable an AWS organization to send events, run the following command:

    To enable all other AWS accounts to send events, run the following command:

    You can run multiple times to grant permissions to both individual AWS accounts and organizations, but you cannot specify both an individual account and an organization in a single command.

  2. After setting permissions for your default event bus, you can optionally use the command to check the permissions:

Sending Events to Another AWS Account

To send events to another account, configure a CloudWatch Events rule that has the default event bus of another AWS account as the target. The default event bus of that receiving account must also be configured to receive events from your account.

To send events from your account to another AWS account using the console

  1. Open the CloudWatch console at https://console.aws.amazon.com/cloudwatch/.

  2. In the navigation pane, choose Events, Create Rule.

  3. For Event Source, choose Event Pattern and select the service name and event types to send to the other account.

  4. Choose Add Target.

  5. For Target, choose Event bus in another AWS account. For Account ID, enter the 12-digit account ID of the AWS account to which to send events.

  6. An IAM role is needed when this sender account has permissions to send events because the receiver account granted permissions to an entire organization.

    • To create an IAM role automatically, choose Create a new role for this specific resource.

    • Otherwise, choose Use existing role. Choose a role that already has sufficient permissions to invoke the build. CloudWatch Events does not grant additional permissions to the role that you select.

  7. At the bottom of the page, choose Configure Details.

  8. Type a name and description for the rule, and choose Create Rule .

To send events to another AWS account using the AWS CLI

  1. If the sender account has permissions to send events because it is part of an AWS organization to which the receiver account has granted permissions, the sender account also must have a role with policies that enable it to send events to the receiver account. This step explains how to create that role.

    If the sender account was given permission to send events by way of its AWS account ID, and not through an organization, this step is optional. You can skip to step 2.

    1. If the sender account was granted permissions through an organization, create the IAM role needed. First, create a file named , with the following content:

    2. To create the role, enter the following command:

    3. Create a file named with the following content:

    4. Enter the following command to attach this policy to the role:

  2. Use the command to create a rule that matches the event types to send to the other account.

  3. Add the other account's default event bus as the target of the rule.

    If the sender account was given permissions to send events by its account ID, specifying a role is not necessary. Run the following command:

    If the sender account was given permissions to send events by its organization, specify a role, as in the following example:

Writing Rules that Match Events from Another AWS Account

If your account is set up to receive events from other AWS accounts, you can write rules that match those events. Set the event pattern of the rule to match the events you are receiving from the other account.

Unless you specify in the event pattern of a rule, any of your account's rules, both new and existing, that match events you receive from other accounts trigger based on those events. If you are receiving events from another account, and you want a rule to trigger only on that event pattern when it is generated from your own account, you must add and specify your own account ID to the event pattern of the rule.

If you set up your AWS account to accept events from all AWS accounts, we strongly recommend that you add to every CloudWatch Events rule in your account. This prevents rules in your account from triggering on events from unknown AWS accounts. When you specify the field in the rule, you can specify the account IDs of more than one AWS account in the field.

To have a rule trigger on a matching event from any AWS account that you have granted permissions to, do not specify * in the field of the rule. Doing so would not match any events, because * never appears in the field of an event. Instead, just omit the field from the rule.

To write a rule matching events from another account using the console

  1. Open the CloudWatch console at https://console.aws.amazon.com/cloudwatch/.

  2. In the navigation pane, choose Events, Create Rule.

  3. For Event Source, choose Event Pattern, and select the service name and event types that the rule should match.

  4. Near Event Pattern Preview, choose Edit.

  5. In the edit window, add an line specifying which AWS accounts sending this event should be matched by the rule. For example, the edit window originally shows the following:

    Add the following to make the rule match EBS volume notifications that are sent by the AWS accounts 123456789012 and 111122223333:

  6. After editing the event pattern, choose Save.

  7. Finish creating the rule as usual, setting one or more targets in your account.

To write a rule matching events from another AWS account using the AWS CLI

  • Use the command. In the field in the rule's event pattern, specify the other AWS accounts for the rule to match. The following example rule matches Amazon EC2 instance state changes in the AWS accounts 123456789012 and 111122223333:

Migrate a Sender-Receiver Relationship to Use AWS Organizations

If you have a sender account that had permissions granted directly to its account ID, and you now want to revoke those permissions and give the sending account access by granting permissions to an organization, you must take some additional steps. These steps ensure that the events from the sender account can still get to the receiver account. This is because accounts that are given permission to send events via an organization must also use an IAM role to do so.

To add the permissions necessary to migrate a sender-receiver relationship

  1. In the sender account, create an IAM role with policies that enable it to send events to the receiver account.

    1. Create a file named , with the following content:

    2. To create the IAM role, enter the following command:

    3. Create a file named with the following content:

    4. Enter the following command to attach this policy to the role:

  2. Edit each existing rule in the sender account that has the receiver account default event bus as a target. Edit the rule by adding the role that you created in step 1 to the target information. Use the following command:

  3. In the receiver account, run the following command to grant permissions for the accounts in the organization to send events to the receiver account:

    Optionally, you can also revoke the permissions originally granted directly to the sender account:

Sours: https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/CloudWatchEvents-CrossAccountEventDelivery.html

Event Bus Exposed

Trend Micro Cloud One™ – Conformity is a continuous assurance tool that provides peace of mind for your cloud infrastructure, delivering over 750 automated best practice checks.

Using an overly permissive access policy for your CloudWatch default event bus can allow unauthorized AWS users to send their CloudWatch events.


01 Sign in to the AWS Management Console.

02 Navigate to AWS CloudWatch dashboard at https://console.aws.amazon.com/cloudwatch/.

03 In the left navigation panel, under Events section, select Event Buses.

04 On the Event Buses page, select Permissions tab and check the AWS entities authorized to send CloudWatch events to the default event bus provisioned within the current region, listed in the Principal column. If the Principal is set to Everybody(*), the AWS CloudWatch event bus available in the current region is exposed to everyone, therefore any AWS user can send their CloudWatch events to your default event bus.

05 Change the AWS region from the navigation bar and repeat step no. 4 to determine if the CloudWatch event buses provisioned in other AWS regions are exposed.

01 Run describe-event-bus command (OSX/Linux/UNIX) to describe the access policy that enables AWS entities to send CloudWatch events to the default event bus created within the selected AWS region:

aws events describe-event-bus --region us-east-1 --query 'Policy'

02 The command output should return the requested policy document:

{ "Version": "2012-10-17", "Statement": [ { "Sid": "aaaabbbb-aaaa-bbbb-cccc-1234567890123456789012345", "Effect": "Allow", "Principal": , "Action": "events:PutEvents", "Resource": "arn:aws:events:us-east-1:123456789012:event-bus/default" } ] }

Within the policy document returned as output, check the Principalelement value (highlighted). If the Principalelement has the following value: "*", as shown in the output example above, the Amazon CloudWatch default event bus available in the selected region is exposed to everyone (*).

03 Change the AWS region by updating the --region command parameter value and repeat step no. 1 and 2 to determine if the CloudWatch default event buses created in other AWS regions are exposed.

01 Sign in to the AWS Management Console.

02 Navigate to AWS CloudWatch dashboard at https://console.aws.amazon.com/cloudwatch/.

03 In the left navigation panel, under Events section, select Event Buses.

04 On the Event Buses page, select Permissions tab, choose the entry with the Principal attribute set to Everybody(*) and click Remove to delete the selected access permission and block public access to the default event bus provisioned in the current AWS region.

05 Click Add permissions button to add a new permission that allows a specific (authorized) AWS account to send its CloudWatch event data to your event bus.

06 Inside Add Permission dialog box, enter the 12-digit AWS account ID to receive events from.

07 Click Add to confirm the changes and create the new permission for the CloudWatch default event bus available in the current AWS region.

08 Change the AWS region from the navigation bar and repeat steps no. 4 – 7 to update the access permissions configured for CloudWatch default event buses available in other regions.

01 Run remove-permission command (OSX/Linux/UNIX) using the access policy statement ID as identifier (see Audit section part II to identify the right statement ID number) to block public access to the default event bus (the command does not produce an output):

aws events remove-permission --region us-east-1 --statement-id aaaabbbb-aaaa-bbbb-cccc-1234567890123456789012345

02 Run put-permission command (OSX/Linux/UNIX) to create a new permission that permits a specified (trusted) AWS account to put events to your account's default event bus, available in the selected region. Replace the --principal parameter value with the 12-digit ID of the AWS account that is authorized to send event data to your account (the command does not return an output):

aws events put-permission --region us-east-1 --action events:PutEvents --principal 123456789012 --statement-id aaaabbbb-aaaa-bbbb-cccc-1234567890123456789012345

03 Change the AWS region by updating the --region command parameter value and repeat step no. 1 and 2 to update the permissions defined for CloudWatch default event buses provisioned in other regions.

01 Sign in to the AWS Management Console.

02 Navigate to AWS CloudWatch dashboard at https://console.aws.amazon.com/cloudwatch/.

03 In the left navigation panel, under Events section, select Event Buses.

04 On the Event Buses page, select Permissions tab, choose the permission with the Principal attribute set to Everybody(*) and click Remove to delete the permission and block the public access to the default event bus available within the current AWS region.

05 Change the AWS region from the navigation bar and repeat step no. 4 to revoke public access to CloudWatch event buses available in other regions.

01 Run remove-permission command (OSX/Linux/UNIX) using the access policy statement ID as identifier (see Audit section part II to identify the right ID number) to revoke the permissions set for the exposed event bus (the command does not produce an output):

aws events remove-permission --region us-east-1 --statement-id aaaabbbb-aaaa-bbbb-cccc-1234567890123456789012345

02 Change the AWS region by updating the --region command parameter value and repeat step no. 1 to block public access to CloudWatch event buses available in other AWS regions.

Publication date May 6, 2018

Unlock the Remediation Steps


Gain free unlimited access
to our full Knowledge Base


Over 750 rules & best practices
for and

Free 30-day Trial

Automatically audit your configurations with Conformity
and gain access to our cloud security platform.

Confirmity Cloud Platform

No thanks, back to article

You are auditing:

Event Bus Exposed

Risk level: High


Whether your cloud exploration is just starting to take shape, you’re mid-way through a migration or you’re already running complex workloads in the cloud, Conformity offers full visibility into your overall security and governance posture across various standards and frameworks.

Continuous security & compliance for cloud environments. Grow and scale your business with confidence

Sours: https://www.trendmicro.com/cloudoneconformity/knowledge-base/aws/CloudWatchEvents/event-bus-exposed.html

Event bus aws

Using Amazon EventBridge, you can now route events between different event buses in the same Region and same AWS account. Combined with the ability to route events cross-Region, this provides you with significant flexibility in routing events in your workloads. This blog post explains how to use event routing and walks through ways you can use this feature.

EventBridge enables developers to route events between AWS services, integrated software as a service (SaaS) applications, and your own applications. Previously, you could only consume events from AWS services from the default bus, and events from SaaS applications appeared only in partner event buses. With bus-to-bus routing, you can now forward these events to other buses using the same model for routing events to existing targets.

Putting events onto another bus is charged at the same rate as other put events operations – see the EventBridge pricing page to learn more.

How bus-to-bus routing works

Event buses route events using rules, which match events with patterns, and route to targets. To route an event from an event bus in any Region, you must create a rule and define which event bus to route to. You can have up to 100 event buses per AWS account. This is a soft limit which you can raise by submitting a support ticket from the AWS Service Quotas console.

Using same-Region buses as targets works the same way as using cross-account or cross-Region buses as targets. To add a bus in the same Region as a target to a rule:

  1. Navigate to the EventBridge console. Choose Create rule.
  2. Provide a name and pattern and choose the source event bus.
  3. In the Select targets panel:
    Select targets dialog
    – For Target, select Event bus in the same account and Region.
    – For Event Bus, enter the name of the target event bus.
    – Keep the selected option Create a new role for this specific resource. This creates the necessary IAM permissions to allow the rule to put events on the target bus.
  4. Choose Save.

Events that match the rule are then delivered to the event bus. The delivered event is identical to the original event and does not contain any additional metadata or attributes. You can specify multiple target event buses in the same rule by using multiple targets.

You can only forward an event between same-Region buses once. If you have routed an event from a source bus to a target bus, the target bus cannot then forward the event to another bus.

If you use the CLI to configure the target, you must manually create the IAM role that provides permission for the rule to route to the target bus. This role should include a policy that allows an event:PutEvents action for the target bus:

You must also enable events.amazonaws.com as a trusted entity on the IAM role:

The target bus also requires a rule to process the event, otherwise the event is discarded. You can create a rule on the target bus to route the event to AWS Lambda functions, Amazon SQS queues, API destinations, or any other available target.

Using bus-to-bus routing to simplify event flow and access

Previously, a single workload may need rules on multiple buses for events related to one application. This is because events from AWS services are routed to the default bus while events from SaaS partners have their own dedicated buses. With this feature, you can now route events from multiple buses to a single custom bus.

This can be useful for centralizing events related to a single project, application, or team within your organization. For example, in a banking application where ATM transactions originate on the default bus, there could be multiple departments interested in the events.

Bus-to-bus routing example architecture

These departments can now subscribe to their own dedicated buses for messages, and do not need access to the source buses:

  • The Marketing department receives ATM events on a Marketing bus. The rule forwarding the event filters out personally identifiable information (PII) from the event, so the marketing team can use the data.
  • The Compliance department receives the same events but with no fields redacted. This Compliance bus also receives events from a Splunk partner event bus which captures log events from the ATM machines.
  • The Operations department receives only ATM events where a machine has operational issues, and transactional events are excluded. The Operations bus also receives Zendesk ticket updates related to ATM maintenance from a partner event bus.

Additionally, this can help if you need to filter or route AWS-related events to an application, but you do not want to provide access to all AWS events. In the case, create a rule on the default event bus to match the allowed events and forward to a custom bus used by the consuming application. You can then use IAM to deny access to the default bus and enable access to the custom bus.

Creating a bus-to-bus routing rule in AWS CloudFormation

Using AWS CloudFormation or the AWS Serverless Application Model (AWS SAM), you can deploy EventBridge buses, rules, and policies using infrastructure as code (IaC). To create a rule on an event bus that routes events to another bus in the same account, first create the AWS::Events::Rule resource:

Next, create an AWS::IAM::Role resource that allows EventBridge to put events on the target bus in the destination Region:

Conclusion

With bus-to-bus event routing in EventBridge, you can now route events from any type of event bus to the default and custom buses. This post explains how to configure bus-to-bus event routing in the console and CLI and discusses potential use-cases.

For more serverless learning resources, visit Serverless Land.

Sours: https://awsfeed.com/whats-new/compute/using-bus-to-bus-event-routing-with-amazon-eventbridge
AWS EventBridge Vs EventBus

Amazon EventBridge

What is AWS EventBridge?

Part of the AWS Serverless ecosystem, Amazon EventBridge is a serverless event bus that was built on top of the existing AWS CloudWatch Events API. 

AWS CloudWatch Events enables developers to integrate many of the AWS services through events. For example, if there is a change in the state of an EC2 instance, a CloudWatch Event can trigger an event to AWS Lambda to take an action. EventBridge extends this functionality beyond the AWS ecosystem, letting you brings together your own (legacy) applications, SaaS (Software-as-a-Service), and AWS Services. It can stream real-time data from various event sources like PagerDuty, Symantec, and routes to various targets (AWS services) like SQS, Lambda, and others. 

At launch, EventBridge arrived offering support for 10 SaaS application partners, more than 90 AWS services as event sources, and 17 AWS services as targets.

How is EventBridge Different from Other AWS Services?

Let’s take a look at the other options available in AWS for Event routing and see how they compare with EventBridge. There are four main AWS-native options for event routing:

  • CloudWatch Events
  • SNS
  • EventBridge
  • Kinesis

CloudWatch Events vs EventBridge

CloudWatch Events can support only AWS services as event sources. It uses only the default event bus, which accepts events from AWS services, PutEvents API calls, and other authorized accounts. You can manage permissions on the default event bus to authorize other accounts.

EventBridge provides an option to create custom event buses and SaaS event bus on top of the default bus. The custom event bus is used to handle custom events raised by using PutEvents APIs. SaaS event bus is used to channel through events triggered by SaaS platforms. 

For default bus, EventBridge leverages the CloudWatch Events API, so CloudWatch Events users can access their existing default bus, rules, and events in the new EventBridge console, as well as in the CloudWatch Events console.

SNS vs EventBridge

SNS is a well-known event-sourcing service. It really shines when the throughput is very high, up into the millions of TPS. EventBridge, meanwhile, supports 400 requests per second only. 

However, the number of targets supported by SNSis limited compared to EventBridge.

For example, if an event needs to trigger Step Functions, it cannot do it directly as it is not available as a target. It needs to call a Lambda function, and that can trigger the Step Functions. On the other hand, EventBridge supports 17 targets as of now. But, each Rule in EventBridge can configure a maximum of 5 targets.

SNS scales practically infinitely, but filtering is limited to attributes, not event content. SNS doesn’t give any guarantee as to the ordering of the messages.

Kinesis vs EventBridge

Kinesis can be used for event-routing as well as event-storing. This is an ideal solution for processing real-time data at large scales. It can fan-out to multiple consumers, however, there is a limit on the number of consumers that can connect to a single stream. Each individual consumer would carry some responsibility for filtering out of any messages that they weren’t potentially interested in. 

Kinesis also provides ordering guarantees. However, it doesn’t have an entirely usage-based pricing model. It doesn’t automatically scale to demand. 

On the other hand, EventBridge cannot buffer the events. It needs SQS or Kinesis integration for event storage. 

EventBridge Use Cases

Let’s take a couple of use cases and compare how they would be implemented using SNS and EventBridge.

  1. Say I want to build a system where if an EC2 instance is down, it should reboot and then trigger a Lambda function to store the incident to the DynamoDB table.

If I build it using SNS as an event-routing service, it would need to use SQS as well, as it cannot be subscribed by EC2 directly. Here is the design for this solution:

If we implement the same use case using EventBridge, the design will look like this:

With EventBridge the design is much simpler. We can implement our solution using fewer services.

  1. Let’s take another use case where an employee resigns from an organization and his record is updated in the CRM tool. It needs to trigger different workflows for all approvals as part of an exit checklist.

If we implement this use case using SNS, the design will look something like this:

If we use EventBridge, the design will be much simpler. It doesn’t need polling, CloudWatch Scheduler, or Lambda functions. The design will look more like this:

AWS EventBridge Building Blocks

Before we go deep into how EventBridge works, let us first understand the components this service contains:

Events – An event is a real-time change in a system, data, or environment. This change can be either in your application or in an AWS service or a SaaS partner service.

Event sources – An event source is used to ingest events from a SaaS partner– or your own app — to an AWS customer account.

Event buses – To receive an event from event sources, you need to configure an event bus in an AWS account. These event buses can be of several types:

  • Default event bus – Created by default and receives events from any AWS service.
  • Custom event bus – Receives events from custom applications you create and must be created manually.
  • Partner event bus – Receives events from SaaS partner applications and must be created manually.

Rules – A rule is created and associated with an event bus from which it will scan the events to be matched. When incoming events match with the rule, it routes them to targets for processing. You can enable parallel processing also by routing to multiple targets. A rule can also parse the JSON and filter/customize it to send only certain parts of JSON or overwrite the text.

Targets – A target processes events. It supports JSON format for events. Targets can include several AWS services such as Amazon EC2 instances, Lambda functions, Kinesis streams, Amazon ECS tasks, Step Functions, Amazon SNS topics, and Amazon SQS.

How EventBridge Works

In layman’s terms, Amazon EventBridge is a serverless event bus that supports the publish/subscribe model. SaaS applications publish events to this event bus and it fans out the events to one or multiple AWS target services.

The first step is to create a rule. A rule has to be created in the same region where the target is. A rule requires an event pattern. It uses the pattern to match the incoming events. Below is an example that processes all EC2 instance-termination events:

 

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

Each rule has to be associated with an event bus. You can select one of the event buses based on your requirements discussed above. Now, select a target to which the events will be routed once matched with the event pattern by the rule.

The next step is to create an event bus. every AWS account creates one default event bus, which receives events emitted by AWS services. You can also configure your custom applications to send events to the default event bus. If you need to integrate with a SaaS partner application, you can create a partner event bus.

Once the basic flow is set up, you can enable additional features such as content-based event filtering, transforming target inputs, schema registry, and so on.

Content-based event filtering

Content-based event filtering is used to write complex rules in which allow events to be processed when filtering conditions are met.

For instance, you might want to pass the event only if it is missing a specific field in it or if events are coming from a specific IP address.

It supports the following types of pattern matching:

  • Prefix Matching
  • Anything-but Matching
  • Numeric Matching
  • IP Address Matching
  • Exists Matching
  • Complex Example with Multiple Matching

Transforming Target Inputs

In specific use cases, you might want to customize the text of event fields before passing them to a target so that these fields provide more meaningful information to process them further.

Let’s assume this is the event being processed:

{  "version": "0",  "id": "6bf42112-1422-2cf3-a730-92db853d1542",  "detail-type": "EC2 Instance State-change Notification",  "source": "aws.ec2",  "account": "91204489383",  "time": "2021-02-05T11:13:14Z",  "region": "ap-southeast-1",  "resources": [    "arn:aws:ec2:ap-southeast-1:91204489383:instance/i-zysa0111"  ],  "detail": {    "instance": "i-999999999",    "state": "RUNNING"  }}

When you create a rule, you can select the Input Transformer option under Configure input. It provides two text boxes: one for the Input Path and one for the Input Template.

The Input Path can be defined with the variables instance and state:

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

The Input Template is used to transform the information to pass to your target. You can create a template that passes either a string or JSON to the target. For example:

Template

"instance <instance> is in <state>"

Output

"instance i-999999999 is in RUNNING"

EventBridge Schema Registry

So far we have seen that events get published and consumed by targets. But now, from a developer perspective, if you need to read these events at the target end and process them, you need to manually write code matching up with the event structure being received.

To solve this problem, AWS launched Schema Registry to centralize and share the event structure which can be downloaded as objects with popular programming languages such as Java and Python. You can generate events from these schemas or generate code binding for these schemas.

Additional Points to Remember

Here are additional points to consider as you implement EventBridge for your serverless applications:

  1. Pricing for EventBridge is the same as for CloudWatch Events, at $1 per 1 million events published to the event bus.
  2. EventBridge will ensure successful delivery to targets. If failure happens, it will retry for 24 hours only before marking it as failed. In the case of Lambda, what successful delivery means from the EventBridge perspective is that it was able to asynchronously invoke your function. As long as EventBridge is getting a 200 response, from its perspective it is a successful transaction. If there is any failure in Lambda execution, it has to reply on Lambda retry policy. EventBridge cannot apply it’s retry policies.
  3. EventBridge makes connections seamless for an AWS service from an AWS account to another AWS service in a different account. It has a target option as “event bus from another account”.
  4. EventBridge needs SQS to bring resiliency but Kinesis has that feature built-in.

A Brief History: What Came Before EventBridge?

EventBridge has been introduced mainly to address the problems of SaaS platform integration with AWS services. 

This is critical, because in the current cloud world, SaaS platforms like CRMs, identity providers, and so on, have become key partners. They generate a large amount of data and need to pass it to AWS platforms for business processing. Before EventBridge, there were two main solutions for sending event data to AWS:

Polling

With this solution, we generally set up a Cron job or CloudWatch Scheduler to go out and call the SaaS APIs. It will check if there has been any change in data and then pull the data. Polling frequency can be minutes to hours depending on the use case and the capacity of the particular SaaS platform to bear the load. A typical flow might look like this:

This solution seems simple but it raises two major issues:

  • Data freshness issue – The scheduler will be calling the API at set intervals, maybe every few minutes or perhaps only once per hour. So, it will never get real-time data. There will always be a gap, which might not be suitable for some business scenarios. 
  • Costing and Performance issues – To alleviate the data freshness issue we could choose to reduce the interval of polling, but that will increase costs as call frequency will be increased. Additionally, more resources will be consumed on the SaaS platform side. This may cause throttling and slow down performance.

So, the overall recommendation is to avoid the polling mechanism if you can.

SaaS Webhooks

This technique eliminates the data freshness issue. Here, we find out an HTTP endpoint of the AWS-hosted application which the SaaS platform can call to send event data. The SaaS platform will set up the webhooks and send real-time data when records change.

Here’s an example of a typical use case:

In this flow, we still need to manage the public endpoint of the application for handling security/DDoS attacks. It will also require Authentication handling. In AWS, this is usually done through API Gateway or WAF/ALB. We would also need to write the code to handle the events.

So, in light of the shortcomings inherent in the existing techniques, AWS introduced EventBridge, which enables SaaS platforms to create a Native Event source on the AWS side and establish a secure connection just by sharing Account ID and region with platforms. 

It not only solves the issue of real-time data processing but also takes care of event ingestion and delivery, security, authorization, and error handling for you.

Image source: AWS

Summary

The introduction of EventBridge helps to solve some of the big issues around SaaS platform integration with AWS services. Also, for existing AWS services, integration has become much simpler and smoother. When comparing it to similar AWS services, it’s clear that while CloudWatch Events, SNS, and Kinesis each offer certain advantages, EventBridge has the potential to be a key ingredient in a modern, highly distributed microservices architecture.

How are you using EventBridge in your serverless environment? Continue the conversation on Twitter. We’d love to hear your thoughts!

 

Sours: https://lumigo.io/aws-serverless-ecosystem/amazon-eventbridge/

You will also like:

And when I am not at home, Lech can now visit her on the sly. Or a neighbor. Damn.



37567 37568 37569 37570 37571