Amazon EventBridge FAQs

Q:What is Amazon EventBridge?
Amazon EventBridge is a service that provides real-time access to changes in data in Amazon Web Services services, your own applications and Software-as-a-Service (SaaS) applications without writing code. To get started, you can choose an event source on the Amazon EventBridge console, and select a target from a number of Amazon Web Services services including Amazon Lambda, Amazon SNS, and Amazon Kinesis Data Firehose. Amazon EventBridge will automatically deliver the events in near real-time.

Q: How can I get started using Amazon EventBridge?
Log in to your Amazon Web Services account, navigate to the Amazon EventBridge console, and choose an event source from a list of partner SaaS applications and Amazon Web Services services. If you are using a partner application ensure that you have configured your SaaS account to emit events, and accept it in the offered event sources section of the Amazon EventBridge console. Amazon EventBridge will automatically create an event bus for you to which events will be routed. Alternatively, you can use the Amazon SDK to instrument your application to start emitting events to your event bus. Optionally configure a filtering rule and attach a target for your events, for example, this can be a Lambda function. Amazon EventBridge will be automatically ingest, filter and send the events to the configured target in a secure and highly available way.

Q: Can I publish my own events to Amazon EventBridge?
Yes. Customers can generate custom application-level events and publish them to Amazon EventBridge via the service’s APIs. Customers can also set up scheduled events that are generated on a periodic basis, and can process these events in any of the Amazon EventBridge supported targets.

Q: What is the format of an event?
Events use a specific JSON structure. Every event has the same top-level envelope fields, such as the source of the event, timestamp, and region. This is followed by a detail field which is the body of the event. For example, when an Amazon EC2 auto scaling group creates a new Amazon EC2 instance, it emits an event with source: “aws.autoscaling” and detail: "EC2 instance created successfully".

Q: How do I filter which events are delivered to a target?
You can filter events with rules. A rule matches incoming events for a given event bus and routes them to targets for processing. A single rule can route to multiple targets, all of which are processed in parallel. Rules allow different application components to look for and process the events that are of interest to them. A rule can customize an event before it is sent to the target, by passing only certain parts or by overwriting it with a constant. For the example given in the previous question, you can create an event rule that matches on source: “aws.autoscaling” and detail: "EC2 instance created successfully" to be notified any time an auto scaling group successfully creates an Amazon EC2 instance.

Q: How do I secure access to Amazon EventBridge?
Amazon EventBridge integrates with Amazon Identity and Access Management (IAM) so that you can specify which actions a user in your Amazon Web Services Account can perform. For example, you could create an IAM policy that gives only certain users in your organization permission to create event buses or attach event targets.

Q: How does Amazon EventBridge relate to CloudWatch Events?
Amazon EventBridge builds upon and extends CloudWatch Events. It uses the same service API and endpoint, and the same underlying service infrastructure. For existing CloudWatch Events customers, nothing changes - you can continue to use the same API, CloudFormation templates, and console. We heard from customers that CloudWatch Events is the ideal service for building event-driven architectures, and so we built new features that would enable our customers to connect data from their own apps and third-party SaaS apps. Rather than keeping this beneath the CloudWatch service, we have released this functionality with a new name, Amazon EventBridge, to signify the expansion beyond the monitoring use case that CloudWatch Events was developed for.

Q: I currently use Amazon CloudWatch Events and I WANT to try the features of Amazon EventBridge. Do I need to move my Amazon Cloudwatch Events rules and permissions to Amazon EventBridge?
No. Existing Amazon CloudWatch Events users can access their existing default bus, rules, and events in the new Amazon EventBridge console and API or in the Amazon CloudWatch Events console and API.

Q: I’m already using Amazon CloudWatch Events and I don’t need the features of Amazon EventBridge. What will change for me?
Nothing. Amazon EventBridge uses the same Amazon CloudWatch Events API so all of your existing CloudWatch Events API usage will remain the same.

Q: Are you going to deprecate Amazon CloudWatch Events one day?
No, we are not going to deprecate the API or the service itself. Amazon EventBridge is using the same API, and has added additional features. Over time, the Amazon CloudWatch Events name will be replaced with Amazon EventBridge.

Q: Which Amazon Web Services services are integrated as event sources for Amazon EventBridge?
There are over 90 Amazon Web Services services available as event sources for EventBridge, including Amazon Lambda, Amazon Kinesis, Amazon Fargate, and Amazon S3. For a full list of Amazon Web Services service integrations, see the EventBridge documentation.

Q: Which Amazon Web Services services are integrated as event targets for Amazon EventBridge?
There are over 15 Amazon Web Services services available as event targets for EventBridge including Amazon Lambda, Amazon SQS, Amazon SNS, and Amazon Kinesis Streams. For a full list of Amazon Web Services service integrations please see the EventBridge documentation.

Q: What is EventBridge API Destinations?

API Destinations helps developers send events back to any on-premises or SaaS applications with the ability to control throughput and authentication. You can configure rules with input transformations that will map the format of the event to the format of the receiving service, and EventBridge will take care of security and delivery.

When a rule is initiated, EventBridge will transform the event based on the conditions specified. It will then send it to the configured web service with authentication information that was provided when the rule was set up. Security is built in so that developers no longer need to write authentication components for the service that they want to use.

Q: What is a Connection for an API destination? How do I set up API destinations?

Each API destination uses a Connection that defines the authorization method and credentials to use to connect to the HTTP endpoint. When you configure the authorization settings and create a connection, it creates a secret on Amazon Secrets Manager to store the authorization information securely. You can also add further parameters to include the connection as appropriate for your application.

To set up an API destination, you will need to provide an API destination endpoint, which is an HTTP invocation endpoint target for events. You will need to create a Connection to authorize against this endpoint. You can also optionally define the invocation rate limit, which is the maximum number of invocations per second to send to the API destination endpoint. 

Q: What are the service limits?
See “Service Limits” page here.

Q: What is the latency I can expect between sending and receiving an event?

Typical latency is about half a second. Note that this can vary.

Q: Does Amazon EventBridge support resource tagging?
Yes, you can tag rules. You can’t tag event buses or event sources.

Q: What throughput can I expect from Amazon EventBridge?
Event bus throughput limits are given in the “Service Limits” page here. If you require higher throughput please request a service limit increase through the Amazon Web Services Support Center by choosing Create Case and then choosing Service Limit Increase.

Q: What is a schema?

A schema represents the structure of an event, and commonly includes information such as the title and format of each piece of data included in the event.

For example, a schema might include fields such as name and phone number, and the fact that the name is a text string, and the phone number is an integer. The schema can also include information on patterns, such as a requirement that the phone number be 10 digits in length. The schema of an event is important because it shows what information is contained in the event, and helps you write code based on that data.

Q: What is a schema registry?

A schema registry stores a searchable collection of schemas so any developer in your organization can more easily access schemas generated by the application. This is in contrast to looking through documentation or finding the schema’s author for this information. You can add a schema to the registry manually or automate this process by turning on the EventBridge schema discovery feature.

Q: What is the schema discovery feature?

Schema discovery automates the processes of finding schemas and adding them to your registry. When schema discovery is enabled for an EventBridge event bus, the schema of each event sent to the event bus is automatically added to the registry. If the schema of an event changes, schema discovery will automatically create a new version of the schema in the registry.

Once a schema is added to the registry, you can generate a code binding for the schema either in the EventBridge console or directly in your integrated development environment (IDE). This helps you represent the event as a strongly typed object in your code. You can then take advantage of IDE features such as validation and autocomplete.

Q: Can I discover schemas from events delivered across other accounts?

Yes, within Schema discovery you can discover events across accounts, so that you can have full visibility of the schema of events published to your event buses. 

Q: How much does the schema registry cost?

There is no cost to use the schema registry; however, there is a cost per ingested event when you turn on schema discovery. Schema discovery has a free tier of 5 M ingested events per month, and some applications may be able to operate within this free tier. There is a fee for additional usage outside of the free tier. For more info on pricing, see the EventBridge pricing page.

Q: How does the schema registry reduce the amount of code I need to write?

The Schema registry reduces the amount of code by enabling you to do the following:

• Identify schema automatically for any events sent to your EventBridge event bus, and store them in the registry, saving you from having to manage your event schema manually.
• Write applications that handle events on your bus, generate and download code bindings for schema to use strong-typed objects directly in your code.

Code bindings reduce the overhead for de-serialization, validation, and guesswork for your event handler.

Q: Why should I use the schema registry?

You should use schema registry to build event-driven applications faster. The schema registry eliminates the time spent coordinating between development teams by automatically finding the available events from any supported event source -- including Amazon Web Services services, third-party, and custom applications -- and detect their schema. It was built to allow developers to solely focus on their application code, instead of wasting valuable time searching for available events, their structure, and writing code to interpret and translate events. 

Q: Which IDEs does the schema registry support?

The schema registry is available through the Amazon Toolkit for JetBrains (IntelliJ IDEA, PyCharm, WebStorm, Rider) and Visual Studio Code, as well as in the EventBridge console and APIs. Learn more about using the EventBridge schema registry within your IDE.

Q: Can I use schema with the Amazon Serverless Application Model (SAM)?

Yes, the latest version of the Amazon SAM CLI includes an interactive mode that helps you create new serverless applications on EventBridge for any schema as an event type.

Choose the EventBridge Starter App template, and the schema of your event, and SAM will automatically generate an application with a Lambda function invoked by EventBridge, with handling code of the event. This means that you can treat an event trigger like a normal object in your code, and use features such as validation and autocomplete in your IDE.

The Amazon Toolkit for Jetbrains (Intellij IDEA, PyCharm, Webstorm, Rider) plugin and Amazon Toolkit for Visual Studio Code also provide functionality to generate serverless applications from this template with a schema as a trigger, directly from these IDEs.

Q: In which languages can I generate code from my schemas?

EventBridge offers code generation in Java (8+), Python (3.6+), and TypeScript (3.0+), and Go (1+).

Q: What is Amazon EventBridge Pipes?

EventBridge Pipes provides a simpler, consistent, and cost-effective way to create point-to-point integration between event producers and consumers. Creating a pipe is as simple as selecting a source and a target with the ability to customize batching, starting position, concurrency, and more. An optional filtering step allows only specific source events to flow into the pipe and an optional enrichment step using Amazon Lambda, Amazon Step Functions, API Destinations, or Amazon API Gateway can be used to enrich or transform events before they reach the target. By removing the need to write manage, and scale undifferentiated integration code, EventBridge Pipes allows you to spend your time building applications rather than connecting them.

Q: How do I get started with EventBridge Pipes?

You can get started by visiting the EventBridge console, select the Pipes tab, and choose Create Pipe. From there, you can choose from a list of available sources and provide an optional filtering pattern that will be used to transfer only the events you require. For the optional transformation and enrichment step of a pipe, you can provide an API endpoint, such as a SaaS application API or container cluster, Lambda function, or Amazon Step Function. The pipe will then make the API request and capture the response once processing is completed. Finally, set a destination service to which the events are delivered, and specify whether you require archiving or DLQ capabilities to be enabled on the pipe. You can also create a pipe using the Amazon CLI, CloudFormation, CloudFormation, or Amazon Cloud Development Kit (CDK).

Q: What are the possible event sources for EventBridge Pipes?

EventBridge Pipes introduces Amazon SQS, Amazon Kinesis, Amazon DynamoDB, Amazon Managed Streaming Kafka, self-managed Kafka, and Amazon MQ as sources to the EventBridge product suite. EventBridge Pipes supports the same target services as event buses, such as Amazon SQS, Amazon Step Functions, Amazon Kinesis Data Streams, Amazon Kinesis Data Firehose, Amazon SNS, Amazon ECS, and event buses themselves.

Q: How does transformation and enrichment work?

EventBridge Pipes support basic transformations using Velocity Template Language (VTL). For more powerful transformations, EventBridge Pipes helps you specify a Lambda function or Step Functions workflow to transform your event. If you’d prefer to use a container service such as Amazon Elastic Container Service (ECS) or Amazon Elastic Kubernetes Service (EKS), you can specify the API endpoint and authentication scheme for your container cluster. EventBridge will then take care of delivering the event for transformation.

Q: Do I need to use an EventBridge event bus to use EventBridge Pipes?

No, EventBridge Pipes can be used independently of existing EventBridge features, helping you receive events from other event producers such as Kinesis, SQS, or Amazon MSK, without needing to use an EventBridge event bus. It is also used for point-to-point integrations, where an event bus is used for many-to-many integrations. If you are already using an EventBridge event bus to route events, you can use EventBridge Pipes to connect to a supported source and set your event bus as the source of a pipe.

Q: What is the difference between EventBridge event bus and EventBridge Pipes?

EventBridge event buses are well suited for many-to-many routing of events between event-driven services. EventBridge Pipes is intended for point-to-point integrations between event publishers and consumers, with support for advanced transformations and enrichments. EventBridge Pipes can use an EventBridge event bus as a target. Migrating from an EventBridge event bus rule to a pipe is easier, as filtering and targets remain the same between the two resources.

Q: How is EventBridge Pipes different from Amazon Lambda’s Event Source Mapping (ESM)?

Amazon Lambda’s Event Source Mapping (ESM) and Amazon EventBridge Pipes use the same polling infrastructure to select and send events. ESM is ideal for customers who want to use Lambda as a target to process the received events. Pipes is ideal for customers who would rather not worry about creating, maintaining, and scaling Lambda code and instead prefer a simple, managed resources to connect their source to one of over 14 targets.

Q: Does EventBridge Pipes provide ordering guarantees?

Yes, EventBridge Pipes will maintain the order of events received from an event source when sending those events to a destination service.

Q: Does EventBridge Pipes support batching events?

Yes, for services that support batching events, you can configure your desired batch size when creating a pipe. For sources and targets that don’t support batching, you can still choose to batch events for your enrichment and transformation step. This helps you save compute costs and still helps you deliver events individually to your chosen target.

Q: Can I get a history of EventBridge Pipes API calls made on my account for security analysis and operational troubleshooting purposes?

Yes, to receive a history of EventBridge Pipes API calls made on your account, you need to turn on CloudTrail in the Amazon Web Services Management Console.

Q: What does EventBridge Pipes cost?

To see the full details of pricing for Amazon EventBridge Pipes, visit the pricing page.

Q: What does event bridge cost?
Please see Pricing here.

Q: Will I be charged for events sent by a partner to an event source that does not have an event bus attached?
No.

Q: Can I have a target that sends events to another account?
Yes. These are called cross-account events, and you can have a target that is either the default event bus or any other event bus in another account.

Q: Can I use Amazon CloudFormation with Amazon EventBridge?
Amazon CloudFormation is supported for Rules and EventBusPolicy resources. Event bus and event source resources are not yet supported, but will be in the future.

Q: When should I use Amazon EventBridge and when should I use Amazon SNS?
Both Amazon EventBridge and Amazon SNS can be used to develop event-driven applications, and your choice will depend on your specific needs. Amazon EventBridge is recommended when you want to build an application that reacts to events from SaaS applications and/or Amazon Web Services services. Amazon EventBridge is the only event-based service that integrates directly with third-party SaaS partners. Amazon EventBridge also automatically ingests events from over 90 Amazon Web Services services without requiring developers to create any resources in their account. Further, Amazon EventBridge uses a defined JSON-based structure for events, and allows you to create rules that are applied across the entire event body to select events to forward to a target. Amazon EventBridge currently supports over 15 Amazon Web Services services as targets, including Amazon Lambda, Amazon SQS, Amazon SNS, and Amazon Kinesis Streams and Firehose, among others. At launch, Amazon EventBridge is has limited throughput (see Service Limits) which can be increased upon request, and typical latency of around half a second.
Amazon SNS is recommended when you want to build an application that reacts to high throughput or low latency messages published by other applications or microservices (as Amazon SNS provides nearly unlimited throughput), or for applications that need very high fan-out (thousands or millions of endpoints). Messages are unstructured and can be in any format. Amazon SNS supports forwarding messages to 6 different types of targets, including Amazon Lambda, Amazon SQS, HTTP/S endpoints, SMS, Mobile Push, and email. Amazon SNS typical latency is under 30 msec. A wide range of Amazon Web Services services send SNS messages by configuring the service to do so (more than 30, including Amazon EC2, Amazon S3, and Amazon RDS).

Q: Why would I integrate my SaaS application with Amazon EventBridge?
Amazon EventBridge makes it easy for SaaS vendors to integrate their service into their customers’ event-driven architectures built on Amazon Web Services. Amazon EventBridge makes your product directly accessible to millions of Amazon Web Services developers, unlocking new use cases. It offers a fully auditable, secure, and scalable pathway to send events without the SaaS vendor managing any eventing infrastructure.

Q: How much effort will be required for a SaaS Partner to integrate with Amazon EventBridge?
Partners who already support a webhook or other push-based integration mode can expect to perform less than 5 days of development to integrate with Amazon EventBridge.