Overview

Q: What is Amazon EventBridge?

Amazon EventBridge is a service that provides real-time access to changes in data in AWS 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 AWS services including AWS Lambda, Amazon Simple Notification Service (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 AWS account, navigate to the Amazon EventBridge console, and choose an event source from a list of partner SaaS applications and AWS 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 AWS 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 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. You can generate custom application-level events and publish them to Amazon EventBridge via the service’s APIs. You 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 Elastic Compute Cloud (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 anytime an Auto Scaling group successfully creates an Amazon EC2 instance.

Q: How do I secure access to Amazon EventBridge?

Amazon EventBridge integrates with AWS Identity and Access Management (IAM) so that you can specify which actions a user in your AWS 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 additional features. Over time, the Amazon CloudWatch Events name will be replaced with Amazon EventBridge.

Q: Which AWS services are integrated as event sources for Amazon EventBridge?

There are over 90 AWS services available as event sources for EventBridge, including AWS Lambda, Amazon Kinesis, AWS Fargate, and Amazon Simple Storage Service (S3). For a full list of AWS service integrations, see the EventBridge documentation.

Q: Which AWS services are integrated as event targets for Amazon EventBridge?

There are over 15 AWS services available as event targets for EventBridge including AWS Lambda, Amazon Simple Queue Service (SQS), Amazon SNS, Amazon Kinesis Streams, and Amazon Kinesis Data Firehose. For a full list of AWS service integrations, see the EventBridge documentation.

Q: What is EventBridge Archive and Replay Events?

Event Replay is a new feature for Amazon EventBridge that allows customers to reprocess past events back to an event bus or a specific EventBridge rule. This feature allows developers to debug their applications easily, extend them by hydrating targets with historic events, and recover from errors. Event Replay gives developers peace of mind that they will always have access to any event published to EventBridge.

Q: What is EventBridge API Destinations?

API Destinations enables developers to send events back to any on-premises or SaaS applications with the ability to control throughput and authentication. Customers 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 triggered, Amazon EventBridge will transform the event based on the conditions specified, and 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 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 in AWS Secrets Manager to store the authorization information securely. You can also add further parameters to include in the connection as appropriate for your application.

To set up an API destination, you will need to provide an API destination endpoint – 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 -the maximum number of invocations per second to send to the API destination endpoint. Learn more about Connections and API destinations.

Limits and performance

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 AWS Support Center by choosing 'Create Case' and then choosing 'Service Limit Increase'.

Q: Does EventBridge have a Service Level Agreement?

Yes. AWS will use commercially reasonable efforts to make EventBridge available with a Monthly Uptime Percentage for each AWS Region, during any monthly billing cycle, of at least 99.99%. For details, please review the full EventBridge Service Level Agreement.

Schema Registry

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 allows you to write code based on that data.

Q: What is a schema registry?

A schema registry stores a searchable collection of schema so any developer in your organization can easily access schema generated by the application, rather than 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 IDE, which allows you to represent the event as a strongly-typed object in your code, and take advantage of IDE features such as validation and auto-complete.

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

Schema discovery is only enabled for events originating within the same account as the discoverer on the default, custom, and partner 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 5M ingested events per month, which should cover most development usage. There is a fee of $0.10 per million ingested events for additional usage outside of the free tier. For more info on pricing, please see the EventBridge pricing page.

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

First, you can use schema discovery to 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. Second, when you write applications that handle events on your bus, you can generate and download code bindings for this schema so you can use strongly-typed objects directly in your code. This saves overhead for deserialization, validation, and guesswork for your event handler.

Q: Why should I use the schema registry?

With the schema registry, EventBridge gives you a way to develop event-driven applications faster, allowing you to focus on your application code. Previously, you needed to find available events and their structure, and write code to interpret and translate events into a format understandable by your code. Now, with the schema registry, you can automatically find the events available from any supported event source, including AWS services, third-party, and custom applications, and detect their schema.

Q: Which IDEs does the schema registry support?

The schema registry is available via the AWS Toolkit for JetBrains (IntelliJ, PyCharm, WebStorm, Rider) and VS 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 Serverless Application Model (AWS SAM)?

Yes, the latest version of the AWS SAM CLI includes an interactive mode that allows you to create new serverless applications on EventBridge for any schema as an event type. Simply choose the “EventBridge Starter App” template, and the schema of your event, and AWS 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 auto-complete in your IDE.

The AWS Toolkit for Jetbrains (Intellij, PyCharm, Webstorm, Rider) plugin and AWS 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?

Code generation is available in Java (8+), Python (3.6+), and TypeScript (3.0+).

Q: In which AWS Regions is the schema registry available?

The EventBridge schema registry is available in the following Regions: US East (Ohio and N. Virginia), US West (Oregon and N. California), Canada (Central), EU (Stockholm, Paris, Ireland, Frankfurt, and London), Asia Pacific (Mumbai, Tokyo, Seoul, Singapore, Hong Kong, and Sydney), and South America (Sao Paulo).

Global endpoints

Q: What are global endpoints?

Global endpoints are a new feature of Amazon EventBridge that makes it easier for you to build highly available event-driven applications using AWS. You can replicate your events across primary and secondary regions to enable failover with minimum data loss along with the ability to failover automatically to a backup Region in the case of any service disruptions. This simplifies adoption of multi-Region architectures and allows you to incorporate resiliency into your event-driven applications.

Q: Why should I use global endpoints?

Global endpoints help you provide a better experience for your end-customers by minimizing the amount of data at risk during service disruptions. You can make your event-driven applications more robust and resilient by having the ability to failover your event ingestion to a secondary region automatically and without the need for manual intervention. You have the flexibility to configure failover criteria using CloudWatch Alarms (via Route53 health checks) to determine when to failover and when to route events back to the primary region.

Q: How does global endpoint improve the availability of my applications?

Once you publish events to the global endpoint, the events are routed to the event bus in your primary region. If errors are detected in the primary region, your healthcheck is marked as unhealthy and incoming events are routed to the secondary region. Errors can be detected easily using CloudWatch Alarms (via Route53 health checks) that you specify. As soon the issue is mitigated, we route new events back to the primary Region and continue processing of the events.

Q: What type of applications are well suited for Global Endpoints?

Global endpoints are well suited for applications that do not require idempotency or can handle idempotency across regions. They are also well suited for applications that are tolerant with having up to 420 seconds of events being not replicated and thus, stuck in the primary region until the service or region recovers (referred to as the Recovery Point Objective).

Q: What metrics should I use to failover my global endpoint?

We have added a new metric that reports the end-to-end latency of Amazon EventBridge that will allow you to easily determine if there are errors within EventBridge that would require you to failover your event ingestion to the secondary region. We have made it easy for you to get started in the console by providing a pre-populated CloudFormation stack (that you can customize if you choose to) for creating a CloudWatch Alarm and Route53 Health Checks. For more details on how to set up the alarms and the health checks, please check out our launch blog and documentation.

Q: Should I use metrics from my subscriber to failover my global endpoint?

We recommend against including subscriber metrics in your Health Check as this could cause your publisher to failover to the backup region if a single subscriber encounters an issue, despite all other subscribers being healthy in the primary region. If one of your subscribers is failing to process events in the primary region, you should turn on replication to ensure that your subscriber in the secondary region is able to process events successfully.

Q: What is the expected Recovery Time Objective (RTO) and Recovery Point Objective (RPO)?

The Recovery Time Objective (RTO) is the time for which the backup Region or target will start receiving new events after a failure. The Recovery Point Objective (RPO) is the measure of the data that will be left unprocessed during a failure. With global endpoints, if you are following our prescriptive guidance for alarm configuration, the RTO and RPO will be 360 seconds (with a maximum of 420). For RTO, the time includes time period for triggering CloudWatch Alarms and updating statuses for Route53 health checks. For RPO, the time includes events that are not replicated to the secondary region and are stuck in the primary region until the service or region recovers.

Q: Should I turn on replication?

Yes. You should turn on replication to minimize the data at risk during a service disruption. Once you setup your custom buses in both regions and create the global endpoint, you can update your applications to publish your events to the global endpoint. By doing so, your incoming events will be replicated back to the primary region once the issue is mitigated. You can archive your events in the secondary region to ensure none of your events are lost during a disruption. To recover quickly from disruptions, you can replicate your architecture in the secondary region to continue processing your events. You also need to turn on replication to ensure automatic recovery after the issue has been mitigated.

Q: What’s the best practice for managing quotas in both my regions?

You should ensure that the same quotas have been setup in your primary and secondary regions. As a best practice, you should turn on replication and process your events in the secondary region as this ensures not only that you have the right quotas, but also that your application in the secondary region is configured correctly.

Q: Is there an easy way to replicate my architecture in my secondary region?

You can use AWS CloudFormation StackSets that makes it easy to replicate your architecture across AWS regions. For an example, please refer to our documentation.

Q: Can I use any account, any region and any bus for my secondary architecture?

In the first iteration of the launch, Opt-in, China or GovCloud regions are not supported. For the list of regions supported at launch, please see Q#16 below. We are also supporting failover and recovery between the same account and buses with the same name across regions.

Q: Do global endpoints work with AWS events from CloudTrail, S3, and other AWS services?

Global endpoints are available for custom events only. We will be adding support for events from AWS services, opt-in events from S3 (Amazon S3 event notifications), and third party events in the future.

Q: Do you support latency based routing?

No, we are not supporting latency based routing in the first iteration of the launch.
How much do global endpoints cost?

Global endpoints are available at no additional charge. Today, global endpoints are available for custom events only and custom Events published to the global endpoint are billed as per the custom events pricing. To learn about pricing, please visit the EventBridge pricing page.

Q: Will I be charged for replication?

Yes, you will be charged $1 per million events for replication, which EventBridge charges for cross region events.

Q: In which regions are global endpoints available?

Global endpoints are available in the following regions: US East (Ohio and N. Virginia), US West (Oregon and N. California), Canada (Central), EU (Stockholm, Paris, Ireland, Frankfurt, and London), Asia Pacific (Mumbai, Tokyo, Seoul, Singapore, Osaka, and Sydney), and South America (Sao Paulo).

Cost and billing

Q: What does EventBridge 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.

Architecture and design

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 AWS CloudFormation with Amazon EventBridge?

Yes. CloudFormation support is available in all regions where Amazon EventBridge is available. To learn more about how to use CloudFormation to provision and manage Amazon EventBridge resources, visit our documentation.

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 AWS 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 AWS 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 AWS services as targets, including AWS Lambda, Amazon SQS, Amazon SNS, and Amazon Kinesis Streams and Kinesis Data Firehose, among others. At launch, Amazon EventBridge has limited throughput (see service limits) that 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 six different types of targets, including AWS Lambda, Amazon SQS, HTTP/S endpoints, SMS, mobile push, and email. Amazon SNS typical latency is under 30 msec. A wide range of AWS services send SNS messages by configuring the service to do so (more than 30, including Amazon EC2, Amazon S3, and Amazon RDS).

Integrations

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 AWS. Amazon EventBridge makes your product directly accessible to millions of AWS 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: My SaaS company would be a great event source. How do I get on-boarded?

SaaS vendors interested in becoming an Amazon EventBridge partner should follow self-service instructions at the Amazon EventBridge integrations page to begin publishing events to Amazon EventBridge.

Q: How much effort will be required for an SaaS vendor to integrate with Amazon EventBridge?

SaaS vendors that 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.

Q: Which SaaS integrations are supported?

For a full list of supported integrations, please see here.

Amazon EventBridge Integrations
Learn more about the Amazon EventBridge integrations

Visit the Amazon EventBridge integrations page.

Learn more 
Start building in the console
Start building in the console

Get started building with Amazon EventBridge in the AWS Management Console.

Sign in 
Read the documentation
Learn more in documentation

Get a deeper understanding of EventBridge in the Developer Guide.

Learn more