# Event buses in Amazon EventBridge
<a name="eb-event-bus"></a>

An event bus is a router that receives [events](eb-events.md) and delivers them to zero or more destinations, or *targets*. Event buses are well-suited for routing events from many sources to many targets, with optional transformation of events prior to delivery to a target. 

![\[Sources send events to an EventBridge event bus, which then routes them to the appropriate targets.\]](http://docs.aws.amazon.com/eventbridge/latest/userguide/images/bus_eventbridge_conceptual.svg)


[Rules](eb-rules.md) associated with the event bus evaluate events as they arrive. Each rule checks whether an event matches the rule's pattern. If the event does match, EventBridge sends the event 

You associate a rule with a specific event bus, so the rule only applies to events received by that event bus. 

**Note**  
You can also process events using EventBridge Pipes. EventBridge Pipes is intended for point-to-point integrations; each pipe receives events from a single source for processing and delivery to a single target. Pipes also include support for advanced transformations and enrichment of events prior to delivery to a target. For more information, see [Amazon EventBridge Pipes](eb-pipes.md).

## How event buses work in EventBridge
<a name="eb-what-is-how-it-works"></a>

Event buses enable you to route events from multiple sources to multiple destinations, or *targets*. 

At a high level, here's how it works:

1. An event source, which can be an AWS service, your own custom application, or a SaaS provider, sends an event to an event bus.

1. EventBridge then evaluates the event against each *rule* defined for that event bus. 

   For each event that matches a rule, EventBridge then sends the event to the targets specified for that rule. Optionally, as part of the rule, you can also specify how EventBridge should transform the event prior to sending it to the target(s).

   An event might match multiple rules, and each rule can specify up to five targets. (An event may not match any rules, in which case EventBridge takes no action.)

![\[An event bus compares events against rules, and sends matching events to the specified targets.\]](http://docs.aws.amazon.com/eventbridge/latest/userguide/images/bus-overview_eventbridge_conceptual.svg)


Consider an example using the EventBridge default event bus, which automatically receives events from AWS services:

1. You create a rule on the default event bus for the `EC2 Instance State-change Notification` event: 
   + You specify that the rule matches events where an Amazon EC2 instance has changed its `state` to `running`.

     You do this by specifying JSON that defines the attributes and values an event must match to trigger the rule. This is called an *event pattern*. 

     ```
     {
       "source": ["aws.ec2"],
       "detail-type": ["EC2 Instance State-change Notification"],
         "detail": {
           "state": ["running"]
       }
     }
     ```
   + You specify the target of the rule to be a given Lambda function.

1. Whenever an Amazon EC2 instance changes state, Amazon EC2 (the event source) automatically sends that event to the default event bus.

1. EventBridge evaluates all events sent to the default event bus against the rule you've created.

   If the event matches your rule (that is, if the event was an Amazon EC2 instance changing state to `running`), EventBridge sends the event to the specified target. In this case, that's the Lambda function.

 The following video describes what event buses are and explains some of the basics of them:




 The following video covers the different event buses and when to use them:




# Event bus concepts in Amazon EventBridge
<a name="eb-what-is-how-it-works-concepts"></a>

Here's a closer look at the main components of an event driven architecture built on event buses.

## Event buses
<a name="eb-bus-concepts-buses"></a>

An event bus is a router that receives [events](eb-events.md) and delivers them to zero or more destinations,or *targets*. Use an event bus when you need to route events from many sources to many targets, with optional transformation of events prior to delivery to a target.

Your account includes a *default event bus* that automatically receives events from AWS services. You can also:
+ Create additional event buses, called *custom event buses*, and specify which events they receive.
+ Create *[partner event buses](eb-saas.md)*, which receive events from SaaS partners.

Common use cases for event buses include:
+ Using an event bus as a broker between different workloads, services, or systems.
+ Using multiple event buses in your applications to divide up the event traffic. For example, creating a bus to process events containing personal identification information (PII), and another bus for events that don't.
+ Aggregating events by sending events from multiple event buses to a centralized event bus. This centralized bus can be in the same account as the other buses, but can also be in a different account or Region.

![\[The different event buses that receive events from AWS services, custom apps, or partner sources.\]](http://docs.aws.amazon.com/eventbridge/latest/userguide/images/bus-overview-types_eventbridge_conceptual.svg)


## Events
<a name="eb-bus-concepts-events"></a>

At its simplest, an EventBridge event is a JSON object sent to an event bus or pipe. 

In the context of event-driven architecture (EDA), an event often represents an indicator of a change in a resource or environment.

For more information, see [Events in Amazon EventBridge](eb-events.md).

## Event sources
<a name="eb-bus-concepts-event-sources"></a>

EventBridge can receive events from event sources including:
+ AWS services
+ Custom applications
+ Software as a service (SaaS) partners

## Rules
<a name="eb-bus-concepts-rules"></a>

A rule receives incoming events and sends them as appropriate to targets for processing. You can specify how each rule invokes their target(s) based on either:
+ An [event pattern](eb-event-patterns.md), which contains one or more filters to match events. Event patterns can include filters that match on:
  + **Event metadata** – Data *about* the event, such as the event source, or the account or Region in which the event originated.
  + **Event data** – The properties of the event itself. These properties vary according to event.
  + **Event content** – The actual property *values* of the event data.
+ A schedule to invoke the target(s) at regular intervals. 

  You can [specify a scheduled rule within EventBridge](eb-create-rule-schedule.md), or by using [EventBridge Scheduler](using-eventbridge-scheduler.md). 
**Note**  
Scheduled rules are a legacy feature of EventBridge.  
EventBridge offers a more flexible and powerful way to create, run, and manage scheduled tasks centrally, at scale: EventBridge Scheduler. With EventBridge Scheduler, you can create schedules using cron and rate expressions for recurring patterns, or configure one-time invocations. You can set up flexible time windows for delivery, define retry limits, and set the maximum retention time for failed API invocations.   
Scheduler is highly customizable, and offers improved scalability over scheduled rules, with a wider set of target API operations and AWS services. We recommend that you use Scheduler to invoke targets on a schedule.  
For more information, see [Create a schedule](using-eventbridge-scheduler.md#using-eventbridge-scheduler-create) or the *[EventBridge Scheduler User Guide](https://docs.aws.amazon.com/scheduler/latest/UserGuide/what-is-scheduler.html)*.

Each rule is defined for a specific event bus, and only apply to events on that event bus.

A single rule can send an event to up to five targets.

By default, you can configure up to 300 rules per event bus. This quota can be raised to thousands of rules in the [Service Quotas console](https://console.aws.amazon.com/servicequotas/home). Since the rule limit apply to each bus, if you require even more rules, you can create additional custom event buses in your account.

You can customize how events are received in your account by creating event buses with different permissions for different services.

To customize the structure or date of an event before EventBridge passes it to a target, use the [input transformer](eb-transform-target-input.md) to edit the information before it goes to the target.

For more information, see [Rules in Amazon EventBridge](eb-rules.md).

## Targets
<a name="eb-bus-concepts-targets"></a>

A target is a resource or endpoint to which EventBridge sends an event when the event matches the event pattern defined for a rule.

A target can receive multiple events from multiple event buses.

For more information, see [Event bus targets in Amazon EventBridge](eb-targets.md).

## Advanced features for event buses
<a name="eb-what-is-how-it-works-advanced"></a>

EventBridge includes the following features to help you develop, manage, and use event buses.

**Using API destinations to enable REST API calls between services**

EventBridge *[API destinations](eb-api-destinations.md)* are HTTP endpoints that you can set as the target of a rule, in the same way that you would send event data to an AWS service or resource. By using API destinations, you can use API calls to route events between AWS services, integrated SaaS applications, and your applications outside of AWS. When you create an API destination, you specify a connection to use for it. Each connection includes the details about the authorization type and parameters to use to authorize with the API destination endpoint.

**Archiving and replaying events to aid development and disaster recovery**

You can *[archive](eb-archive-event.md)*, or save, events and then [replay](eb-replay-archived-event.md) them at a later time from the archive. Archiving is useful for: 
+ Testing an application because you have a store of events to use rather than having to wait for new events.
+ Hydrating a new service when it first comes online.
+ Adding more durability to your event-driven applications.

**Using the Schema Registry to jump-start event pattern creation**

When you build serverless applications that use EventBridge, it can be helpful to know the structure of typical events without having to generate the event. The event structure are described in [schemas](eb-schema.md), which are available for all events generated by AWS services on EventBridge. 

For events that don't come from AWS services, you can:
+ Create or upload custom schemas.
+ Use Schema Discovery to have EventBridge automatically create schemas for events sent to the event bus.

Once you have a schema for an event, you can download code bindings for popular programming languages.

**Managing resources and access with policies**

To organize AWS resources or to track costs in EventBridge, you can assign a custom label, or *[tag](eb-tagging.md)*, to AWS resources. Using [tag-based policies](eb-tag-policies.md), you can control what resources can and can’t do within EventBridge.

In addition to tag-based policies, EventBridge supports [identity-based](eb-use-identity-based.md) and [resource-based](eb-use-resource-based.md) policies to control access to EventBridge. Use identity-based policies to control the permissions of a group, role, or user. Use resource-based policies to give specific permissions to each resource, such as a Lambda function or Amazon SNS topic.

# Creating an event bus in Amazon EventBridge
<a name="eb-create-event-bus"></a>

You can create a custom [event bus](eb-event-bus.md) to receive [events](eb-events.md) from your applications. Your applications can also send events to the default event bus. When you create an event bus, you can attach a [resource-based policy](eb-use-resource-based.md) to grant permissions to other accounts. Then other accounts can send events to the event bus in the current account.

 The following video goes through creating event buses:




**To create a custom event bus**

1. Open the Amazon EventBridge console at [https://console.aws.amazon.com/events/](https://console.aws.amazon.com/events/).

1. In the navigation pane, choose **Event buses**.

1. Choose **Create event bus**.

1. Enter a name for the new event bus.

1. Choose the KMS key for EventBridge to use when encrypting the event data stored on the event bus.
**Note**  
Schema discovery is not supported for event buses encrypted using a customer managed key. To enable schema discovery on an event bus, choose to use an AWS owned key. For more information, see [KMS key options](eb-encryption-at-rest-key-options.md).
   + Choose **Use AWS owned key** for EventBridge to encrypt the data using an AWS owned key.

     This AWS owned key is a KMS key that EventBridge owns and manages for use in multiple AWS accounts. In general, unless you are required to audit or control the encryption key that protects your resources, an AWS owned key is a good choice. 

     This is the default.
   + Choose **Use customer managed key** for EventBridge to encrypt the data using the customer managed key that you specify or create.

     Customer managed keys are KMS keys in your AWS account that you create, own, and manage. You have full control over these KMS keys.

     1. Specify an existing customer managed key, or choose **Create a new KMS key**.

        EventBridge displays the key status and any key aliases that have been associated with the specified customer managed key.

     1. Choose the Amazon SQS queue to use as the dead-letter queue (DLQ) for this event bus, if any.

        EventBridge sends events that aren't successfully encrypted to the DLQ, if configured, so you can process them later.

1. (Optional) Under **Logs - optional**, you can set up how EventBridge logs event information, including how to configure those logs. 

   For more information about event bus logs, see [Logging event buses ](eb-event-bus-logs.md).

   CloudWatch logs is selected as a log destination by default, as is the `ERROR` log level. So, by default, EventBridge creates a new CloudWatch log group to which it sends log records containing the `ERROR` level of detail.

   To have EventBridge send log records to any of the supported log destinations, do the following: 

   1. Under **Logs - optional**, choose the destinations to which you want log records delivered.

   1. For **Log level**, choose the level of information for EventBridge to include in log records. The `ERROR` log level is selected by default.

      For more information, see [Specifying log level](eb-event-bus-logs.md#eb-event-bus-logs-level).

   1. Select **Include detail data** if you want EventBridge to include event and target information in log records.

      For more information, see [Including details in logs](eb-event-bus-logs.md#eb-event-logs-data).

   1. Configure each log destination you selected.

1. Configure optional event bus features:
   + Specify a resource-based policy by doing one of the following:
     + Enter the policy that includes the permissions to grant for the event bus. You can paste in a policy from another source or enter the JSON for the policy. You can use one of the [example policies](eb-event-bus-perms.md) and modify it for your environment.
     + To use a template for the policy, choose **Load template**. Modify the policy as appropriate for your environment, including adding additional actions that you authorize the principal in the policy to use.

     For more information about granting permissions to an event bus through resource-based policies, see [Permissions for event buses in Amazon EventBridge](eb-event-bus-perms.md).
   + Enable an archive (optional)

     You can create an archive of events so that you can easily replay them at a later time. For example, you might want to replay events to recover from errors or to validate new functionality in your application. For more information, see [Archiving and replaying events in Amazon EventBridge](eb-archive.md)

     1. Under **Archives**, choose **Enabled**.

     1. Specify a name and description for the archive.

        You can't change the archive name once it has been created.

        When creating an archive as part of creating a new event bus, you can't set the event retention period or an event pattern for the archive. You can specify these for the archive once it has been created. For more information, see [Updating archives](event-bus-update-archive.md).
   + Enable schema discovery (optional)

     Enable schema discovery to have EventBridge automatically infer schemas directly from events running on this event bus. For more information, see [Amazon EventBridge schemas](eb-schema.md)

     1. Under **Schema discovery**, choose **Enabled**.
**Note**  
Schema discovery is not supported for event buses encrypted using a customer managed key. To enable schema discovery on an event bus, choose to use an AWS owned key. For more information, see [KMS key options](eb-encryption-at-rest-key-options.md).
   + Specify tags (optional)

     A tag is a custom attribute label that you assign to an AWS resource. Use tags to identify and organize your AWS resources. Many AWS services support tagging, so you can assign the same tag to resources from different services to indicate that the resources are related. For more information, see [Tagging resources in Amazon EventBridge](eb-tagging.md) 

     1. Under **Tags**, choose **Add new tag**.

     1. Specify a key and, optionally, a value for the new tag.

1. Choose **Create**.

# Updating an event bus in Amazon EventBridge
<a name="event-bus-update"></a>

You can update the configuration of event buses after you create them. This includes the default event bus, which EventBridge creates in your account automatically.

**To update an event bus (console)**

1. Open the Amazon EventBridge console at [https://console.aws.amazon.com/events/](https://console.aws.amazon.com/events/).

1. In the navigation pane, choose **Event buses**.

1. Choose the event bus you want to update.

1. Do one or more of the following:
   + To create, edit, or delete an archive, see the following procedures:

     [Creating archives](eb-archive-event.md)

     [Updating archives](event-bus-update-archive.md)

     [Deleting archives](eb-archive-delete.md)
   + To add or remove tags, see the following procedure:

     [Managing event bus tags](eb-tagging.md#event-bus-update-tags)
   + To manage event bus permissions, see the following procedure:

     [Managing event bus permissions](eb-event-bus-permissions-manage.md)
   + To change the AWS KMS key used to encrypt events, see the following procedure:

     [Update encryption on an event bus](eb-encryption-event-bus-cmkey-configure.md#eb-encryption-event-bus-cmkey-update)

# Updating a default event bus using AWS CloudFormation in EventBridge
<a name="event-bus-update-default-cfn"></a>

CloudFormation enables you to configure and manage your AWS resources across accounts and regions in a centralized and repeatable manner by treating infrastructure as code. CloudFormation does this by letting you create *templates*, which define the resources you want to provision and manage.

Because EventBridge provisions the default event bus into your account automatically, you cannot create it using a CloudFormation template, as you normally would for any resource you wanted to include in a CloudFormation stack. To include the default event bus in a CloudFormation stack, you must first *import* it into a stack. Once you have imported the default event bus into a stack, you can then update the event bus properties as desired.

To import an existing resource into a new or existing CloudFormation stack, you need the following information:
+ A unique identifier for the resource to import.

  For default event buses, the identifier is `Name` and then identifier value is `default`.
+ A template that accurately describes the current properties of the existing resource.

  The template snippet below contains an `AWS::Events::EventBus` resource that describes the current properties of a default event bus. In this example, the event bus has been configured to use a customer managed key and DLQ for encryption at rest.

  Also, the `AWS::Events::EventBus` resource that describes the default event bus you want to import should include a `DeletionPolicy` property set to `Retain`.

  ```
  {
      "AWSTemplateFormatVersion": "2010-09-09",
      "Description": "Default event bus import example",
      "Resources": {
          "defaultEventBus": {
              "Type" : "AWS::Events::EventBus",
              "DeletionPolicy": "Retain",
              "Properties" : {
                  "Name" : "default",
                  "KmsKeyIdentifier" : "KmsKeyArn",
                  "DeadLetterConfig" : {
                      "Arn" : "DLQ_ARN"
                  }
              }
          }
      }
  }
  ```

For more information, see [Bringing existing resources into CloudFormation management](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/resource-import.html) in the *CloudFormation User Guide*.

# Deleting an event bus in Amazon EventBridge
<a name="event-bus-delete"></a>

You can delete a custom or partner event bus. You cannot delete the default event bus. Deleting an event bus deletes the rules associated with that event bus.

**To delete an event bus using the EventBridge console**

1. Open the Amazon EventBridge console at [https://console.aws.amazon.com/events/](https://console.aws.amazon.com/events/).

1. In the navigation pane, choose **Event buses**.

1. Choose the event bus you want to delete.

1. Do one of the following:
   + Choose **Delete**.
   + Choose the name of the event bus.

     On the event bus details page, choose **Delete**.

# Generating an CloudFormation template from an existing EventBridge event bus
<a name="eb-generate-event-bus-template"></a>

AWS CloudFormation enables you to configure and manage your AWS resources across accounts and regions in a centralized and repeatable manner by treating infrastructure as code. CloudFormation does this by letting you create *templates*, which define the resources you want to provision and manage.

EventBridge enables you to generate templates from the existing event buses in your account, as an aid to help you jumpstart developing CloudFormation templates. In addition, EventBridge provides the option of including the rules associated with that event bus in your template. You can then use these templates as the basis for [creating stacks](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-create-stack.html) of resources under CloudFormation management.

For more information on CloudFormation see [*The CloudFormation User Guide*.](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)

**Note**  
EventBridge does not include [managed rules](eb-rules.md#eb-rules-managed) in the generated template.

You can also [generate a template from one or more rules contained in a selected event bus](https://docs.aws.amazon.com/eventbridge/latest/userguide/rule-create-template.html).

**To generate an CloudFormation template from an event bus**

1. Open the Amazon EventBridge console at [https://console.aws.amazon.com/events/](https://console.aws.amazon.com/events/).

1. In the navigation pane, choose **Event buses**.

1. Choose the event bus from which you want to generate a CloudFormation template.

1. From the **Actions** menu, choose **CloudFormation Template**, and then choose which format you want EventBridge to generate the template in: **JSON** or **YAML**.

   EventBridge displays the template, generated in the selected format. By default, all rules associated with the event bus are included in the template.

   1. To generate the template without including rules, deselect **Include rules on this EventBus**.

1. EventBridge gives you the option of downloading the template file, or copying the template to the clipboard.
   + To download the template file, choose **Download**.
   + To copy the template to the clipboard, choose **Copy**.

1. To exit the template, choose **Cancel**. 

Once you've customized your CloudFormation template as necessary for your use case, you can use it to [create stacks](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-create-stack.html) in CloudFormation.

## Considerations when using CloudFormation templates generated from Amazon EventBridge
<a name="eb-generate-event-bus-template-considerations"></a>

Consider the following factors when using a CloudFormation template you generated from an event bus:
+ EventBridge does not include any passwords in the generate template.

  You can edit the template to include [template parameters](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/parameters-section-structure.html) that enable users to specify passwords or other sensitive information when using the template to create or update a CloudFormation stack.

  In addition, users can use Secrets Manager to create a secret in the desired region and then edit the generated template to employ [dynamic parameters](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/dynamic-references.html#dynamic-references-secretsmanager).
+ Targets in the generated template remain exactly as they were specified in the original event bus. This can lead to cross-region issues if you do not appropriately edit the template before using it to create stacks in other regions.

  Additionally, the generated template will not create the downstream targets automatically.

# Permissions for event buses in Amazon EventBridge
<a name="eb-event-bus-perms"></a>

The default [event bus](eb-event-bus.md) in your AWS account only allows [events](eb-events.md) from one account. You can grant additional permissions to an event bus by attaching a [resource-based policy](eb-use-resource-based.md) to it. With a resource-based policy, you can allow `PutEvents`, `PutRule`, and `PutTargets` API calls from another account. You can also use [IAM conditions](eb-use-conditions.md) in the policy to grant permissions to an organization, apply [tags](eb-tagging.md), or filter events to only those from a specific rule or account. You can set a resource-based policy for an event bus when you create it or afterward.

EventBridge APIs that accept an event bus `Name` parameter such as `PutRule`, `PutTargets`, `DeleteRule`, `RemoveTargets`, `DisableRule`, and `EnableRule` also accept the event bus ARN. Use these parameters to reference cross-account or cross-Region event buses through the APIs. For example, you can call `PutRule` to create a [rule](eb-rules.md) on an event bus in a different account without needing to assume a role.

You can attach the example policies in this topic to an IAM role to grant permission to send events to a different account or Region. Use IAM roles to set organization control policies and boundaries on who can send events from your account to other accounts. We recommend always using IAM roles when the target of a rule is an event bus. You can attach IAM roles using `PutTarget` calls. For information about creating a rule to send events to a different account or Region, see [Sending and receiving events between AWS accounts in Amazon EventBridge](eb-cross-account.md).

# Managing event bus permissions in Amazon EventBridge
<a name="eb-event-bus-permissions-manage"></a>

Use the following procedure to modify the permissions for an existing event bus. For information about how to use CloudFormation to create an event bus policy, see [AWS::Events::EventBusPolicy](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-events-eventbuspolicy.html).

**To manage permissions for an existing event bus**

1. Open the Amazon EventBridge console at [https://console.aws.amazon.com/events/](https://console.aws.amazon.com/events/).

1. In the left navigation pane, choose **Event buses**.

1. In **Name**, choose the name of the event bus to manage permissions for.

   If a resource policy is attached to the event bus, the policy displays.

1. Choose **Manage permissions**, and then do one of the following:
   + Enter the policy that includes the permissions to grant for the event bus. You can paste in a policy from another source, or enter the JSON for the policy.
   + To use a template for the policy, choose **Load template**. Modify the policy as appropriate for your environment, and add additional actions that you authorize the principal in the policy to use.

1. Choose **Update**.

The template provides example policy statements that you can customize for your account and environment. The template isn't a valid policy. You can modify the template for your use case, or you can copy one of the example policies and customize it.

The template loads policies that include an example of how to grant permissions to an account to use the `PutEvents` action, how to grant permissions to an organization, and how to grant permissions to the account to manage rules in the account. You can customize the template for your specific account, and then delete the other sections from the template. More example policies are included later in this section.

If you try to update the permissions for the bus but the policy contains an error, an error message indicates the specific issue in the policy.

```
  ### Choose which sections to include in the policy to match your use case. ###
  ### Be sure to remove all lines that start with ###, including the ### at the end of the line. ###

  ### The policy must include the following: ###

  {
    "Version": "2012-10-17",		 	 	 
    "Statement": [

      ### To grant permissions for an account to use the PutEvents action, include the following, otherwise delete this section: ###

      {

        "Sid": "AllowAccountToPutEvents",
        "Effect": "Allow",
        "Principal": {
          "AWS": "<ACCOUNT_ID>"
        },
        "Action": "events:PutEvents",
        "Resource": "arn:aws:events:us-east-1:123456789012:event-bus/default"
      },

      ### Include the following section to grant permissions to all members of your AWS Organizations to use the PutEvents action ###

      {
        "Sid": "AllowAllAccountsFromOrganizationToPutEvents",
        "Effect": "Allow",
        "Principal": "*",
        "Action": "events:PutEvents",
        "Resource": "arn:aws:events:us-east-1:123456789012:event-bus/default",
        "Condition": {
          "StringEquals": {
            "aws:PrincipalOrgID": "o-yourOrgID"
          }
        }
      },

      ### Include the following section to grant permissions to the account to manage the rules created in the account ###

      {
        "Sid": "AllowAccountToManageRulesTheyCreated",
        "Effect": "Allow",
        "Principal": {
          "AWS": "<ACCOUNT_ID>"
        },
        "Action": [
          "events:PutRule",
          "events:PutTargets",
          "events:DeleteRule",
          "events:RemoveTargets",
          "events:DisableRule",
          "events:EnableRule",
          "events:TagResource",
          "events:UntagResource",
          "events:DescribeRule",
          "events:ListTargetsByRule",
          "events:ListTagsForResource"],
        "Resource": "arn:aws:events:us-east-1:123456789012:rule/default",
        "Condition": {
          "StringEqualsIfExists": {
            "events:creatorAccount": "<ACCOUNT_ID>"
          }
        }
    }]
  }
```

# Example policy: Send events to the default bus in a different account in Amazon EventBridge
<a name="eb-event-bus-example-policy-cross-account"></a>

The following example policy grants the account 111122223333 permission to publish events to the default event bus in the account 123456789012.

------
#### [ JSON ]

****  

```
{
   "Version":"2012-10-17",		 	 	 
   "Statement": [
       {
        "Sid": "sid1",
        "Effect": "Allow",
        "Principal": {"AWS":"arn:aws:iam::111112222333:root"},
        "Action": "events:PutEvents",
        "Resource": "arn:aws:events:us-east-1:123456789012:event-bus/default"
        }
    ]
  }
```

------

# Example policy: Send events to a custom bus in a different account in Amazon EventBridge
<a name="eb-event-bus-example-policy-cross-account-custom-bus-source"></a>

The following example policy grants the account 111122223333 permission to publish events to the `central-event-bus` in account 123456789012, but only for events with a source value set to `com.exampleCorp.webStore` and a `detail-type` set to `newOrderCreated`.

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Sid": "WebStoreCrossAccountPublish",
      "Effect": "Allow",
      "Action": [
        "events:PutEvents"
      ],
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:root"
      },
      "Resource": "arn:aws:events:us-east-1:123456789012:event-bus/central-event-bus",
      "Condition": {
        "ForAllValues:StringEquals": {
          "events:source": "com.exampleCorp.webStore",
          "events:detail-type": "newOrderCreated"
        }
      }
    }
  ]
}
```

------

# Example policy: Send events to an event bus in the same account in Amazon EventBridge
<a name="eb-event-bus-example-policy-same-account"></a>

The following example policy attached to an event bus named `CustomBus1` allows the event bus to receive events from the same account and Region.

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "events:PutEvents"
            ],
            "Resource": [
                "arn:aws:events:us-east-1:111122223333:event-bus/CustomBus1"
            ]
        }
    ]
}
```

------

# Example policy: Send events from specific rules to an Amazon EventBridge bus in a different Region
<a name="eb-event-bus-example-policy-restrict-rule"></a>

The following example policy grants the account 111122223333 permission to send events that match a rule named `SendToUSE1AnotherAccount` in the Middle East (Bahrain) and US West (Oregon) Regions to an event bus named `CrossRegionBus` in the US East (N. Virginia) in account 123456789012. The example policy is added to the event bus named `CrossRegionBus` in account 123456789012. The policy allows events only if they match a rule specified for the event bus in account 111122223333. The `Condition` statement restricts events to only events that match the rules with the specified rule ARN.

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Sid": "AllowSpecificRulesAsCrossRegionSource",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111112222333:root"
      },
      "Action": "events:PutEvents",
      "Resource": "arn:aws:events:us-east-1:123456789012:event-bus/CrossRegionBus",
      "Condition": {
        "ArnEquals": {
          "aws:SourceArn": [
            "arn:aws:events:us-west-2:111112222333:rule/CrossRegionBus/SendToUSE1AnotherAccount",
            "arn:aws:events:me-south-1:111112222333:rule/CrossRegionBus/SendToUSE1AnotherAccount"
          ]
        }
      }
    }
  ]
}
```

------

# Example policy: Send events only from a specific Region to a different Region in Amazon EventBridge
<a name="eb-event-bus-example-policy-specific-region"></a>

The following example policy grants account 111122223333 permission to send all events that are generated in the Middle East (Bahrain) and US West (Oregon) Regions to the event bus named `CrossRegionBus` in account 123456789012 in the US East (N. Virginia) Region. Account 111122223333 doesn't have permission to send events that are generated in any other Region.

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Sid": "AllowCrossRegionEventsFromUSWest2AndMESouth1",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111112222333:root"
      },
      "Action": "events:PutEvents",
      "Resource": "arn:aws:events:us-east-1:123456789012:event-bus/CrossRegionBus",
      "Condition": {
        "ArnEquals": {
          "aws:SourceArn": [
            "arn:aws:events:us-west-2:*:*",
            "arn:aws:events:me-south-1:*:*"
          ]
        }
      }
    }
  ]
}
```

------

# Example policy: Deny sending events from specific Regions in Amazon EventBridge
<a name="eb-event-bus-example-policy-deny-regions"></a>

The following example policy attached to an event bus named `CrossRegionBus` in account 123456789012 grants permission for the event bus to receive events from the account 111122223333, but not events that are generated in the US West (Oregon) Region.

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Sid": "1AllowAnyEventsFromAccount111112222333",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111112222333:root"
      },
      "Action": "events:PutEvents",
      "Resource": "arn:aws:events:us-east-1:123456789012:event-bus/CrossRegionBus"
    },
    {
      "Sid": "2DenyAllCrossRegionUSWest2Events",
      "Effect": "Deny",
      "Principal": {
        "AWS": "*"
      },
      "Action": "events:PutEvents",
      "Resource": "arn:aws:events:us-east-1:123456789012:event-bus/CrossRegionBus",
      "Condition": {
        "ArnEquals": {
          "aws:SourceArn": [
            "arn:aws:events:us-west-2:*:*"
          ]
        }
      }
    }
  ]
}
```

------

# Events in Amazon EventBridge
<a name="eb-events"></a>

An *event* indicates a change in an environment such as an AWS environment, a SaaS partner service or application, or one of your applications or services. The following are examples of events:
+ Amazon EC2 generates an event when the state of an instance changes, such as from pending to running.
+ AWS CloudFormation generates an event when it creates, updates, or deletes a stack.
+ AWS CloudTrail publishes events when you make API calls.

You can also set up scheduled events that are generated on a periodic basis. 

Events are represented as JSON objects and they all have a similar structure, and the same top-level fields. For more information, see [Event structure](https://docs.aws.amazon.com/eventbridge/latest/ref/welcome.html#overiew-event-structure) in the *EventBridge Events Reference*.

## Events from AWS services
<a name="eb-service-event"></a>

Many AWS services generate events that EventBridge receives. When an AWS service in your account sends an event to EventBridge, it goes to your account’s default event bus.

For a list of AWS services that send events to EventBridge, and the events they send, see the [EventBridge Events Reference](https://docs.aws.amazon.com/eventbridge/latest/ref/welcome.html).

AWS services send events to EventBridge on a *durable* or *best-effort basis*. For more information, see [Event delivery level](https://docs.aws.amazon.com/eventbridge/latest/ref/welcome.html#event-delivery-level) in the *EventBridge Events Reference*.

 The following video explains the basics of events:




 The following video covers the ways events get to EventBridge:




# Sending events with `PutEvents` in Amazon EventBridge
<a name="eb-putevents"></a>

The `PutEvents` action sends multiple [events](eb-events.md) to EventBridge in a single request. For more information, see [PutEvents](https://docs.aws.amazon.com/eventbridge/latest/APIReference/API_PutEvents.html) in the *Amazon EventBridge API Reference* and [put-events](https://docs.aws.amazon.com/cli/latest/reference/events/put-events.html) in the *AWS CLI Command Reference*.

Each `PutEvents` request can support a limited number of entries. For more information, see [Amazon EventBridge quotas](eb-quota.md). The `PutEvents` operation attempts to process all entries in the natural order of the request. After you call `PutEvents`, EventBridge assigns each event a unique ID.

The following example Java code sends two identical events to EventBridge.

------
#### [ AWS SDK for Java Version 2.x ]

```
EventBridgeClient eventBridgeClient =
    EventBridgeClient.builder().build();

PutEventsRequestEntry requestEntry = PutEventsRequestEntry.builder()
    .resources("resource1", "resource2")
    .source("com.mycompany.myapp")
    .detailType("myDetailType")
    .detail("{ \"key1\": \"value1\", \"key2\": \"value2\" }")
    .build();

List <
PutEventsRequestEntry > requestEntries = new ArrayList <
PutEventsRequestEntry > ();
requestEntries.add(requestEntry);

PutEventsRequest eventsRequest = PutEventsRequest.builder()
    .entries(requestEntries)
    .build();

PutEventsResponse result = eventBridgeClient.putEvents(eventsRequest);

for (PutEventsResultEntry resultEntry: result.entries()) {
    if (resultEntry.eventId() != null) {
        System.out.println("Event Id: " + resultEntry.eventId());
    } else {
        System.out.println("PutEvents failed with Error Code: " + resultEntry.errorCode());
    }
}
```

------
#### [ AWS SDK for Java Version 1.0 ]

```
EventBridgeClient eventBridgeClient =
    EventBridgeClient.builder().build();
    
PutEventsRequestEntry requestEntry = new PutEventsRequestEntry()
        .withTime(new Date())
        .withSource("com.mycompany.myapp")
        .withDetailType("myDetailType")
        .withResources("resource1", "resource2")
        .withDetail("{ \"key1\": \"value1\", \"key2\": \"value2\" }");

PutEventsRequest request = new PutEventsRequest()
        .withEntries(requestEntry, requestEntry);

PutEventsResult result = awsEventsClient.putEvents(request);

for (PutEventsResultEntry resultEntry : result.getEntries()) {
    if (resultEntry.getEventId() != null) {
        System.out.println("Event Id: " + resultEntry.getEventId());
    } else {
        System.out.println("Injection failed with Error Code: " + resultEntry.getErrorCode());
    }
}
```

------

After you run this code, the `PutEvents` result includes an array of response entries. Each entry in the response array corresponds to an entry in the request array in order from the beginning to the end of the request and response. The response `Entries` array always includes the same number of entries as the request array.

## Handling failures with `PutEvents`
<a name="eb-failure-handling"></a>

By default, if an individual entry within a request fails, EventBridge continues processing the rest of the entries in the request. A response `Entries` array can include both successful and unsuccessful entries. You must detect unsuccessful entries and include them in a subsequent call.

Successful result entries include an `Id` value, and unsuccessful result entries include `ErrorCode` and `ErrorMessage` values. `ErrorCode` describes the type of error. `ErrorMessage` provides more information about the error. The following example has three result entries for a `PutEvents` request. The second entry is unsuccessful.

```
{
    "FailedEntryCount": 1, 
    "Entries": [
        {
            "EventId": "11710aed-b79e-4468-a20b-bb3c0c3b4860"
        },
        {   "ErrorCode": "InternalFailure",
            "ErrorMessage": "Internal Service Failure"
        },
        {
            "EventId": "d804d26a-88db-4b66-9eaf-9a11c708ae82"
        }
    ]
}
```

**Note**  
If you use `PutEvents` to publish an event to an event bus that does not exist, EventBridge event matching will not find a corresponding rule and will drop the event. Although EventBridge will send a `200` response, it will not fail the request or include the event in the `FailedEntryCount` value of the request response.

You can include entries that are unsuccessful in subsequent `PutEvents` requests. First, to find out if there are failed entries in the request, check the `FailedRecordCount` parameter in `PutEventsResult`. If it isn't zero, then you can add each `Entry` that has an `ErrorCode` that is not null to a subsequent request. The following example shows a failure handler.

```
PutEventsRequestEntry requestEntry = new PutEventsRequestEntry()
        .withTime(new Date())
        .withSource("com.mycompany.myapp")
        .withDetailType("myDetailType")
        .withResources("resource1", "resource2")
        .withDetail("{ \"key1\": \"value1\", \"key2\": \"value2\" }");

List<PutEventsRequestEntry> putEventsRequestEntryList = new ArrayList<>();
for (int i = 0; i < 3; i++) {
    putEventsRequestEntryList.add(requestEntry);
}

PutEventsRequest putEventsRequest = new PutEventsRequest();
putEventsRequest.withEntries(putEventsRequestEntryList);
PutEventsResult putEventsResult = awsEventsClient.putEvents(putEventsRequest);

while (putEventsResult.getFailedEntryCount() > 0) {
    final List<PutEventsRequestEntry> failedEntriesList = new ArrayList<>();
    final List<PutEventsResultEntry> PutEventsResultEntryList = putEventsResult.getEntries();
    for (int i = 0; i < PutEventsResultEntryList.size(); i++) {
        final PutEventsRequestEntry putEventsRequestEntry = putEventsRequestEntryList.get(i);
        final PutEventsResultEntry putEventsResultEntry = PutEventsResultEntryList.get(i);
        if (putEventsResultEntry.getErrorCode() != null) {
            failedEntriesList.add(putEventsRequestEntry);
        }
    }
    putEventsRequestEntryList = failedEntriesList;
    putEventsRequest.setEntries(putEventsRequestEntryList);
    putEventsResult = awsEventsClient.putEvents(putEventsRequest);
    }
```

## Sending events using the AWS CLI
<a name="eb-send-events-aws-cli"></a>

You can use the AWS CLI to send custom events to EventBridge so they can be processed. The following example puts one custom event into EventBridge:

```
aws events put-events \
--entries '[{"Time": "2016-01-14T01:02:03Z", "Source": "com.mycompany.myapp", "Resources": ["resource1", "resource2"], "DetailType": "myDetailType", "Detail": "{ \"key1\": \"value1\", \"key2\": \"value2\" }"}]'
```

You can also create a JSON file that contains custom events.

```
[
  {
    "Time": "2016-01-14T01:02:03Z",
    "Source": "com.mycompany.myapp",
    "Resources": [
      "resource1",
      "resource2"
    ],
    "DetailType": "myDetailType",
    "Detail": "{ \"key1\": \"value1\", \"key2\": \"value2\" }"
  }
]
```

Then, to use the AWS CLI to read the entries from this file and send events, at a command prompt, type:

```
aws events put-events --entries file://entries.json
```

## Calculating PutEvents event entry size
<a name="eb-putevent-size"></a>

When you send custom events to EventBridge using the `PutEvents` action, you can batch up to 10 event entries into one request for efficiency. The total request size—that is, the sum of all event entries in the request—must be less than 1 MB (1,048,576 bytes). This limit applies to the request as a whole, not to individual entries. A single event can use up to the full 1 MB if it is the only entry in the request. You can calculate the entry size before you send the events.



**Note**  
The size limit is imposed on the *entry*. Even if the entry is less than the size limit, the *event* in EventBridge is always larger than the entry size due to the necessary characters and keys of the JSON representation of the event. For more information, see [Events in Amazon EventBridge](eb-events.md).

EventBridge calculates the `PutEventsRequestEntry` size as follows:
+ If specified, the `Time` parameter is 14 bytes.
+ The `Source` and `DetailType` parameters are the number of bytes for their UTF-8 encoded forms.
+ If specified, the `Detail` parameter is the number of bytes for its UTF-8 encoded form.
+ If specified, each entry of the `Resources` parameter is the number of bytes for its UTF-8 encoded forms.

The following example Java code calculates the size of a given `PutEventsRequestEntry` object. In order to verify the 1MB limit is not violated, you need to perform the calculation for all events in a request.

```
int getSize(PutEventsRequestEntry entry) {
    int size = 0;
    if (entry.getTime() != null) {
        size += 14;
    }
    size += entry.getSource().getBytes(StandardCharsets.UTF_8).length;
    size += entry.getDetailType().getBytes(StandardCharsets.UTF_8).length;
    if (entry.getDetail() != null) {
        size += entry.getDetail().getBytes(StandardCharsets.UTF_8).length;
    }
    if (entry.getResources() != null) {
        for (String resource : entry.getResources()) {
            if (resource != null) {
                size += resource.getBytes(StandardCharsets.UTF_8).length;
            }
        }
    }
    return size;
}
```

**Note**  
If the entry size is larger than 1 MB (1,048,576 bytes), we recommend uploading the event to an Amazon S3 bucket and including the `Object URL` in the `PutEvents` entry.

# How EventBridge retries delivering events
<a name="eb-rule-retry-policy"></a>

Sometimes an [event](eb-events.md) isn't successfully delivered to the [target](eb-targets.md) specified in a [rule](eb-rules.md). This can happen, for example:
+ If the target resource is unavailable
+ Due to network conditions

When an event isn't successfully delivered to a target because of retriable errors, EventBridge retries sending the event. You set the length of time it tries, and number of retry attempts in the **Retry policy** settings for the target. By default, EventBridge retries sending the event for 24 hours and up to 185 times with an [exponential back off and *jitter*](https://aws.amazon.com/blogs/architecture/exponential-backoff-and-jitter/), or randomized delay.

If an event isn't delivered after all retry attempts are exhausted, the event is dropped and EventBridge doesn't continue to process it.

To avoid losing events after they fail to be delivered to a target, configure a dead-letter queue (DLQ) to receive all failed events. For more information, see [Using dead-letter queues to process undelivered events in EventBridge](eb-rule-dlq.md).

# Using dead-letter queues to process undelivered events in EventBridge
<a name="eb-rule-dlq"></a>

To avoid losing events after they fail to be delivered to a target, you can configure a dead-letter queue (DLQ) and send all failed events to it for processing later.

EventBridge DLQs are standard Amazon SQS queues that EventBridge uses to store events that couldn't successfully be delivered to a target. When you create a rule and add a target, you can choose whether or not to use a DLQ. When you configure a DLQ, you can retain any events that weren't successfully delivered. Then you can resolve the issue that resulted in the failed event delivery and process the events at a later time.

When you configure a DLQ for a target of a rule, EventBridge sends the events with failed invocations to the Amazon SQS queue selected. 

Event errors are handled in different ways. Some events are dropped or sent to a DLQ without any retry attempts. For example, for errors that result from missing permissions to a target, a target resource that no longer exists, or a target that cannot be found due to an invalid address or DNS lookup failure, no retry attempts will happen until action is taken to resolve the underlying issue. EventBridge sends these events directly to the target DLQ, if you have specified one.

When an event delivery fails, EventBridge publishes an event to Amazon CloudWatch metrics indicating that a target `invocation` failed. If you use a DLQ, additional metrics are sent to CloudWatch including `InvocationsSentToDLQ` and `InvocationsFailedToBeSentToDLQ`. 

You can also specify DLQs for event buses, if you use AWS KMS customer managed keys to encrypt events at rest. For more information, see [Using dead-letter queues to capture encrypted event errors in EventBridge](eb-encryption-event-bus-dlq.md).

Each message in your DLQ will include the following custom attributes:
+ `RULE_ARN`
+ `TARGET_ARN`
+ `ERROR_CODE`

  The following is a sample of the error codes a DLQ can return:
  + `ACTION_DECRYPTION_FAILURE`
  + `CONNECTION_FAILURE`
  + `CROSS_ACCOUNT_INGESTION_FAILED`
  + `CROSS_REGION_INGESTION_FAILED`
  + `ERROR_FROM_TARGET`
  + `EVENT_DECRYPTION_FAILURE`
  + `EVENT_ENCRYPTION_FAILURE`
  + `EVENTS_IN_BATCH_REQUEST_REJECTED`
  + `FAILED_TO_ASSUME_ROLE`
  + `INTERNAL_ERROR`
  + `INVALID_JSON`
  + `INVALID_PARAMETER`
  + `NO_PERMISSIONS`
  + `NO_RESOURCE`
  + `RESOURCE_ALREADY_EXISTS`
  + `RESOURCE_LIMIT_EXCEEDED`
  + `RESOURCE_MODIFICATION_COLLISION`
  + `RULE_DECRYPTION_FAILURE`
  + `SDK_CLIENT_ERROR`
  + `THIRD_ACCOUNT_HOP_DETECTED`
  + `THIRD_REGION_HOP_DETECTED`
  + `THROTTLING`
  + `TIMEOUT`
  + `TRANSIENT_ASSUME_ROLE`
  + `UNKNOWN`
+ `ERROR_MESSAGE`
+ `EXHAUSTED_RETRY_CONDITION`

  The following conditions can be returned:
  + `MaximumRetryAttempts`
  + `MaximumEventAgeInSeconds`
+ `RETRY_ATTEMPTS`

 The following video goes over setting up DLQs:




**Topics**
+ [Considerations for using a dead-letter queue](#eb-dlq-considerations)
+ [Granting permissions to the dead-letter queue](#eb-dlq-perms)
+ [How to resend events from a dead-letter queue](#eb-dlq-resend)

## Considerations for using a dead-letter queue
<a name="eb-dlq-considerations"></a>

Consider the following when configuring a DLQ for EventBridge.
+ Only [standard queues](https://docs.aws.amazon.com//AWSSimpleQueueService/latest/SQSDeveloperGuide/standard-queues.html) are supported. You can't use a FIFO queue for a DLQ in EventBridge.
+ EventBridge includes event metadata and message attributes in the message, including: the Error Code, Error Message, the Exhausted Retry Condition, Rule ARN, Retry Attempts, and the Target ARN. You can use these values to identify an event and the cause of the failure.
+ Permissions for DLQs in the same account:
  + If you add a target to a rule using the console, and you choose an Amazon SQS queue in the same account, a [resource-based policy](eb-use-resource-based.md) that grants EventBridge access to the queue is attached to the queue for you.
  + If you use the `PutTargets` operation of the EventBridge API to add or update a target for a rule, and you choose an Amazon SQS queue in the same account, you must manually grant permissions to the queue selected. To learn more, see [Granting permissions to the dead-letter queue](#eb-dlq-perms).
+ Permissions for using Amazon SQS queues from a different AWS account.
  + If you create a rule from the console, queues from other accounts aren't displayed for you to select. You must provide the ARN for the queue in the other account, and then manually attach a resource-based policy to grant permission to the queue. To learn more, see [Granting permissions to the dead-letter queue](#eb-dlq-perms).
  + If you create a rule using the API, you must manually attach a resource-based policy to the SQS queues in another account that is used as the dead-letter queue. To learn more, see [Granting permissions to the dead-letter queue](#eb-dlq-perms).
+ The Amazon SQS queue you use must be in the same Region in which you create the rule.

## Granting permissions to the dead-letter queue
<a name="eb-dlq-perms"></a>

To successfully deliver events to the queue, EventBridge must have permission to do so. When you specify a DLQ using the EventBridge console, the permissions are automatically added. This includes:
+ When you configure a DLQ for a target of a rule.
+ When you configure a DLQ for an event bus where you've specified that EventBridge use an AWS KMS customer managed key to encrypt events at rest. 

  For more information, see [Using dead-letter queues to capture encrypted event errors in EventBridge](eb-encryption-event-bus-dlq.md).

 If you specify a DLQ using the API, or use a queue that is in a different AWS account, you must manually create a resource-based policy that grants the required permissions and then attach it to the queue.

**Target dead-letter queue permissions example**

The following resource-based policy demonstrates how to grant the required permissions for EventBridge to send event messages to an Amazon SQS queue. The policy example grants the EventBridge service permissions to use the `SendMessage` operation to send messages to a queue named "MyEventDLQ". The queue must be in the us-west-2 Region in AWS account 123456789012. The `Condition` statement allows only requests that come from a rule named "MyTestRule" that is created in the us-west-2 Region in the AWS account 123456789012.

```
{
  "Sid": "Dead-letter queue permissions",
  "Effect": "Allow",
  "Principal": {
     "Service": "events.amazonaws.com"
  },
  "Action": "sqs:SendMessage",
  "Resource": "arn:aws:sqs:us-west-2:123456789012:MyEventDLQ",
  "Condition": {
    "ArnEquals": {
      "aws:SourceArn": "arn:aws:events:us-west-2:123456789012:rule/MyTestRule"
    }
  }
}
```

**Event bus dead-letter queue permissions example**

The following resource-based policy demonstrates how to grant the required permissions when specifying a DLQ for an event bus. In this case, `aws:SourceArn` specifies the ARN of the event bus sending the events to the DLQ. Here again in this example, the queue must be in the same Region as the event bus.

```
{
  "Sid": "Dead-letter queue permissions",
  "Effect": "Allow",
  "Principal": {
     "Service": "events.amazonaws.com"
  },
  "Action": "sqs:SendMessage",
  "Resource": "arn:aws:sqs:region:account-id:queue-name",
  "Condition": {
    "ArnEquals": {
      "aws:SourceArn": "arn:aws:events:region:account-id:event-bus/event-bus-arn"
    }
  }
}
```

To attach the policy to the queue, use the Amazon SQS console, open the queue, then choose the **Access policy** and edit the policy. You can also use the AWS CLI. To learn more, see [Amazon SQS permissions](eb-use-resource-based.md#eb-sqs-permissions).

## How to resend events from a dead-letter queue
<a name="eb-dlq-resend"></a>

You can move messages out of a DLQ in two ways:
+ Avoid writing Amazon SQS consumer logic – Set your DLQ as an event source to the Lambda function to drain your DLQ.
+ Write Amazon SQS consumer logic – Use the Amazon SQS API, AWS SDK, or AWS CLI to write custom consumer logic for polling, processing, and deleting the messages in the DLQ.

# AWS service events delivered via AWS CloudTrail
<a name="eb-service-event-cloudtrail"></a>

 AWS CloudTrail is a service that automatically records events such as AWS API calls. You can create EventBridge rules that use the information from CloudTrail. For more information about CloudTrail, see [What is AWS CloudTrail?](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html).

CloudTrail sends the following types of events to the default EventBridge event bus. In each case, the `detail-type` value of the event is the listed event type:
+ `AWS API Call via CloudTrail`

  Events that represent a request to a public AWS service API.

  For more information, see [Understanding CloudTrail events](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-events.html) in the *AWS CloudTrail User Guide*.
+ `AWS Console Signin via CloudTrail`

  Attempts to sign in to the AWS Management Console, the AWS Discussion Forums, and the AWS Support Center. 

  For more information, see [AWS Management Console sign-in events](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-event-reference-aws-console-sign-in-events.html) in the *AWS CloudTrail User Guide*.
+ `AWS Console Action via CloudTrail`

  Actions that were taken in the console that were not an API calls.

  For more information, see [AWS Management Console sign-in events](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-event-reference-aws-console-sign-in-events.html) in the *AWS CloudTrail User Guide*.
+ `AWS Service Event via CloudTrail`

  Events created by AWS services but are not directly triggered by a request to a public AWS service API.

  For more information, see [AWS service events](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/non-api-aws-service-events.html) in the *AWS CloudTrail User Guide*.
+ `AWS Insight via CloudTrail`

  Insights events are triggered by CloudTrail when customer enables the CloudTrail Insight feature.

  For more information, see [CloudTrail Insights](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-event-reference-insight-details.html) in the *AWS CloudTrail User Guide*.

To record events with one of the CloudTrail `detail-type` values, you must enable a CloudTrail trail with logging. For more information, see [Working with CloudTrail trails](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-trails.html) in the *AWS CloudTrail User Guide*.

Some occurrences in AWS services can be reported to EventBridge both by the service itself and by CloudTrail. For example, an Amazon EC2 API call that starts an instance generates multiple events:
+ `EC2 Instance State-change Notification` events sent directly from Amazon EC2 to EventBridge, as the instance enters the `pending` and then `running` states. For example:

  ```
  {
      . . . 
     "detail-type":"EC2 Instance State-change Notification",
     "source":"aws.ec2",
      . . . 
     "detail":{
        "instance-id":"i-abcd1111",
        "state":"pending"
     }
  }
  ```
+ An `AWS API Call via CloudTrail` event sent from CloudTrail to EventBridge that represents the API call itself. For example:

  ```
  {
      . . . 
     "detail-type":"AWS API Call via CloudTrail",
     "source":"aws.ec2",
      . . . 
     ],
    "detail": {
      "eventSource": "ec2.amazonaws.com",
      "eventName": "StartInstances"
      }
  }
  ```

**Note**  
If you use a `Put*Events` API call event as the basis for creating an event pattern, make sure the final event pattern does not exceed 1 MB. The maximum size of any `Put*Events` requests is 1 MB. For more information, see [](eb-putevents.md).

For more information about the services that CloudTrail supports, see [CloudTrail supported services and integrations](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-aws-service-specific-topics.html) in the *CloudTrail User Guide*.

# Receiving read-only management events from AWS services
<a name="eb-service-event-cloudtrail-management"></a>

You can set up rules on your default or custom event bus to receive read-only *management events* from AWS services via CloudTrail. Management events provide visibility into management operations that are performed on resources in your AWS account. These are also known as control plane operations. For more information, see [Logging management events](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/logging-management-events-with-cloudtrail.html#logging-management-events) in the *CloudTrail User Guide*.

For each rule on the default or custom event buses, you can set the rule state to control the types of events to receive:
+ Disable the rule so that EventBridge does not match events against the rule.
+ Enable the rule so that EventBridge matches events against the rule, except for read-only AWS management events delivered through CloudTrail.
+ Enable the rule so that EventBridge matches all events against the rule, *including* read-only management events delivered through CloudTrail.

Partner event buses do not receive AWS events.

Some things to consider when deciding whether to receive read-only management events:
+ Certain read-only management events, such as AWS Key Management Service `GetKeyPolicy` and `DescribeKey`, or IAM `GetPolicy` and `GetRole` events, occur at a much higher volume than typical change events. 
+ You may already be receiving read-only management events even if those events don't start with `Describe`, `Get`, or `List`. One such example is `TestEventPattern` from EventBridge.

  For a list of read-only management events that do not adhere to the `Describe`, `Get`, or `List` naming convention, by AWS services, see [Management events generated by AWS services in EventBridge](eb-service-management-event-list.md).

**To create a rule that receives read-only management events using the AWS CLI**
+ Use the `put-rule` command to create or update the rule, using parameters to:
  + Specify that the rule belongs on the default event bus, or a specific custom event bus
  + Set rule state as `ENABLED_WITH_ALL_CLOUDTRAIL_MANAGEMENT_EVENTS`

  `aws events put-rule --name "ruleForManagementEvents" --event-bus-name "default" --state "ENABLED_WITH_ALL_CLOUDTRAIL_MANAGEMENT_EVENTS"`

**Note**  
Enabling a rule for CloudWatch management events is supported through the AWS CLI and CloudFormation templates only. 

**Example**  
The following example illustrates how to match against specific events. Best practice is to define a dedicated rule for matching specific events, for clarity and ease of editing.   
In this case, the dedicated rule matches the `AssumeRole` management event from AWS Security Token Service.   

```
{
    "source" : [ "aws.sts" ],
    "detail-type": ["AWS API Call via CloudTrail"],
    "detail" : {
        "eventName" : ["AssumeRole"]
    }
}
```

# Management events generated by AWS services in EventBridge
<a name="eb-service-management-event-list"></a>

In general, APIs that generate management (or read-only) events start with the verbs `Describe`, `Get`, or `List`. The table below list AWS services and the management events they generate that do not follow this naming convention. For more information on management events, see [Receiving read-only management events from AWS services](eb-service-event-cloudtrail-management.md).

## Management events that don't start with `Describe`, `Get`, or `List`
<a name="eb-service-management-table-list"></a>

The following table list AWS services and the management events they generate that do not follow typical naming conventions of starting with `Describe`, `Get`, or `List`. 


| Service | Event name | Event type | 
| --- | --- | --- | 
| Alexa for Business | ResolveRoom | API call | 
| Alexa for Business | SearchAddressBooks | API call | 
| Alexa for Business | SearchContacts | API call | 
| Alexa for Business | SearchDevices | API call | 
| Alexa for Business | SearchProfiles | API call | 
| Alexa for Business | SearchRooms | API call | 
| Alexa for Business | SearchSkillGroups | API call | 
| Alexa for Business | SearchUsers | API call | 
| IAM Access Analyzer | ValidatePolicy | API call | 
| AWS AdSpace Clean Rooms | BatchGetSchema | API call | 
| AWS Amplify UI Builder | ExportComponents | API call | 
| AWS Amplify UI Builder | ExportForms | API call | 
| AWS Amplify UI Builder | ExportThemes | API call | 
| Amazon OpenSearch Service | BatchGetCollection | API call | 
| Amazon API Gateway | ExportApi | API call | 
| AWS AppConfig | ValidateConfiguration | API call | 
| Amazon AppFlow | RetrieveConnectorData | API call | 
| Amazon CloudWatch Application Insights | UpdateApplicationDashboardConfiguration | API call | 
| Amazon Athena | BatchGetNamedQuery | API call | 
| Amazon Athena | BatchGetPreparedStatement | API call | 
| Amazon Athena | BatchGetQueryExecution | API call | 
| Amazon Athena | CheckQueryCompatibility | API call | 
| Amazon Athena | ExportNotebook | API call | 
| AWS Auto Scaling | AreScalableTargetsRegistered | API call | 
| AWS Auto Scaling | Test | API call | 
| AWS Marketplace | SearchAgreements | API call | 
| AWS Backup | CreateLegalHold | API call | 
| AWS Backup | ExportBackupPlanTemplate | API call | 
| AWS Backup gateway | TestHypervisorConfiguration | API call | 
| AWS Billing and Cost Management | AWSPaymentInstrumentGateway.Get | Console action | 
| AWS Billing and Cost Management | AWSPaymentPortalService.DescribeMakePaymentPage | Console action | 
| AWS Billing and Cost Management | AWSPaymentPortalService.DescribePaymentsDashboard | Console action | 
| AWS Billing and Cost Management | AWSPaymentPortalService.GetAccountPreferences | Console action | 
| AWS Billing and Cost Management | AWSPaymentPortalService.GetAdvancePaySummary | Console action | 
| AWS Billing and Cost Management | AWSPaymentPortalService.GetAsoBulkDownload | Console action | 
| AWS Billing and Cost Management | AWSPaymentPortalService.GetBillingContactAddress | Console action | 
| AWS Billing and Cost Management | AWSPaymentPortalService.GetDocuments | Console action | 
| AWS Billing and Cost Management | AWSPaymentPortalService.GetEligiblePaymentInstruments | Console action | 
| AWS Billing and Cost Management | AWSPaymentPortalService.GetEntitiesByIds | Console action | 
| AWS Billing and Cost Management | AWSPaymentPortalService.GetFundingDocuments | Console action | 
| AWS Billing and Cost Management | AWSPaymentPortalService.GetKybcValidationStatus | Console action | 
| AWS Billing and Cost Management | AWSPaymentPortalService.GetOneTimePasswordStatus | Console action | 
| AWS Billing and Cost Management | AWSPaymentPortalService.GetPaymentHistory | Console action | 
| AWS Billing and Cost Management | AWSPaymentPortalService.GetPaymentProfileByArn | Console action | 
| AWS Billing and Cost Management | AWSPaymentPortalService.GetPaymentProfileCurrencies | Console action | 
| AWS Billing and Cost Management | AWSPaymentPortalService.GetPaymentProfiles | Console action | 
| AWS Billing and Cost Management | AWSPaymentPortalService.GetPaymentProfileServiceProviders | Console action | 
| AWS Billing and Cost Management | AWSPaymentPortalService.GetPaymentsDue | Console action | 
| AWS Billing and Cost Management | AWSPaymentPortalService.GetRemittanceInformation | Console action | 
| AWS Billing and Cost Management | AWSPaymentPortalService.GetTaxInvoiceMetadata | Console action | 
| AWS Billing and Cost Management | AWSPaymentPortalService.GetTermsAndConditionsForProgramGroup | Console action | 
| AWS Billing and Cost Management | AWSPaymentPortalService.GetTransactionsHistory | Console action | 
| AWS Billing and Cost Management | AWSPaymentPortalService.GetUnappliedFunds | Console action | 
| AWS Billing and Cost Management | AWSPaymentPortalService.GetUnpaidInvoices | Console action | 
| AWS Billing and Cost Management | AWSPaymentPreferenceGateway.Get | Console action | 
| AWS Billing and Cost Management | CancelBulkDownload | Console action | 
| AWS Billing and Cost Management | DownloadCommercialInvoice | Console action | 
| AWS Billing and Cost Management | DownloadCsv | Console action | 
| AWS Billing and Cost Management | DownloadDoc | Console action | 
| AWS Billing and Cost Management | DownloadECSVForBillingPeriod | Console action | 
| AWS Billing and Cost Management | DownloadPaymentHistory | Console action | 
| AWS Billing and Cost Management | DownloadRegistrationDocument | Console action | 
| AWS Billing and Cost Management | DownloadTaxInvoice | Console action | 
| AWS Billing and Cost Management | FindBankRedirectPaymentInstruments | Console action | 
| AWS Billing and Cost Management | FindECSVForBillingPeriod | Console action | 
| AWS Billing and Cost Management | ValidateReportDestination | Console action | 
| AWS Billing and Cost Management | VerifyChinaPaymentEligibility | Console action | 
| Amazon Braket | SearchCompilations | API call | 
| Amazon Braket | SearchDevices | API call | 
| Amazon Braket | SearchQuantumTasks | API call | 
| Amazon Connect Cases | BatchGetField | API call | 
| Amazon Connect Cases | SearchCases | API call | 
| Amazon Connect Cases | SearchRelatedItems | API call | 
| Amazon Chime | RetrieveDataExports | API call | 
| Amazon Chime | SearchChannels | API call | 
| Amazon Chime SDK Identity | DeleteProfile | Service event | 
| Amazon Chime SDK Identity | DeleteWorkTalkAccount | Service event | 
| AWS Clean Rooms | BatchGetSchema | API call | 
| Amazon Cloud Directory | BatchRead | API call | 
| Amazon Cloud Directory | LookupPolicy | API call | 
| CloudFormation | DetectStackDrift | API call | 
| CloudFormation | DetectStackResourceDrift | API call | 
| CloudFormation | DetectStackSetDrift | API call | 
| CloudFormation | EstimateTemplateCost | API call | 
| CloudFormation | ValidateTemplate | API call | 
| AWS CloudShell | RedeemCode | API call | 
| AWS CloudTrail | LookupEvents | API call | 
| AWS CodeArtifact | ReadFromRepository | API call | 
| AWS CodeArtifact | SearchPackages | API call | 
| AWS CodeArtifact | VerifyResourcesExistForTagris | API call | 
| AWS CodeBuild | BatchGetBuildBatches | API call | 
| AWS CodeBuild | BatchGetBuilds | API call | 
| AWS CodeBuild | BatchGetProjects | API call | 
| AWS CodeBuild | BatchGetReportGroups | API call | 
| AWS CodeBuild | BatchGetReports | API call | 
| AWS CodeBuild | BatchPutCodeCoverages | API call | 
| AWS CodeBuild | BatchPutTestCases | API call | 
| AWS CodeBuild | RequestBadge | Service event | 
| AWS CodeCommit | BatchDescribeMergeConflicts | API call | 
| AWS CodeCommit | BatchGetCommits | API call | 
| AWS CodeCommit | BatchGetPullRequests | API call | 
| AWS CodeCommit | BatchGetRepositories | API call | 
| AWS CodeCommit | EvaluatePullRequestApprovalRules | API call | 
| AWS CodeCommit | GitPull | API call | 
| AWS CodeDeploy | BatchGetApplicationRevisions | API call | 
| AWS CodeDeploy | BatchGetApplications | API call | 
| AWS CodeDeploy | BatchGetDeploymentGroups | API call | 
| AWS CodeDeploy | BatchGetDeploymentInstances | API call | 
| AWS CodeDeploy | BatchGetDeployments | API call | 
| AWS CodeDeploy | BatchGetDeploymentTargets | API call | 
| AWS CodeDeploy | BatchGetOnPremisesInstances | API call | 
| Amazon CodeGuru Profiler | BatchGetFrameMetricData | API call | 
| Amazon CodeGuru Profiler | SubmitFeedback | API call | 
| AWS CodePipeline | PollForJobs | API call | 
| AWS CodePipeline | PollForThirdPartyJobs | API call | 
| CodeConnections | StartAppRegistrationHandshake | API call | 
| CodeConnections | StartOAuthHandshake | API call | 
| CodeConnections | ValidateHostWebhook | API call | 
| Amazon CodeWhisperer | CreateCodeScan | API call | 
| Amazon CodeWhisperer | CreateProfile | API call | 
| Amazon CodeWhisperer | CreateUploadUrl | API call | 
| Amazon CodeWhisperer | GenerateRecommendations | API call | 
| Amazon CodeWhisperer | UpdateProfile | API call | 
| Amazon Cognito Identity | LookupDeveloperIdentity | API call | 
| Amazon Cognito user pools | AdminGetDevice | API call | 
| Amazon Cognito user pools | AdminGetUser | API call | 
| Amazon Cognito user pools | AdminListDevices | API call | 
| Amazon Cognito user pools | AdminListGroupsForUser | API call | 
| Amazon Cognito user pools | AdminListUserAuthEvents | API call | 
| Amazon Cognito user pools | Beta\$1Authorize\$1GET | Service event | 
| Amazon Cognito user pools | Confirm\$1GET | Service event | 
| Amazon Cognito user pools | ConfirmForgotPassword\$1GET | Service event | 
| Amazon Cognito user pools | Error\$1GET | Service event | 
| Amazon Cognito user pools | ForgotPassword\$1GET | Service event | 
| Amazon Cognito user pools | IntrospectToken | API call | 
| Amazon Cognito user pools | Login\$1Error\$1POST | Service event | 
| Amazon Cognito user pools | Login\$1GET | Service event | 
| Amazon Cognito user pools | Mfa\$1GET | Service event | 
| Amazon Cognito user pools | MfaOption\$1GET | Service event | 
| Amazon Cognito user pools | ResetPassword\$1GET | Service event | 
| Amazon Cognito user pools | Signup\$1GET | Service event | 
| Amazon Cognito user pools | UserInfo\$1GET | Service event | 
| Amazon Cognito user pools | UserInfo\$1POST | Service event | 
| Amazon Cognito Sync | BulkPublish | API call | 
| Amazon Comprehend | BatchContainsPiiEntities | API call | 
| Amazon Comprehend | BatchDetectDominantLanguage | API call | 
| Amazon Comprehend | BatchDetectEntities | API call | 
| Amazon Comprehend | BatchDetectKeyPhrases | API call | 
| Amazon Comprehend | BatchDetectPiiEntities | API call | 
| Amazon Comprehend | BatchDetectSentiment | API call | 
| Amazon Comprehend | BatchDetectSyntax | API call | 
| Amazon Comprehend | BatchDetectTargetedSentiment | API call | 
| Amazon Comprehend | ClassifyDocument | API call | 
| Amazon Comprehend | ContainsPiiEntities | API call | 
| Amazon Comprehend | DetectDominantLanguage | API call | 
| Amazon Comprehend | DetectEntities | API call | 
| Amazon Comprehend | DetectKeyPhrases | API call | 
| Amazon Comprehend | DetectPiiEntities | API call | 
| Amazon Comprehend | DetectSentiment | API call | 
| Amazon Comprehend | DetectSyntax | API call | 
| Amazon Comprehend | DetectTargetedSentiment | API call | 
| Amazon Comprehend | DetectToxicContent | API call | 
| AWS Compute Optimizer | ExportAutoScalingGroupRecommendations | API call | 
| AWS Compute Optimizer | ExportEBSVolumeRecommendations | API call | 
| AWS Compute Optimizer | ExportECInstanceRecommendations | API call | 
| AWS Compute Optimizer | ExportECSServiceRecommendations | API call | 
| AWS Compute Optimizer | ExportLambdaFunctionRecommendations | API call | 
| AWS Compute Optimizer | ExportRDSInstanceRecommendations | API call | 
| AWS Config | BatchGetAggregateResourceConfig | API call | 
| AWS Config | BatchGetResourceConfig | API call | 
| AWS Config | SelectAggregateResourceConfig | API call | 
| AWS Config | SelectResourceConfig | API call | 
| Amazon Connect | AdminGetEmergencyAccessToken | API call | 
| Amazon Connect | SearchQueues | API call | 
| Amazon Connect | SearchRoutingProfiles | API call | 
| Amazon Connect | SearchSecurityProfiles | API call | 
| Amazon Connect | SearchUsers | API call | 
| AWS Glue DataBrew | SendProjectSessionAction | API call | 
| AWS Data Pipeline | EvaluateExpression | API call | 
| AWS Data Pipeline | QueryObjects | API call | 
| AWS Data Pipeline | ValidatePipelineDefinition | API call | 
| AWS DataSync | VerifyResourcesExistForTagris | API call | 
| AWS DeepLens | BatchGetDevice | API call | 
| AWS DeepLens | BatchGetModel | API call | 
| AWS DeepLens | BatchGetProject | API call | 
| AWS DeepLens | CreateDeviceCertificates | API call | 
| AWS DeepRacer | AdminGetAccountConfig | API call | 
| AWS DeepRacer | AdminListAssociatedUsers | API call | 
| AWS DeepRacer | TestRewardFunction | API call | 
| AWS DeepRacer | VerifyResourcesExistForTagris | API call | 
| Amazon Detective | BatchGetGraphMemberDatasources | API call | 
| Amazon Detective | BatchGetMembershipDatasources | API call | 
| Amazon Detective | SearchGraph | API call | 
| Amazon DevOps Guru | SearchInsights | API call | 
| Amazon DevOps Guru | SearchOrganizationInsights | API call | 
| AWS Database Migration Service | BatchStartRecommendations | API call | 
| AWS Database Migration Service | ModifyRecommendation | API call | 
| AWS Database Migration Service | StartRecommendations | API call | 
| AWS Database Migration Service | VerifyResourcesExistForTagris | API call | 
| AWS Directory Service | VerifyTrust | API call | 
| Amazon Elastic Compute Cloud | ConfirmProductInstance | API call | 
| Amazon Elastic Compute Cloud | ReportInstanceStatus | API call | 
| Amazon Elastic Container Registry | BatchCheckLayerAvailability | API call | 
| Amazon Elastic Container Registry | BatchGetImage | API call | 
| Amazon Elastic Container Registry | BatchGetImageReferrer | API call | 
| Amazon Elastic Container Registry | BatchGetRepositoryScanningConfiguration | API call | 
| Amazon Elastic Container Registry | DryRunEvent | Service event | 
| Amazon Elastic Container Registry | PolicyExecutionEvent | Service event | 
| Amazon Elastic Container Registry Public | BatchCheckLayerAvailability | API call | 
| Amazon Elastic Container Service | DiscoverPollEndpoint | API call | 
| Amazon Elastic Container Service | FindSubfleetRoute | API call | 
| Amazon Elastic Container Service | ValidateResources | API call | 
| Amazon Elastic Container Service | VerifyTaskSetsExist | API call | 
| Amazon Elastic Kubernetes Service | AccessKubernetesApi | API call | 
| AWS Elastic Beanstalk | CheckDNSAvailability | API call | 
| AWS Elastic Beanstalk | RequestEnvironmentInfo | API call | 
| AWS Elastic Beanstalk | RetrieveEnvironmentInfo | API call | 
| AWS Elastic Beanstalk | ValidateConfigurationSettings | API call | 
| Amazon Elastic File System | NewClientConnection | Service event | 
| Amazon Elastic File System | UpdateClientConnection | Service event | 
| Amazon Elastic Transcoder | ReadJob | API call | 
| Amazon Elastic Transcoder | ReadPipeline | API call | 
| Amazon Elastic Transcoder | ReadPreset | API call | 
| Amazon EventBridge | TestEventPattern | API call | 
| Amazon EventBridge | TestScheduleExpression | API call | 
| Amazon FinSpace API | BatchListCatalogNodesByDataset | API call | 
| Amazon FinSpace API | BatchListNodesByDataset | API call | 
| Amazon FinSpace API | BatchValidateAccess | API call | 
| Amazon FinSpace API | CreateAuditRecordsQuery | API call | 
| Amazon FinSpace API | SearchDatasets | API call | 
| Amazon FinSpace API | SearchDatasetsV | API call | 
| Amazon FinSpace API | ValidateIdToken | API call | 
| AWS Firewall Manager | DisassociateAdminAccount | API call | 
| Amazon Forecast | InvokeForecastEndpoint | API call | 
| Amazon Forecast | QueryFeature | API call | 
| Amazon Forecast | QueryForecast | API call | 
| Amazon Forecast | QueryWhatIfForecast | API call | 
| Amazon Forecast | VerifyResourcesExistForTagris | API call | 
| Amazon Fraud Detector | BatchGetVariable | API call | 
| Amazon Fraud Detector | VerifyResourcesExistForTagris | API call | 
| FreeRTOS | VerifyEmailAddress | API call | 
| Amazon GameLift Servers | RequestUploadCredentials | API call | 
| Amazon GameLift Servers | ResolveAlias | API call | 
| Amazon GameLift Servers | SearchGameSessions | API call | 
| Amazon GameLift Servers | ValidateMatchmakingRuleSet | API call | 
| Amazon GameSparks | ExportSnapshot | API call | 
| Amazon Location Service | BatchGetDevicePosition | API call | 
| Amazon Location Service | CalculateRoute | API call | 
| Amazon Location Service | CalculateRouteMatrix | API call | 
| Amazon Location Service | SearchPlaceIndexForPosition | API call | 
| Amazon Location Service | SearchPlaceIndexForSuggestions | API call | 
| Amazon Location Service | SearchPlaceIndexForText | API call | 
| Amazon Glacier | InitiateJob | API call | 
| AWS Glue | BatchGetBlueprints | API call | 
| AWS Glue | BatchGetColumnStatisticsForTable | API call | 
| AWS Glue | BatchGetCrawlers | API call | 
| AWS Glue | BatchGetCustomEntityTypes | API call | 
| AWS Glue | BatchGetDataQualityResult | API call | 
| AWS Glue | BatchGetDevEndpoints | API call | 
| AWS Glue | BatchGetJobs | API call | 
| AWS Glue | BatchGetMLTransform | API call | 
| AWS Glue | BatchGetPartition | API call | 
| AWS Glue | BatchGetTriggers | API call | 
| AWS Glue | BatchGetWorkflows | API call | 
| AWS Glue | QueryJobRuns | API call | 
| AWS Glue | QueryJobRunsAggregated | API call | 
| AWS Glue | QueryJobs | API call | 
| AWS Glue | QuerySchemaVersionMetadata | API call | 
| AWS Glue | SearchTables | API call | 
| AWS HealthLake | ReadResource | API call | 
| AWS HealthLake | SearchWithGet | API call | 
| AWS HealthLake | SearchWithPost | API call | 
| AWS Identity and Access Management | GenerateCredentialReport | API call | 
| AWS Identity and Access Management | GenerateOrganizationsAccessReport | API call | 
| AWS Identity and Access Management | GenerateServiceLastAccessedDetails | API call | 
| AWS Identity and Access Management | SimulateCustomPolicy | API call | 
| AWS Identity and Access Management | SimulatePrincipalPolicy | API call | 
| AWS Identity Store | IsMemberInGroups | API call | 
| AWS Identity Store Auth | BatchGetSession | API call | 
| Amazon Inspector Classic | PreviewAgents | API call | 
| Amazon Inspector Classic | BatchGetAccountStatus | API call | 
| Amazon Inspector Classic | BatchGetFreeTrialInfo | API call | 
| Amazon Inspector Classic | BatchGetMember | API call | 
| AWS Invoicing | ValidateDocumentDeliveryS3LocationInfo | API call | 
| AWS IoT | SearchIndex | API call | 
| AWS IoT | TestAuthorization | API call | 
| AWS IoT | TestInvokeAuthorizer | API call | 
| AWS IoT | ValidateSecurityProfileBehaviors | API call | 
| AWS IoT Analytics | SampleChannelData | API call | 
| AWS IoT SiteWise | GatewaysVerifyResourcesExistForTagrisInternal | API call | 
| AWS IoT Things Graph | SearchEntities | API call | 
| AWS IoT Things Graph | SearchFlowExecutions | API call | 
| AWS IoT Things Graph | SearchFlowTemplates | API call | 
| AWS IoT Things Graph | SearchSystemInstances | API call | 
| AWS IoT Things Graph | SearchSystemTemplates | API call | 
| AWS IoT Things Graph | SearchThings | API call | 
| AWS IoT TwinMaker | ExecuteQuery | API call | 
| AWS IoT Wireless | CreateNetworkAnalyzerConfiguration | API call | 
| AWS IoT Wireless | DeleteNetworkAnalyzerConfiguration | API call | 
| AWS IoT Wireless | DeregisterWirelessDevice | API call | 
| Amazon Interactive Video Service | BatchGetChannel | API call | 
| Amazon Interactive Video Service | BatchGetStreamKey | API call | 
| Amazon Kendra | BatchGetDocumentStatus | API call | 
| Amazon Kendra | Query | API call | 
| Amazon Managed Service for Apache Flink | DiscoverInputSchema | API call | 
| AWS Key Management Service | Decrypt | API call | 
| AWS Key Management Service | Encrypt | API call | 
| AWS Key Management Service | GenerateDataKey | API call | 
| AWS Key Management Service | GenerateDataKeyPair | API call | 
| AWS Key Management Service | GenerateDataKeyPairWithoutPlaintext | API call | 
| AWS Key Management Service | GenerateDataKeyWithoutPlaintext | API call | 
| AWS Key Management Service | GenerateMac | API call | 
| AWS Key Management Service | GenerateRandom | API call | 
| AWS Key Management Service | ReEncrypt | API call | 
| AWS Key Management Service | Sign | API call | 
| AWS Key Management Service | Verify | API call | 
| AWS Key Management Service | VerifyMac | API call | 
| AWS Lake Formation | SearchDatabasesByLFTags | API call | 
| AWS Lake Formation | SearchTablesByLFTags | API call | 
| AWS Lake Formation | StartQueryPlanning | API call | 
| Amazon Lex | BatchCreateCustomVocabularyItem | API call | 
| Amazon Lex | BatchDeleteCustomVocabularyItem | API call | 
| Amazon Lex | BatchUpdateCustomVocabularyItem | API call | 
| Amazon Lex | DeleteCustomVocabulary | API call | 
| Amazon Lex | SearchAssociatedTranscripts | API call | 
| Amazon Lightsail | CreateGUISessionAccessDetails | API call | 
| Amazon Lightsail | DownloadDefaultKeyPair | API call | 
| Amazon Lightsail | IsVpcPeered | API call | 
| Amazon CloudWatch Logs | FilterLogEvents | API call | 
| Amazon Macie | BatchGetCustomDataIdentifiers | API call | 
| Amazon Macie | UpdateFindingsFilter | API call | 
| AWS Elemental MediaConnect | ManagedDescribeFlow | API call | 
| AWS Elemental MediaConnect | PrivateDescribeFlowMeta | API call | 
| AWS Application Migration Service | OperationalDescribeJobLogItems | API call | 
| AWS Application Migration Service | OperationalDescribeJobs | API call | 
| AWS Application Migration Service | OperationalDescribeReplicationConfigurationTemplates | API call | 
| AWS Application Migration Service | OperationalDescribeSourceServer | API call | 
| AWS Application Migration Service | OperationalGetLaunchConfiguration | API call | 
| AWS Application Migration Service | OperationalListSourceServers | API call | 
| AWS Application Migration Service | VerifyClientRoleForMgn | API call | 
| AWS HealthOmics | VerifyResourceExists | API call | 
| AWS HealthOmics | VerifyResourcesExistForTagris | API call | 
| Amazon Polly | SynthesizeLongSpeech | API call | 
| Amazon Polly | SynthesizeSpeech | API call | 
| Amazon Polly | SynthesizeSpeechGet | API call | 
| AWS service providing managed private networks | Ping | API call | 
| AWS Proton | DeleteEnvironmentTemplateVersion | API call | 
| AWS Proton | DeleteServiceTemplateVersion | API call | 
| Amazon QLDB | ShowCatalog | API call | 
| Amazon Quick | GenerateEmbedUrlForAnonymousUser | API call | 
| Amazon Quick | GenerateEmbedUrlForRegisteredUser | API call | 
| Amazon Quick | QueryDatabase | Service event | 
| Amazon Quick | SearchAnalyses | API call | 
| Amazon Quick | SearchDashboards | API call | 
| Amazon Quick | SearchDataSets | API call | 
| Amazon Quick | SearchDataSources | API call | 
| Amazon Quick | SearchFolders | API call | 
| Amazon Quick | SearchGroups | API call | 
| Amazon Quick | SearchUsers | API call | 
| Amazon Relational Database Service | DownloadCompleteDBLogFile | API call | 
| Amazon Relational Database Service | DownloadDBLogFilePortion | API call | 
| Amazon Rekognition | CompareFaces | API call | 
| Amazon Rekognition | DetectCustomLabels | API call | 
| Amazon Rekognition | DetectFaces | API call | 
| Amazon Rekognition | DetectLabels | API call | 
| Amazon Rekognition | DetectModerationLabels | API call | 
| Amazon Rekognition | DetectProtectiveEquipment | API call | 
| Amazon Rekognition | DetectText | API call | 
| Amazon Rekognition | RecognizeCelebrities | API call | 
| Amazon Rekognition | SearchFaces | API call | 
| Amazon Rekognition | SearchFacesByImage | API call | 
| Amazon Rekognition | SearchUsers | API call | 
| Amazon Rekognition | SearchUsersByImage | API call | 
| AWS Resource Explorer | BatchGetView | API call | 
| AWS Resource Explorer | Search | API call | 
| AWS Resource Groups | SearchResources | API call | 
| AWS Resource Groups | ValidateResourceSharing | API call | 
| AWS RoboMaker | BatchDescribeSimulationJob | API call | 
| Amazon Route 53 | TestDNSAnswer | API call | 
| Amazon Route 53 Domains | checkAvailabilities | API call | 
| Amazon Route 53 Domains | CheckDomainAvailability | API call | 
| Amazon Route 53 Domains | checkDomainTransferability | API call | 
| Amazon Route 53 Domains | CheckDomainTransferability | API call | 
| Amazon Route 53 Domains | isEmailReachable | API call | 
| Amazon Route 53 Domains | searchDomains | API call | 
| Amazon Route 53 Domains | sendVerificationMessage | API call | 
| Amazon Route 53 Domains | ViewBilling | API call | 
| Amazon Route 53 Domains | viewBilling | API call | 
| Amazon CloudWatch RUM | BatchGetRumMetricDefinitions | API call | 
| Amazon Simple Storage Service | echo | API call | 
| Amazon Simple Storage Service | GenerateInventory | Service event | 
| Amazon SageMaker AI | BatchDescribeModelPackage | API call | 
| Amazon SageMaker AI | DeleteModelCard | API call | 
| Amazon SageMaker AI | QueryLineage | API call | 
| Amazon SageMaker AI | RenderUiTemplate | API call | 
| Amazon SageMaker AI | Search | API call | 
| Amazon EventBridge Schemas | ExportSchema | API call | 
| Amazon EventBridge Schemas | SearchSchemas | API call | 
| Amazon SimpleDB | DomainMetadata | API call | 
| AWS Secrets Manager | ValidateResourcePolicy | API call | 
| AWS Service Catalog | ScanProvisionedProducts | API call | 
| AWS Service Catalog | SearchProducts | API call | 
| AWS Service Catalog | SearchProductsAsAdmin | API call | 
| AWS Service Catalog | SearchProvisionedProducts | API call | 
| Amazon SES | BatchGetMetricData | API call | 
| Amazon SES | TestRenderEmailTemplate | API call | 
| Amazon SES | TestRenderTemplate | API call | 
| Amazon Simple Notification Service | CheckIfPhoneNumberIsOptedOut | API call | 
| AWS SQL Workbench | BatchGetNotebookCell | API call | 
| AWS SQL Workbench | ExportNotebook | API call | 
| Amazon EC2 Systems Manager | ExecuteApi | API call | 
| AWS Systems Manager Incident Manager | DeleteContactChannel | API call | 
| AWS IAM Identity Center | IsMemberInGroup | API call | 
| AWS IAM Identity Center | SearchGroups | API call | 
| AWS IAM Identity Center | SearchUsers | API call | 
| AWS STS | AssumeRole | API call | 
| AWS STS | AssumeRoleWithSAML | API call | 
| AWS STS | AssumeRoleWithWebIdentity | API call | 
| AWS STS | DecodeAuthorizationMessage | API call | 
| AWS Tax Settings | BatchGetTaxExemptions | API call | 
| AWS WAFV2 | CheckCapacity | API call | 
| AWS WAFV2 | GenerateMobileSdkReleaseUrl | API call | 
| AWS Well-Architected Tool | ExportLens | API call | 
| AWS Well-Architected Tool | TagResource | API call | 
| AWS Well-Architected Tool | UntagResource | API call | 
| AWS Well-Architected Tool | UpdateGlobalSettings | API call | 
| Amazon Connect Wisdom | QueryAssistant | API call | 
| Amazon Connect Wisdom | SearchContent | API call | 
| Amazon Connect Wisdom | SearchSessions | API call | 
| Amazon WorkDocs | AbortDocumentVersionUpload | API call | 
| Amazon WorkDocs | AddUsersToGroup | API call | 
| Amazon WorkDocs | BatchGetUsers | API call | 
| Amazon WorkDocs | CheckAlias | API call | 
| Amazon WorkDocs | CompleteDocumentVersionUpload | API call | 
| Amazon WorkDocs | CreateAnnotation | API call | 
| Amazon WorkDocs | CreateComment | API call | 
| Amazon WorkDocs | CreateFeedbackRequest | API call | 
| Amazon WorkDocs | CreateFolder | API call | 
| Amazon WorkDocs | CreateGroup | API call | 
| Amazon WorkDocs | CreateShare | API call | 
| Amazon WorkDocs | CreateUser | API call | 
| Amazon WorkDocs | DeleteAnnotation | API call | 
| Amazon WorkDocs | DeleteComment | API call | 
| Amazon WorkDocs | DeleteDocument | API call | 
| Amazon WorkDocs | DeleteFeedbackRequest | API call | 
| Amazon WorkDocs | DeleteFolder | API call | 
| Amazon WorkDocs | DeleteFolderContents | API call | 
| Amazon WorkDocs | DeleteGroup | API call | 
| Amazon WorkDocs | DeleteOrganizationShare | API call | 
| Amazon WorkDocs | DeleteUser | API call | 
| Amazon WorkDocs | DownloadDocumentVersion | API call | 
| Amazon WorkDocs | DownloadDocumentVersionUnderlays | API call | 
| Amazon WorkDocs | InitiateDocumentVersionUpload | API call | 
| Amazon WorkDocs | LogoutUser | API call | 
| Amazon WorkDocs | PaginatedOrganizationActivity | API call | 
| Amazon WorkDocs | PublishAnnotations | API call | 
| Amazon WorkDocs | PublishComments | API call | 
| Amazon WorkDocs | RestoreDocument | API call | 
| Amazon WorkDocs | RestoreFolder | API call | 
| Amazon WorkDocs | SearchGroups | API call | 
| Amazon WorkDocs | SearchOrganizationUsers | API call | 
| Amazon WorkDocs | TransferUserResources | API call | 
| Amazon WorkDocs | UpdateAnnotation | API call | 
| Amazon WorkDocs | UpdateComment | API call | 
| Amazon WorkDocs | UpdateDocument | API call | 
| Amazon WorkDocs | UpdateDocumentVersion | API call | 
| Amazon WorkDocs | UpdateFolder | API call | 
| Amazon WorkDocs | UpdateGroup | API call | 
| Amazon WorkDocs | UpdateOrganization | API call | 
| Amazon WorkDocs | UpdateUser | API call | 
| Amazon WorkMail | AssumeImpersonationRole | API call | 
| Amazon WorkMail | QueryDnsRecords | API call | 
| Amazon WorkMail | SearchMembers | API call | 
| Amazon WorkMail | TestAvailabilityConfiguration | API call | 
| Amazon WorkMail | TestInboundMailFlowRules | API call | 
| Amazon WorkMail | TestOutboundMailFlowRules | API call | 

# Amazon EventBridge events detail reference
<a name="event-reference"></a>

EventBridge itself emits the following events. These events are automatically sent to the default event bus as with any other AWS service.

For definitions of the metadata fields that are included in all events, see [AWS service event metadata](https://docs.aws.amazon.com/eventbridge/latest/ref/events-structure.html) in the *Events Reference*.


| Event detail type | Description | 
| --- | --- | 
|   [Scheduled Event](#event-detail-scheduled-event)   |  Represents a scheduled event. | 
|   [Schema Created](#event-detail-schema-created)   |  Represents the creation of a new event schema. | 
|   [Schema Version Created](#event-detail-schema-version-created)   |  Represents the creation of a new version of a new or existing event schema.  | 
|   [Connection state events](#event-detail-connection-state)   |  Represents a change in the state of a connection.  | 
|   [API Destination state events](#event-detail-api-destination-state)   |  Represents a change in the state of an API destination.  | 

## Schedule events
<a name="event-reference-schedules"></a>

EventBridge sends the following schedule events to the default event bus. For more information, see [Scheduler](using-eventbridge-scheduler.md).

### Scheduled Event
<a name="event-detail-scheduled-event"></a>

Represents a scheduled event.

The `source` and `detail-type` fields are included because they contain specific values for EventBridge events. For definitions of the other metadata fields that are included in all events, see [AWS service event metadata](https://docs.aws.amazon.com/eventbridge/latest/ref/events-structure.html) in the *Events Reference*.

```
{
  . . .,
  "detail-type": "Scheduled Event",
  "source": "aws.events",
  . . .,
  "detail": {}
}
```

`detail-type`  <a name="scheduled-event-detail-type"></a>
Identifies the type of event.  
For this event, this value is `Scheduled Event`.  
Required: Yes

`source`  <a name="scheduled-event-source"></a>
Identifies the service that generated the event. For EventBridge events, this value is `aws.events`.  
Required: Yes

`detail`  <a name="scheduled-event-detail"></a>
A JSON object that contains information about the event. The service generating the event determines the content of this field.  
Required: Yes  
There are no required fields in this object for `Scheduled Event` events.

**Example Scheduled Event event**  <a name="event-detail-scheduled-event.example"></a>

```
{
  "version": "0",
  "id": "89d1a02d-5ec7-412e-82f5-13505f849b41",
  "detail-type": "Scheduled Event",
  "source": "aws.events",
  "account": "123456789012",
  "time": "2016-12-30T18:44:49Z",
  "region": "us-east-1",
  "resources": ["arn:aws:events:us-east-1:123456789012:rule/SampleRule"],
  "detail": {}
}
```

## Schema registry events
<a name="event-reference-schemas"></a>

EventBridge sends the following schema registry events to the default event bus. For more information, see [](eb-schema.md).

### Schema Created
<a name="event-detail-schema-created"></a>

Represents the creation of a new schema.

When a schema is created, EventBridge sends both a `Schema Created` and a `Schema Version Created` event.

The `source` and `detail-type` fields are included because they contain specific values for EventBridge events. For definitions of the other metadata fields that are included in all events, see [AWS service event metadata](https://docs.aws.amazon.com/eventbridge/latest/ref/events-structure.html) in the *Events Reference*.

```
{
  . . .,
  "detail-type": "Schema Created",
  "source": "aws.schemas",
  . . .,
  "detail": {
    "SchemaName" : "String",
    "SchemaType" : "String",
    "RegistryName" : "String",
    "CreationDate" : "DateTime",
    "Version" : "Number"
  }
}
```

`detail-type`  <a name="schema-created-detail-type"></a>
Identifies the type of event.  
For this event, this value is `Schema Created`.  
Required: Yes

`source`  <a name="schema-created-source"></a>
Identifies the service that generated the event. For EventBridge events, this value is `aws.schemas`.  
Required: Yes

`detail`  <a name="schema-created-detail"></a>
A JSON object that contains information about the event. The service generating the event determines the content of this field.  
Required: Yes  
For this event, this data includes:    
`SchemaName`  <a name="schema-created-schema-name"></a>
The name of the schema.  
Required: Yes  
`SchemaType`  <a name="schema-created-schema-type"></a>
The type of schema.  
Valid values: `OpenApi3` \$1 `JSONSchemaDraft4`  
Required: Yes  
`RegistryName`  <a name="schema-created-registry-name"></a>
The name of the registry that contains the schema.  
Required: Yes  
`CreationDate`  <a name="schema-created-creation-date"></a>
The date the schema was created.  
Required: Yes  
`Version`  <a name="schema-created-version"></a>
The version of the schema.  
For `Schema Created` events, this value will always be `1`.  
Required: Yes

**Example Schema Created event**  <a name="event-detail-schema-created.example"></a>

```
{
  "version": "0",
  "id": "01234567-0123-0123-0123-012345678901",
  "detail-type": "Schema Created",
  "source": "aws.schemas",
  "account": "123456789012",
  "time": "2019-05-31T21:49:54Z",
  "region": "us-east-1",
  "resources": ["arn:aws:schemas:us-east-1::schema/myRegistry/mySchema"],
  "detail": {
    "SchemaName": "mySchema",
    "SchemaType": "OpenApi3",
    "RegistryName": "myRegistry",
    "CreationDate": "2019-11-29T20:08:55Z",
    "Version": "1"
  }
}
```

### Schema Version Created
<a name="event-detail-schema-version-created"></a>

Represents the creation of a new version of a new or existing event schema.

When a schema is created, EventBridge sends both a `Schema Created` and a `Schema Version Created` event.

The `source` and `detail-type` fields are included because they contain specific values for EventBridge events. For definitions of the other metadata fields that are included in all events, see [AWS service event metadata](https://docs.aws.amazon.com/eventbridge/latest/ref/events-structure.html) in the *Events Reference*.

```
{
  . . .,
  "detail-type": "Schema Version Created",
  "source": "aws.schemas",
  . . .,
  "detail": {
    "SchemaName" : "String",
    "SchemaType" : "String",
    "RegistryName" : "String",
    "CreationDate" : "DateTime",
    "Version" : "Number"
  }
}
```

`detail-type`  <a name="schema-version-created-detail-type"></a>
Identifies the type of event.  
For this event, this value is `Schema Version Created`.  
Required: Yes

`source`  <a name="schema-version-created-source"></a>
Identifies the service that generated the event. For EventBridge events, this value is `aws.schemas`.  
Required: Yes

`detail`  <a name="schema-version-created-detail"></a>
A JSON object that contains information about the event. The service generating the event determines the content of this field.  
Required: Yes  
For this event, this data includes:    
`SchemaName`  <a name="schema-version-created-schema-name"></a>
The name of the schema.  
Required: Yes  
`SchemaType`  <a name="schema-version-created-schema-type"></a>
The type of schema.  
Valid values: `OpenApi3` \$1 `JSONSchemaDraft4`  
Required: Yes  
`RegistryName`  <a name="schema-version-created-registry-name"></a>
The name of the registry that contains the schema.  
Required: Yes  
`CreationDate`  <a name="schema-version-created-creation-date"></a>
The date the schema version was created.  
Required: Yes  
`Version`  <a name="schema-version-created-version"></a>
The version of the schema.  
Required: Yes

**Example Schema Version Created event**  <a name="event-detail-schema-version-created.example"></a>

```
{
  "version": "0",
  "id": "01234567-0123-0123-0123-012345678901",
  "detail-type": "Schema Version Created",
  "source": "aws.schemas",
  "account": "123456789012",
  "time": "2019-05-31T21:49:54Z",
  "region": "us-east-1",
  "resources": ["arn:aws:schemas:us-east-1::schema/myRegistry/mySchema"],
  "detail": {
    "SchemaName": "mySchema",
    "SchemaType": "OpenApi3",
    "RegistryName": "myRegistry",
    "CreationDate": "2019-11-29T20:08:55Z",
    "Version": "5"
  }
}
```

## Connection events
<a name="event-reference-connections"></a>

EventBridge sends the following connection events to the default event bus. For more information, see [Connections](eb-target-connection.md).

### Connection state events
<a name="event-detail-connection-state"></a>

These events each represent a change in the state of a new or existing connection.

The `source` and `detail-type` fields are included because they contain specific values for EventBridge events. For definitions of the other metadata fields that are included in all events, see [AWS service event metadata](https://docs.aws.amazon.com/eventbridge/latest/ref/events-structure.html) in the *Events Reference*.

```
{
  . . .,
  "detail-type": "Connection status",
  "source": "aws.events",
  . . .,
  "detail": {
    "ConnectionName" : "String",
    "StateReason" : "String",
    "Timestamp" : "DateTime"
  }
}
```

`detail-type`  <a name="connection-state-detail-type"></a>
Identifies the type of event.  
For this event, this value is one of the following:   
+ `Connection Creation Started`
+ `Connection Update Started`
+ `Connection Deletion Started`
+ `Connection Activated`
+ `Connection Authorized`
+ `Connection Authorization Started`
+ `Connection Deauthorization Started`
+ `Connection Deauthorized`
+ `Connection Failed Connectivity`
Required: Yes

`source`  <a name="connection-state-source"></a>
Identifies the service that generated the event. For EventBridge events, this value is `aws.events`.  
Required: Yes

`detail`  <a name="connection-state-detail"></a>
A JSON object that contains information about the event. The service generating the event determines the content of this field.  
Required: Yes  
For this event, this data includes:    
`ConnectionName`  <a name="connection-state-connection-name"></a>
The name of the connection.  
Required: Yes  
`StateReason`  <a name="connection-state-state-reason"></a>
The reason the connection state has changed.  
Required: No  
`Timestamp`  <a name="connection-state-timestamp"></a>
The time and date the connection state changed.  
Required: Yes

**Example Connection state event**  <a name="event-detail-connection-state.example"></a>

```
{
    "version": "0",
    "id": "1d7a4ac6-a50a-745f-a331-a0d802f7badb",
    "detail-type": "Connection Creation Started",
    "source": "aws.events",
    "account": "123456789012",
    "time": "2024-10-28T09:08:20Z",
    "region": "us-east-1",
    "resources": [
        "arn:aws:events:us-east-1:123456789012:connection/sample-connection/ee7e4d52-8df0-4bed-a0d5-fa7dea43fcf8"
    ],
    "detail": {
        "ConnectionName": "sample-connection",
        "Timestamp": "2024-10-24 09:26:35 +0000 UTC"
    }
}
```

## API Destination events
<a name="event-reference-api-destinations"></a>

EventBridge sends the following API destination events to the default event bus. For more information, see [API destinations](eb-api-destinations.md).

### API Destination state events
<a name="event-detail-api-destination-state"></a>

These events each represents a change in the state of an API destination.

The `source` and `detail-type` fields are included because they contain specific values for EventBridge events. For definitions of the other metadata fields that are included in all events, see [AWS service event metadata](https://docs.aws.amazon.com/eventbridge/latest/ref/events-structure.html) in the *Events Reference*.

```
{
  . . .,
  "detail-type": "API Destination status",
  "source": "aws.events",
  . . .,
  "detail": {
    "ApiDestinationName" : "String",
    "Timestamp" : "DateTime"
  }
}
```

`detail-type`  <a name="api-destination-state-detail-type"></a>
Identifies the type of event.  
For this event, this value is one of the following:   
+ `API Destination Activated`
+ `API Destination Deactivated`
Required: Yes

`source`  <a name="api-destination-state-source"></a>
Identifies the service that generated the event. For EventBridge events, this value is `aws.events`.  
Required: Yes

`detail`  <a name="api-destination-state-detail"></a>
A JSON object that contains information about the event. The service generating the event determines the content of this field.  
Required: Yes  
For this event, this data includes:    
`ApiDestinationName`  <a name="api-destination-state-connection-name"></a>
The name of the API destination.  
Required: Yes  
`Timestamp`  <a name="api-destination-state-timestamp"></a>
The time and date the API destination state changed.  
Required: Yes

**Example API destination state event**  <a name="event-detail-api-destination-state.example"></a>

```
{
    "version": "0",
    "id": "1d7a4ac6-a50a-745f-a331-a0d802f7badb",
    "detail-type": "API Destination Deactivated",
    "source": "aws.events",
    "account": "123456789012",
    "time": "2024-10-28T09:08:20Z",
    "region": "us-east-1",
    "resources": [
        "arn:aws:events:us-east-1:123456789012:api-destination/sample-api-destination/ee7e4d52-8df0-4bed-a0d5-fa7dea43fcf8"
    ],
    "detail": {
        "ApiDestinationName": "sample-api-destination",
        "Timestamp": "2024-10-24 09:26:35 +0000 UTC"
    }
}
```

# Rules in Amazon EventBridge
<a name="eb-rules"></a>

You specify what EventBridge does with the events delivered to each event bus. To do this, you create *rules*. A rule specifies which events to send to which [targets](eb-targets.md) for processing. A single rule can send an event to multiple targets, which then run in parallel.

You can create two types of rules: rules that match on event data as events are delivered, and rules that run on a defined schedule. In addition, certain AWS services may create and manage rules in your account as well.

## Rules that match on event data
<a name="eb-rules-match"></a>

You can create rules that match against incoming events based on event data criteria (called an *event pattern*). An event pattern defines the event structure and the fields that a rule matches. If an event matches the criteria defined in the event pattern, EventBridge sends it to the target(s) you specify.

EventBridge provides two rule builder modes for creating event-pattern rules in the console:
+ **Enhanced Builder** – A visual canvas for building rules and targets. Drag and drop events and targets to construct your rule without writing JSON directly. For more information, see [Creating rules (Enhanced Builder)](eb-create-rule-visual.md).
+ **Advanced Builder** – JSON patterns and configuration for rules and targets. Provides direct access to the full event pattern syntax and target configuration options. For more information, see [Creating rules (Advanced Builder)](eb-create-rule-wizard.md).

## Rules that run on a schedule
<a name="eb-rules-scheduled"></a>

**Note**  
Scheduled rules are a legacy feature of EventBridge.  
EventBridge offers a more flexible and powerful way to create, run, and manage scheduled tasks centrally, at scale: EventBridge Scheduler. With EventBridge Scheduler, you can create schedules using cron and rate expressions for recurring patterns, or configure one-time invocations. You can set up flexible time windows for delivery, define retry limits, and set the maximum retention time for failed API invocations.   
Scheduler is highly customizable, and offers improved scalability over scheduled rules, with a wider set of target API operations and AWS services. We recommend that you use Scheduler to invoke targets on a schedule.  
For more information, see [Create a schedule](using-eventbridge-scheduler.md#using-eventbridge-scheduler-create) or the *[EventBridge Scheduler User Guide](https://docs.aws.amazon.com/scheduler/latest/UserGuide/what-is-scheduler.html)*.

You can also create rules that sends events to the specified targets at specified intervals. For example, to periodically run an Lambda function, you can create a rule to run on a schedule.

For more information, see [Creating a scheduled rule (legacy) in Amazon EventBridge](eb-create-rule-schedule.md).

## Rules managed by AWS services
<a name="eb-rules-managed"></a>

In addition to the rules you create, AWS services can create and manage EventBridge rules in your AWS account that are needed for certain functions in those services. These are called *managed rules*. 

When a service creates a managed rule, it can also create an [IAM policy](eb-iam.md) that grants permission to that service to create the rule. IAM policies created this way are scoped narrowly with resource-level permissions to allow the creation of only the necessary rules.

You can delete managed rules by using the **Force delete** option, but you should only delete them if you're sure that the other service no longer needs the rule. Otherwise, deleting a managed rule causes the features that rely on it to stop working.

# Creating rules using the Enhanced Builder
<a name="eb-create-rule-visual"></a>

## Prerequisites
<a name="eb-create-rule-prerequisites"></a>

Before you begin, ensure you have:
+ Access to the Amazon EventBridge console
+ Appropriate IAM permissions to create EventBridge rules
+ Basic understanding of event-driven architectures

## Overview
<a name="eb-create-rule-overview"></a>

To take action on events received by EventBridge, you can create rules. When an event matches the event pattern defined in your rule, EventBridge sends the event to the specified target.

This topic walks you through creating a rule that EventBridge uses to match events as they are sent to the specified event bus.

Creating EventBridge rules involves four main steps:

1. Choose the events you want to process

1. Configure event filtering and testing

1. Select and configure targets

1. Configure the rule settings

## Choose the events
<a name="eb-create-rule-source"></a>

First, choose the events you want to send to the target.

**To select an event**

1. Open the Amazon EventBridge console at [https://console.aws.amazon.com/events/](https://console.aws.amazon.com/events/).

1. In the navigation pane, choose **Rules**, and then choose **Create rule**.

1. On the rule builder selection page, choose **Enhanced Builder**.

   The Enhanced Builder provides a visual canvas for building rules and targets by dragging and dropping events and targets. To use JSON patterns and configuration instead, see [Creating rules (Advanced Builder)](eb-create-rule-wizard.md).

1. In the **Events** tab, find the events you want to send to the target:

   1. Choose **AWS Service Events** or **Custom Events**.

   1. Use the Search box or browse the event list to find the events you want to send to the target.

   1. Drag one or more events into the **Build** canvas and drop it on **Triggering Events**.

   EventBridge displays the **Triggering Events** section. This section includes:
   + **Events**, which lists the event you chose.
   + **Schema**, which displays the schema of the selected event, if available.

     **Schema** contains three tabs:
     + **Tree**: A tree view of the event schema.
     + **Code**: The event schema in Open API spec or JSON format.
     + **Info**: Overview information about the schema.
   + **Sample event**, which displays a sample of a selected event, if available.
   + **Event pattern (filter)**, which contains an event pattern that selects all events you've chosen.

## Filter events to send only what you want
<a name="eb-create-rule-event-pattern-visual"></a>

You probably won't want to send *all* events of a specific type to a target. You can make your event pattern more specific so that it only selects events that contain the attributes and values you're interested in.

### Edit the event pattern (optional)
<a name="eb-create-rule-event-pattern-steps"></a>

In the **Triggering events** pane, you can build the event pattern two ways:
+ Visually, using the **Schema** tree view
+ By directly editing the JSON in the **Event pattern** pane

**To edit the event pattern using the Schema tree view**

1. Choose the **Tree** tab of the **Schema** pane.

1. Add and edit filters to build out the event pattern.

   1. Choose the filter icon next to the attribute you want to add as a filter to the event pattern.

   1. Choose a comparison operator from the drop-down list.

      For more information on comparison operators, see [Creating event patterns](eb-create-pattern-operators.md).

   1. Enter the value you want to match.

   1. Click the check mark to finish.

   EventBridge adds the filter you've created to the JSON in the **Event pattern** pane.

1. Add additional filters until you've constructed an event pattern that matches on all the event attributes you want.

### Test the event pattern
<a name="eb-create-rule-event-pattern-test"></a>

After you construct an event pattern that matches all the event attributes you want, test to ensure the event pattern performs as expected.

#### Test the event pattern (optional)
<a name="eb-create-rule-event-pattern-test-steps"></a>

1. Choose a sample event for testing, or use your own.
   + **Use sample events provided**

     1. Choose **Use sample events provided**.

     1. Under **Sample triggering event**, select the event to use for testing from the drop-down list.
   + **Use your own event**

     1. Choose **Use your own event**.

        EventBridge displays a generic event with an empty `details` element.

     1. Edit the event JSON to create the event against which you want to test your event pattern.
**Tip**  
You can use the sample events provided as starting points for creating your own custom events to use in your testing:  
Choose **Use sample events provided**, choose an event from the **Sample triggering event**, and then choose **Copy**.
Choose **Use your own event**.
Select the entire event in the window, and paste the sample event over it.
Edit the event as desired.

1. Choose **Run Test**.

   EventBridge displays a message stating whether the test event matches the event pattern.

## Select targets
<a name="eb-create-rule-target-visual"></a>

Drag one (and up to five) targets into the **Build** canvas and drop it on **Targets** to receive events that match the specified event pattern. Targets can include:
+ Other EventBridge event buses, in the same or a different AWS account
+ EventBridge API destinations, including SaaS partners such as Salesforce
+ A range of AWS service resources, such as Amazon SQS queues or Amazon SNS topics

**To select targets**

1. Select the target type from the **Targets** pane, and drop it onto the **Targets** shape in the Build canvas.

   EventBridge displays the **Target** section in the Build, with the applicable configuration options based on the type of target you selected.
**Tip**  
If you have specified more than one target, selecting the target shape displays the configuration section for that target.

1. Configure the target based on your target type. For detailed configuration steps, see [EventBridge Targets](eb-targets.md).

### Customize the event data sent to the target
<a name="eb-create-rule-target-transform"></a>

If you select a target other than an EventBridge event bus or EventBridge API destination, you have the option of customizing what data actually gets delivered to the target.

#### Transform or replace the event data sent (optional)
<a name="eb-create-rule-target-transform-steps"></a>

1. In the Build design canvas, choose the **Input transformation** icon in the **Targets** shape.

   EventBridge displays the **Input transformation** section.

1. Under **Input transformation configuration**, choose **Enable**.

1. Select the Transformation method to choose how you want to customize the text sent to the target for matching events:
   + **Part of the matched events** – EventBridge only sends the specified portion of the original source event to the target.
   + **Constant (JSON text)** – EventBridge sends only the specified JSON text to the target. No part of the original source event is sent.
   + **Input transformer** – Configure an input transformer to customize the text you want EventBridge to send to the target. For more information, see [Transforming target input](eb-transform-target-input.md).

## Configure the rule
<a name="eb-create-rule-configure"></a>

Finally, configure and create the rule.

**To configure the rule (console)**

1. Choose **Configure**.

1. Enter a **Name** and, optionally, a **Description** for the rule.

   A rule can't have the same name as another rule in the same AWS Region and on the same event bus.

1. For **Event bus**, choose the event bus to associate with this rule.

   If you want this rule to match events that come from your account, select **AWS default event bus**. When an AWS service in your account sends an event, it always goes to your account's default event bus.

1. To enable the rule as soon as it is created, under **Activation** enable **Active**.

1. (Optional) Enter one or more tags for the rule. For more information, see [Tagging resources in Amazon EventBridge](eb-tagging.md).

1. Choose **Create**.

## Next steps
<a name="eb-create-rule-next-steps"></a>

After creating your rule, you can:
+ [Monitor rule performance using metrics](eb-monitoring.md)
+ [Test your rule with sample events](eb-event-pattern-sandbox.md)
+ [Modify event patterns as needed](eb-event-patterns.md)
+ [Add additional targets to existing rules](eb-targets.md)

## Additional resources
<a name="eb-create-rule-additional-resources"></a>

For more information about EventBridge rules, see:
+ [EventBridge rules overview](eb-rules.md)
+ [Creating event patterns](eb-event-patterns.md)
+ [EventBridge targets](eb-targets.md)
+ [Troubleshooting EventBridge rules](eb-troubleshooting.md)

# Creating rules using the Advanced Builder
<a name="eb-create-rule-wizard"></a>

To take action on events received by Amazon EventBridge, you can create [rules](eb-rules.md). When an event matches the [event pattern](eb-event-patterns.md) defined in your rule, EventBridge sends the event to the specified [target](eb-targets.md) and triggers the action defined in the rule.

The following steps walk you through how to create a rule that EventBridge uses to match events as they are sent to the specified event bus.

**Topics**
+ [Define the rule](#eb-create-rule-define)
+ [Build the event pattern](#eb-create-rule-event-pattern)
+ [Select targets](#eb-create-rule-target)
+ [Configure tags and review rule](#eb-create-rule-review)

## Define the rule
<a name="eb-create-rule-define"></a>

First, enter a name and description for your rule to identify it. You must also define the event bus where your rule looks for events to match to an event pattern.

**To define the rule detail**

1. Open the Amazon EventBridge console at [https://console.aws.amazon.com/events/](https://console.aws.amazon.com/events/).

1. In the navigation pane, choose **Rules**.

1. Choose **Create rule**.

1. On the rule builder selection page, choose **Advanced Builder**.

   The Advanced Builder uses JSON patterns and configuration for rules and targets. To use the visual canvas instead, see [Creating rules (Enhanced Builder)](eb-create-rule-visual.md).

1. Enter a **Name** and, optionally, a **Description** for the rule.

   A rule can't have the same name as another rule in the same AWS Region and on the same event bus.

1. For **Event bus**, choose the event bus to associate with this rule. If you want this rule to match events that come from your account, select **AWS default event bus**. When an AWS service in your account emits an event, it always goes to your account’s default event bus.

1. For **Rule type**, choose **Rule with an event pattern**.

1. Choose **Next**.

## Build the event pattern
<a name="eb-create-rule-event-pattern"></a>

Next, build the event pattern. To do this, specify the event source, choose the basis for the event pattern, and define the attributes and values to match on. You can also generate the event pattern in JSON and test it against a sample event.

**To build the event pattern**

1. For **Event source**, choose **AWS events or EventBridge partner events**.

1. (Optional) In the **Sample events** section, choose a **Sample event type** against which you want to test your event pattern. 

   The following sample event types are available:
   + **AWS events **– Select from events emitted from supported AWS services.
   + **EventBridge partner events** – Select from events emitted from third-party services that support EventBridge, such as Salesforce.
   + **Enter my own** – Enter your own event in JSON text.

     You can also use an AWS or partner event as the starting point for creating your own custom event.

     1. Select **AWS events** or **EventBridge partner events**.

     1. Use the **Sample events** dropdown to select the event you want to use as a starting point for your custom event.

        EventBridge displays the sample event.

     1. Select **Copy**.

     1. Select **Enter my own** for **Event type.**

     1. Delete the sample event structure in the JSON editing pane, and paste the AWS or partner event in its place.

     1. Edit the event JSON to create your own sample event.

1. Choose a **Creation method**. You can create an event pattern from an EventBridge schema or template, or you can create a custom event pattern.

------
#### [ Existing schema ]

   To use an existing EventBridge schema to create the event pattern, do the following:

   1. In the **Creation method** section, for **Method**, select **Use schema**.

   1. In the **Event pattern** section, for **Schema type**, select **Select schema from Schema registry**.

   1. For **Schema registry**, choose the dropdown box and enter the name of a schema registry, such as `aws.events`. You can also select an option from the dropdown list that appears.

   1. For **Schema**, choose the dropdown box and enter the name of the schema to use. For example, `aws.s3@ObjectDeleted`. You can also select an option from the dropdown list that appears.

   1. In the **Models** section, choose the **Edit** button next to any attribute to open its properties. Set the **Relationship** and **Value** fields as needed, then choose **Set** to save the attribute.
**Note**  
For information about an attribute's definition, choose the **Info** icon next to the attribute's name. For a reference on how to set attribute properties in your event, open the **Note** section of the attribute properties dialog box.  
To delete an attribute's properties, choose the **Edit** button for that attribute, then choose **Clear**.

   1. Choose **Generate event pattern in JSON** to generate and validate your event pattern as JSON text. 

   1. (Optional) To test the sample event against your test pattern, choose **Test pattern**. 

      EventBridge displays a message box stating whether your sample event matches the event pattern.

      You can also choose any of the following options:
      + **Copy** – Copy the event pattern to your device's clipboard.
      + **Prettify** – Makes the JSON text easier to read by adding line breaks, tabs, and spaces.

------
#### [ Custom schema ]

   To write a custom schema and convert it to an event pattern, do the following:

   1. In the **Creation method** section, for **Method**, choose **Use schema**.

   1. In the **Event pattern** section, for **Schema type**, choose **Enter schema**.

   1. Enter your schema into the text box. You must format the schema as valid JSON text.

   1. In the **Models** section, choose the **Edit** button next to any attribute to open its properties. Set the **Relationship** and **Value** fields as needed, then choose **Set** to save the attribute.
**Note**  
For information about an attribute's definition, choose the **Info** icon next to the attribute's name. For a reference on how to set attribute properties in your event, open the **Note** section of the attribute properties dialog box.  
To delete an attribute's properties, choose the **Edit** button for that attribute, then choose **Clear**.

   1. Choose **Generate event pattern in JSON** to generate and validate your event pattern as JSON text. 

   1. (Optional) To test the sample event against your test pattern, choose **Test pattern**. 

      EventBridge displays a message box stating whether your sample event matches the event pattern.

      You can also choose any of the following options:
      + **Copy** – Copy the event pattern to your device's clipboard.
      + **Prettify** – Makes the JSON text easier to read by adding line breaks, tabs, and spaces.

------
#### [ Event pattern ]

   To write a custom event pattern in JSON format, do the following:

   1. In the **Creation method** section, for **Method**, choose **Custom pattern (JSON editor)**.

   1. For **Event pattern**, enter your custom event pattern in JSON-formatted text. 

   1. (Optional) To test the sample event against your test pattern, choose **Test pattern**. 

      EventBridge displays a message box stating whether your sample event matches the event pattern.

      You can also choose any of the following options:
      + **Copy** – Copy the event pattern to your device's clipboard.
      + **Prettify** – Makes the JSON text easier to read by adding line breaks, tabs, and spaces.
      + **Event pattern form** – Opens the event pattern in Pattern Builder. If the pattern can't be rendered in Pattern Builder as-is, EventBridge warns you before it opens Pattern Builder.

------

1. Choose **Next**.

## Select targets
<a name="eb-create-rule-target"></a>

Choose one or more targets to receive events that match the specified pattern. Targets can include an EventBridge event bus, EventBridge API destinations, including SaaS partners such as Salesforce, or another AWS service.

**To select targets**

1. For **Target type**, choose one of the following target types:

------
#### [ Event bus ]

   1. Select **EventBridge event bus**.

   1. Choose the event bus to use as the target.
      + To use an event bus in the same AWS Region as this rule: 

        1. Select **Event bus in the same account and Region**.

        1. For **Event bus for target**, choose the dropdown box and enter the name of the event bus. You can also select the event bus from the dropdown list.

           For more information, see [Sending events between event buses in the same account and Region in Amazon EventBridge](eb-bus-to-bus.md).
      + To use an event bus in a different AWS Region or account as this rule:

        1. Select **Event bus in a different account or Region**.

        1. For **Event bus as target**, enter the ARN of the event bus you want to use.

           For more information, see: 
           + [Sending and receiving events between AWS accounts in Amazon EventBridge](eb-cross-account.md)
           + [Sending and receiving events between AWS Regions in Amazon EventBridge](eb-cross-region.md)

   1. For many target types, EventBridge needs permissions to send events to the target. In these cases, EventBridge can create the IAM role needed for your rule to run. 

      For **Execution role**, do one of the following:
      + To create a new execution role for this rule:

        1. Select **Create a new role for this specific resource**.

        1. Either enter a name for this execution role, or use the name generated by EventBridge.
      + To use an existing execution role for this rule:

        1. Select **Use existing role**.

        1. Enter or select the name of the execution role to use from the dropdown list.

   1. (Optional) For **Additional settings**, specify any of the optional settings available for your target type:

      (Optional) For **Dead-letter queue**, choose whether to use a standard Amazon SQS queue as a dead-letter queue. EventBridge sends events that match this rule to the dead-letter queue if they are not successfully delivered to the target. Do one of the following:
      + Choose **None** to not use a dead-letter queue.
      + Choose **Select an Amazon SQS queue in the current AWS account to use as the dead-letter queue** and then select the queue to use from the drop-down list.
      + Choose **Select an Amazon SQS queue in an other AWS account as a dead-letter queue** and then enter the ARN of the queue to use. You must attach a resource-based policy to the queue that grants EventBridge permission to send messages to it. 

        For more information, see [Granting permissions to the dead-letter queue](eb-rule-dlq.md#eb-dlq-perms).

------
#### [ API destination ]

   1. Select **EventBridge API destination**.

   1. Choose a new or existing API destination:
      + To use an existing API destination, select **Use an existing API destination**. Then select an API destination from the dropdown list.
      + To create a new API destination, select **Create a new API destination**. Then, provide the following details for the destination:
        + **Name** – Enter a name for the destination. 

          Names must be unique within your AWS account. Names can have up to 64 characters. Valid characters are **A-Z**, **a-z**, **0-9**, and **.** **\$1** **-** (hyphen).
        + (Optional) **Description** – Enter a description for the destination. 

          Descriptions can have up to 512 characters.
        + **API destination endpoint** – The URL endpoint for the target. 

          The endpoint URL must start with **https**. You can include the **\$1** as a path parameter wildcard. You can set path parameters from the target's `HttpParameters` attribute.
        + **HTTP method** – Select the HTTP method used when you invoke the endpoint.
        + (Optional) **Invocation rate limit per second** – Enter the maximum number of invocations accepted for each second for this destination. 

          This value must be greater than zero. By default, this value is set to 300.
        + **Connection** – Choose to use a new or existing connection: 
          + To use an existing connection, select **Use an existing connection** and select the connection from the dropdown list. 
          + To create a new connection for this destination select **Create a new connection**, then define the connection's **Name**, **Destination type**, and **Authorization type**. You can also add an optional **Description** for this connection.

   1. For many target types, EventBridge needs permissions to send events to the target. In these cases, EventBridge can create the IAM role needed for your rule to run. 

      For **Execution role**, do one of the following:
      + To create a new execution role for this rule:

        1. Select **Create a new role for this specific resource**.

        1. Either enter a name for this execution role, or use the name generated by EventBridge.
      + To use an existing execution role for this rule:

        1. Select **Use existing role**.

        1. Enter or select the name of the execution role to use from the dropdown list.

   1. (Optional) For **Additional settings**, specify any of the optional settings available for your target type:

      Note that EventBridge may not display all of the following fields for a given AWS service.

      1. (Optional) For Configure target input, choose how you want to customize the text sent to the target for matching events. Choose one of the following:
         + **Matched events** – EventBridge sends the entire original source event to the target. This is the default.
         + **Part of the matched events** – EventBridge only sends the specified portion of the original source event to the target.

           Under **Specify the part of the matched event**, specify a JSON path that defines the part of the event you want EventBridge to send to the target.
         + **Constant (JSON text)** – EventBridge sends only the specified JSON text to the target. No part of the original source event is sent.

           Under **Specify the constant in JSON**, specify the JSON text that you want EventBridge to send to the target instead of the event.
         + **Input transformer** – Configure an input transformer to customize the text you want EventBridge send to the target. For more information, see [Amazon EventBridge input transformation](eb-transform-target-input.md).

           1. Select **Configure input transformer**.

           1. Configure the input transformer following the steps in [Configuring an input transformer when creating a rule in EventBridge](eb-transform-input-rule.md).

      1. (Optional) Under **Retry policy**, specify how EventBridge should retry sending an event to a target after an error occurs.
         + **Maximum age of event** – Enter the maximum amount of time (in hours, minutes, and seconds) for EventBridge to retain unprocessed events. The default is 24 hours.
         + **Retry attempts** – Enter the maximum number of times EventBridge should retry sending an event to the target after an error occurs. The default is 185 times.

      1. (Optional) For **Dead-letter queue**, choose whether to use a standard Amazon SQS queue as a dead-letter queue. EventBridge sends events that match this rule to the dead-letter queue if they are not successfully delivered to the target. Do one of the following:
         + Choose **None** to not use a dead-letter queue.
         + Choose **Select an Amazon SQS queue in the current AWS account to use as the dead-letter queue** and then select the queue to use from the drop-down list.
         + Choose **Select an Amazon SQS queue in an other AWS account as a dead-letter queue** and then enter the ARN of the queue to use. You must attach a resource-based policy to the queue that grants EventBridge permission to send messages to it. 

           For more information, see [Granting permissions to the dead-letter queue](eb-rule-dlq.md#eb-dlq-perms).

   For more information, see [API destinations as targets in Amazon EventBridge](eb-api-destinations.md).

------
#### [ AWS service ]

   1. Select **AWS service**.

   1. For **Select a target**, select an AWS service to use as the target. 

   1. If you choose an AWS service that supports cross-account targets, you can select a target in the same account as the event bus, or a different account.
      + For a target in the same account, for **Target type** select **Target in this account**.

        1. Provide the information requested for the service you select.
**Note**  
The fields displayed vary depending on the service selected. For more information about available targets, see [Event bus targets available in the EventBridge console](eb-targets.md#eb-console-targets).

        1. For many target types, EventBridge needs permissions to send events to the target. In these cases, EventBridge can create the IAM role needed for your rule to run. 

           For **Execution role**, do one of the following:
           + To create a new execution role for this rule:

             1. Select **Create a new role for this specific resource**.

             1. Either enter a name for this execution role, or use the name generated by EventBridge.
           + To use an existing execution role for this rule:

             1. Select **Use existing role**.

             1. Enter or select the name of the execution role to use from the dropdown list.
      + For a target in a different account, for **Target type** select **Target in another AWS account**.

        1. Enter the ARN of the target resource to which you want to send events.

        1. Provide any additional information requested for the service you select.

        1. Select the name of the execution role to use from the dropdown list.

   1. (Optional) For **Additional settings**, specify any of the optional settings available for your target type:

      1. (Optional) For Configure target input, choose how you want to customize the text sent to the target for matching events. Choose one of the following:
         + **Matched events** – EventBridge sends the entire original source event to the target. This is the default.
         + **Part of the matched events** – EventBridge only sends the specified portion of the original source event to the target.

           Under **Specify the part of the matched event**, specify a JSON path that defines the part of the event you want EventBridge to send to the target.
         + **Constant (JSON text)** – EventBridge sends only the specified JSON text to the target. No part of the original source event is sent.

           Under **Specify the constant in JSON**, specify the JSON text that you want EventBridge to send to the target instead of the event.
         + **Input transformer** – Configure an input transformer to customize the text you want EventBridge send to the target. For more information, see [Amazon EventBridge input transformation](eb-transform-target-input.md).

           1. Select **Configure input transformer**.

           1. Configure the input transformer following the steps in [Configuring an input transformer when creating a rule in EventBridge](eb-transform-input-rule.md).

      1. (Optional) Under **Retry policy**, specify how EventBridge should retry sending an event to a target after an error occurs.
         + **Maximum age of event** – Enter the maximum amount of time (in hours, minutes, and seconds) for EventBridge to retain unprocessed events. The default is 24 hours.
         + **Retry attempts** – Enter the maximum number of times EventBridge should retry sending an event to the target after an error occurs. The default is 185 times.

      1. (Optional) For **Dead-letter queue**, choose whether to use a standard Amazon SQS queue as a dead-letter queue. EventBridge sends events that match this rule to the dead-letter queue if they are not successfully delivered to the target. Do one of the following:
         + Choose **None** to not use a dead-letter queue.
         + Choose **Select an Amazon SQS queue in the current AWS account to use as the dead-letter queue** and then select the queue to use from the drop-down list.
         + Choose **Select an Amazon SQS queue in an other AWS account as a dead-letter queue** and then enter the ARN of the queue to use. You must attach a resource-based policy to the queue that grants EventBridge permission to send messages to it. 

           For more information, see [Granting permissions to the dead-letter queue](eb-rule-dlq.md#eb-dlq-perms).

------

1. (Optional) Choose **Add another target** to add another target for this rule.

1. Choose **Next**.

## Configure tags and review rule
<a name="eb-create-rule-review"></a>

Finally, enter any desired tags for the rule, then review and create the rule.

**To configure tags, and review and create the rule**

1. (Optional) Enter one or more tags for the rule. For more information, see [Tagging resources in Amazon EventBridge](eb-tagging.md).

1. Choose **Next**.

1. Review the details for the new rule. To make changes to any section, choose the **Edit** button next to that section.

   When satisfied with the rule details, choose **Create rule**.

# Disabling or deleting a rule in Amazon EventBridge
<a name="eb-delete-rule"></a>

To stop a [rule](eb-rules.md) from processing [events](eb-events.md) or running on a schedule, you can delete or disable the rule. The following steps walk you through how to delete or disable an EventBridge rule.

**To delete or disable a rule**

1. Open the Amazon EventBridge console at [https://console.aws.amazon.com/events/](https://console.aws.amazon.com/events/).

1. In the navigation pane, choose **Rules**.

   Under **Event bus**, select the event bus that is associated with the rule.

1. Do one of the following:

   1. To delete a rule, select the button next to the rule and choose **Actions**, **Delete**, **Delete**.

      If the rule is a managed rule, enter the name of the rule to acknowledge that it is a managed rule and that deleting it may stop functionality in the service that created the rule. To continue, enter the rule name and choose **Force delete**.

   1. To temporarily disable a rule, select the button next to the rule and choose **Disable**, **Disable**.

      You can't disable a managed rule.

# Best practices when defining rules in Amazon EventBridge
<a name="eb-rules-best-practices"></a>

Below are some best practices to consider when you create rules for your event buses.

## Set a single target for each rule
<a name="eb-rules-best-practices-single-target"></a>

While you can specify up to five targets for a given rule, managing rules is easier when you specify a single target for each rule. If more than one target needs to receive the same set of events, we recommend duplicating the rule to deliver the same events to different targets. This encapsulation simplifies maintaining rules: if the needs of the event targets diverge over time, you can update each rule and its event pattern independently of the others.

## Set rule permissions
<a name="eb-rules-best-practices-permissions"></a>

You can enable event-consuming application components or services to be in control of managing their own rules. A common architectural approach adopted by customers is to isolate these application components or services by using separate AWS accounts. To enable the flow of events from one account to another, you must create a rule on one event bus that routes events to an event bus in another account. You can enable event-consuming teams or services to be in control of managing their own rules. You do this by specifying the appropriate permissions to their accounts through resource policies. This works across accounts and Regions. 

For more information, see [Permissions for event buses in Amazon EventBridge](eb-event-bus-perms.md).

For example of resource policies, see [Multi-account design patterns with Amazon EventBridge](https://github.com/aws-samples/amazon-eventbridge-resource-policy-samples/tree/main/patterns) on GitHub.

## Monitor rule performance
<a name="eb-rules-best-practices-monitor"></a>

Monitor your rules to make sure they are performing as you expect:
+ Monitor the `TriggeredRules` metric for missing data-points or anomalies can assist you in detecting discrepancies for a publisher that made a breaking change. For more information, see [Monitoring Amazon EventBridge](eb-monitoring.md). 
+ Alarm on anomalies or maximum expected count can also help detecting when a rule is matching against new events. This can happen when event publishers, including AWS services and SaaS partners, introduce new events when enabling new use-cases and features. When these new events are unexpected and lead to a higher volume than the processing rate of the downstream target, they can lead to an event backlog. 

  Such processing of unexpected events can also lead to unwanted billing charges.

  It can also trigger throttling of rules when the account goes over its aggregate target invocations per second service quota. EventBridge will still attempt to deliver events matched by throttled rules and retry up to 24 hours or as described within the target’s custom retry policy. You can detect and alarm throttled rules using the `ThrottledRules` metric
+ For low-latency use cases, you can also monitor latency using `IngestionToInvocationStartLatency`, which provides an indication of health of your event bus. Any extended periods of high latency over 30 seconds may indicate a service disruption or rule throttling.

# Using AWS Serverless Application Model templates to deploy Amazon EventBridge resources
<a name="eb-use-sam"></a>

You can build and test [rules](eb-rules.md) manually in the EventBridge console, which can help in the development process as you refine [event patterns](eb-event-patterns.md). However, once you are ready to deploy your application, it’s easier to use a framework like [AWS SAM](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/what-is-sam.html) to launch all your serverless resources consistently.

We'll use this [ example application](https://github.com/aws-samples/amazon-eventbridge-producer-consumer-example) to look into the ways you can use AWS SAM templates to build EventBridge resources. The template.yaml file in this example is a AWS SAM template that defines four [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) functions and shows two different ways to integrate the Lambda functions with EventBridge.

For a walkthrough of this example application, see [Tutorial: Create a sample Amazon EventBridge application](eb-tutorial-get-started.md).

 There are two approaches to using EventBridge and AWS SAM templates. For simple integrations where one Lambda function is invoked by one rule, the the **Combined template** approach is recommended. If you have complex routing logic, or you are connecting to resources outside of your AWS SAM template, the **Separated template** approach is the better choice.

**Topics**
+ [Combined template](#eb-combined-template)
+ [Separated template](#eb-separated-template)

## Combined template
<a name="eb-combined-template"></a>

The first approach uses the `Events` property to configure the EventBridge rule. The following example code defines an [event](eb-events.md) that invokes your Lambda function.

**Note**  
This example automatically creates the rule on the default [event bus](eb-event-bus.md), which exists in every AWS account. To associate the rule with a custom event bus, you can add the `EventBusName` to the template.

```
atmConsumerCase3Fn:
  Type: AWS::Serverless::Function
  Properties:
    CodeUri: atmConsumer/
    Handler: handler.case3Handler
    Runtime: nodejs12.x
    Events:
      Trigger:
        Type: CloudWatchEvent 
        Properties:
          Pattern:
            source:
              - custom.myATMapp
            detail-type:
              - transaction                
            detail:
              result:
                - "anything-but": "approved"
```

 This YAML code is equivalent to an event pattern in the EventBridge console. In YAML, you only need to define the event pattern, and AWS SAM automatically creates an IAM role with the required permissions. 

## Separated template
<a name="eb-separated-template"></a>

In the second approach to defining an EventBridge configuration in AWS SAM, the resources are separated more clearly in the template. 

1. First, you define the Lambda function:

   ```
   atmConsumerCase1Fn:
     Type: AWS::Serverless::Function
     Properties:
       CodeUri: atmConsumer/
       Handler: handler.case1Handler
       Runtime: nodejs12.x
   ```

1. Next, define the rule using an `AWS::Events::Rule` resource. The properties define the event pattern and can also specify [targets](eb-targets.md). You can explicitly define multiple targets.

   ```
   EventRuleCase1: 
     Type: AWS::Events::Rule
     Properties: 
       Description: "Approved transactions"
       EventPattern: 
         source: 
           - "custom.myATMapp"
         detail-type:
           - transaction   
         detail: 
           result: 
             - "approved"
       State: "ENABLED"
       Targets: 
         - 
           Arn: 
             Fn::GetAtt: 
               - "atmConsumerCase1Fn"
               - "Arn"
           Id: "atmConsumerTarget1"
   ```

1. Finally, define an `AWS::Lambda::Permission` resource that grants permission to EventBridge to invoke the target.

   ```
   PermissionForEventsToInvokeLambda: 
     Type: AWS::Lambda::Permission
     Properties: 
       FunctionName: 
         Ref: "atmConsumerCase1Fn"
       Action: "lambda:InvokeFunction"
       Principal: "events.amazonaws.com"
       SourceArn: 
         Fn::GetAtt: 
           - "EventRuleCase1"
           - "Arn"
   ```

# Generating an AWS CloudFormation template from an existing EventBridge rule
<a name="rule-generate-template"></a>

AWS CloudFormation enables you to configure and manage your AWS resources across accounts and regions in a centralized and repeatable manner by treating infrastructure as code. CloudFormation does this by letting you create *templates*, which define the resources you want to provision and manage.

EventBridge enables you to generate templates from the existing rules in your account, as an aid to help you jumpstart developing CloudFormation templates. You can select a single rule, or multiple rules to include in the template. You can then use these templates as the basis for [creating stacks](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-create-stack.html) of resources under CloudFormation management.

For more information on CloudFormation see [*The CloudFormation User Guide*.](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)

**Note**  
EventBridge does not include [managed rules](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-rules.html) in the generated template.

You can also [generate a template from an existing event bus](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-generate-event-bus-template.html), including the rules that event bus contains.

**To generate an CloudFormation template from one or more rules**

1. Open the Amazon EventBridge console at [https://console.aws.amazon.com/events/](https://console.aws.amazon.com/events/).

1. In the navigation pane, choose **Rules**.

1. Under **Select event bus**, choose the event bus that contains the rules you want to include in the template.

1. Under **Rules**, choose the rules you want to include in the generated CloudFormation template.

   For a single rule, you can also choose the rule name to display the rule's details page.

1. Choose **CloudFormation Template**, and then choose which format you want EventBridge to generate the template in: **JSON** or **YAML**.

   EventBridge displays the template, generated in the selected format.

1. EventBridge gives you the option of downloading the template file, or copying the template to the clipboard.
   + To download the template file, choose **Download**.
   + To copy the template to the clipboard, choose **Copy**.

1. To exit the template, choose **Cancel**. 

Once you've customized your CloudFormation template as necessary for your use case, you can use it to [create stacks](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-create-stack.html) in CloudFormation.

## Considerations when using CloudFormation templates generated from Amazon EventBridge
<a name="eb-generate-rule-template-considerations"></a>

Consider the following factors when using a CloudFormation template you generated from EventBridge:
+ EventBridge does not include any passwords in the generate template.

  You can edit the template to include [template parameters](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/parameters-section-structure.html) that enable users to specify passwords or other sensitive information when using the template to create or update a CloudFormation stack.

  In addition, users can use Secrets Manager to create a secret in the desired region and then edit the generated template to employ [dynamic parameters](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/dynamic-references.html#dynamic-references-secretsmanager).
+ Targets in the generated template remain exactly as they were specified in the original event bus. This can lead to cross-region issues if you do not appropriately edit the template before using it to create stacks in other regions.

  Additionally, the generated template does not create the downstream targets automatically.

# Event bus targets in Amazon EventBridge
<a name="eb-targets"></a>

A *target* is a resource or endpoint that EventBridge sends an [event](eb-events.md) to when the event matches the event pattern defined for a [rule](eb-rules.md). **The rule processes the [event](eb-events.md) data and sends the pertinent information to the target. To deliver event data to a target, EventBridge needs permission to access the target resource. You can define up to five targets for each rule.

When you add targets to a rule and that rule runs soon after, any new or updated targets might not be immediately invoked. Allow a short period of time for changes to take effect.

## Event bus targets available in the EventBridge console
<a name="eb-console-targets"></a>

You can configure the following target types for rules in the EventBridge console:
+ API destinations

  API destinations are HTTPS endpoints that you can invoke as the target of an event bus rule. When you specify an API destination as a rule target, EventBridge invokes the HTTPS endpoint for any event that matches the event pattern specified in the rule, and then delivers the event information with the request. For more information, see [API destinations](eb-api-destinations.md).
+ Event buses

  You can specify other event buses as targets for rules. This includes event buses in the same or different AWS accounts.
  + [Cross-account event buses as targets](eb-cross-account.md)
  + [Same account event buses as targets](eb-bus-to-bus.md)
+ AWS services

  You can have EventBridge send events to a number of AWS service resources. These include:
  + [API Gateway](eb-api-gateway-target.md)
  + [AWS AppSync](target-appsync.md)
  + [Batch job queue](#targets-specifics-batch)
  + [CloudWatch log group](#targets-specifics-cwl)
  + [CodeBuild project](#targets-specifics-codebuild)
  + CodePipeline
  + Amazon EBS `CreateSnapshot` API call
  + EC2 Image Builder
  + EC2 `RebootInstances` API call
  + EC2 `StopInstances` API call
  + EC2 `TerminateInstances` API call
  + [ECS task](#targets-specifics-ecs-task)
  + Firehose delivery stream
  + Glue workflow
  + [Incident Manager response plan](https://docs.aws.amazon.com//incident-manager/latest/userguide/incident-creation.html#incident-tracking-auto-eventbridge)
  + Inspector assessment template
  + Kinesis stream
  + Lambda function (ASYNC)
  + [Amazon Redshift cluster data API queries](https://docs.aws.amazon.com/redshift/latest/mgmt/data-api-calling-event-bridge.html) 
  + [Amazon Redshift Serverless workgroup data API queries](https://docs.aws.amazon.com/redshift/latest/mgmt/data-api-calling-event-bridge.html)
  + SageMaker AI Pipeline
  + Amazon SNS topic
  + [Amazon SQS standard, fair, and FIFO queues](#targets-specifics-sqs)
  + Step Functions state machine (ASYNC)
  + Systems Manager Automation
  + Systems Manager OpsItem
  + Systems Manager Run Command

## Target parameters
<a name="targets-specific-parms"></a>

Some targets don't send the information in the event payload to the target, instead, they treat the event as a trigger for invoking a specific API. EventBridge uses the [Target](https://docs.aws.amazon.com/eventbridge/latest/APIReference/API_Target.html) parameters to determine what happens with that target. These include the following:
+ API destinations

  The data sent to an API destination must match the structure of the API. Use the [https://docs.aws.amazon.com/eventbridge/latest/APIReference/API_InputTransformer.html](https://docs.aws.amazon.com/eventbridge/latest/APIReference/API_InputTransformer.html) object to make sure the data is structured correctly. If you want to include the original event payload, reference it in the [https://docs.aws.amazon.com/eventbridge/latest/APIReference/API_InputTransformer.html](https://docs.aws.amazon.com/eventbridge/latest/APIReference/API_InputTransformer.html).
+ API Gateway 

  The data sent to API Gateway must match the structure of the API. Use the [https://docs.aws.amazon.com/eventbridge/latest/APIReference/API_InputTransformer.html](https://docs.aws.amazon.com/eventbridge/latest/APIReference/API_InputTransformer.html) object to make sure the data is structured correctly. If you want to include the original event payload, reference it in the [https://docs.aws.amazon.com/eventbridge/latest/APIReference/API_InputTransformer.html](https://docs.aws.amazon.com/eventbridge/latest/APIReference/API_InputTransformer.html).
+ Amazon EC2 Image Builder
+ Amazon Redshift Data API clusters

  Use [https://docs.aws.amazon.com/eventbridge/latest/APIReference/API_RedshiftDataParameters.html](https://docs.aws.amazon.com/eventbridge/latest/APIReference/API_RedshiftDataParameters.html).
+ Amazon SageMaker Runtime Model Building Pipelines

  Use [https://docs.aws.amazon.com/eventbridge/latest/APIReference/API_SageMakerPipelineParameters.html](https://docs.aws.amazon.com/eventbridge/latest/APIReference/API_SageMakerPipelineParameters.html).
+ Amazon SQS fair and FIFO queues

  Use [https://docs.aws.amazon.com/eventbridge/latest/APIReference/API_SqsParameters.html](https://docs.aws.amazon.com/eventbridge/latest/APIReference/API_SqsParameters.html) to specify the message group to use as the target.
+ Systems Manager Run Command

  Use [https://docs.aws.amazon.com/eventbridge/latest/APIReference/API_RunCommandParameters.html](https://docs.aws.amazon.com/eventbridge/latest/APIReference/API_RunCommandParameters.html) to specify the SSM document and target instances. For more information, see [Systems Manager Run Command as a target](#targets-specifics-ssm-run-command).

**Note**  
EventBridge does not support all JSON Path syntax and evaluate it at runtime. Supported syntax includes:   
dot notation (for example,`$.detail`)
dashes
underscores
alphanumeric characters
array indices
wildcards (\$1)
forward slashes

### Dynamic path parameters
<a name="dynamic-path-parameters"></a>

Dynamic path parameters let you use JSON path syntax to reference event data at runtime instead of static values.

You can use dynamic JSON path syntax with target parameters to specify JSON paths instead of static values (for example, `$.detail.state`).

#### Requirements
<a name="requirements"></a>

The entire value must be a JSON path, not just part of it. For example:
+ ✓ Correct: `RedshiftParameters.Sql` can be `$.detail.state`
+ ✗ Incorrect: `RedshiftParameters.Sql` cannot be `"SELECT * FROM $.detail.state"`

EventBridge replaces these paths at runtime with data from the event payload at the specified path.

#### Limitations
<a name="limitations"></a>

Dynamic path parameters cannot reference new or transformed values from input transformation. The JSON path syntax is the same as input transformation syntax. For more information, see [Amazon EventBridge input transformation](eb-transform-target-input.md).

#### Supported parameters
<a name="supported-parameters"></a>

You can use dynamic syntax on all string, non-enum fields of these parameters:
+ [https://docs.aws.amazon.com/eventbridge/latest/APIReference/API_EcsParameters.html](https://docs.aws.amazon.com/eventbridge/latest/APIReference/API_EcsParameters.html)
+ [https://docs.aws.amazon.com/eventbridge/latest/APIReference/API_HttpParameters.html](https://docs.aws.amazon.com/eventbridge/latest/APIReference/API_HttpParameters.html) (except `HeaderParameters` keys)
+ [https://docs.aws.amazon.com/eventbridge/latest/APIReference/API_RedshiftDataParameters.html](https://docs.aws.amazon.com/eventbridge/latest/APIReference/API_RedshiftDataParameters.html)
+ [https://docs.aws.amazon.com/eventbridge/latest/APIReference/API_SageMakerPipelineParameters.html](https://docs.aws.amazon.com/eventbridge/latest/APIReference/API_SageMakerPipelineParameters.html)
+ [https://docs.aws.amazon.com/eventbridge/latest/APIReference/API_SqsParameters.html](https://docs.aws.amazon.com/eventbridge/latest/APIReference/API_SqsParameters.html)

## Permissions
<a name="targets-permissions"></a>

To make API calls on the resources that you own, EventBridge needs appropriate permissions. Specify an IAM execution role [using the EventBridge console](eb-create-rule-wizard.md#eb-create-rule-target), or by setting the `RoleARN` parameter in [https://docs.aws.amazon.com/eventbridge/latest/APIReference/API_PutTargets.html](https://docs.aws.amazon.com/eventbridge/latest/APIReference/API_PutTargets.html).

For example, the following policy defines permission to send messages to an Amazon SQS queue:

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "sqs:SendMessage"
            ],
            "Resource": [
                "arn:aws:sqs:us-east-1:111122223333:sqs-queue-name"
            ]
        }
    ]
}
```

------

And the following trust policy enables EventBridge to assume the role:

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "events.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}
```

------

You can invoke an API Gateway endpoint with configured IAM authorization, but the role is optional if you haven't configured authorization. For more information, see [Amazon EventBridge and AWS Identity and Access Management](eb-iam.md).

If another account is in the same Region and has granted you permission, then you can send events to that account. 

For more information, see [Sending and receiving events between AWS accounts in Amazon EventBridge](eb-cross-account.md). 

If your target, such as an Amazon SQS queue, uses AWS Key Management Service (AWS KMS) encryption, you must include the following section in your KMS key policy:

```
{
  "Sid": "Allow EventBridge to use the key",
  "Effect": "Allow",
  "Principal": {
    "Service": "events.amazonaws.com"
  },
  "Action": [
    "kms:Decrypt",
    "kms:GenerateDataKey"
  ],
  "Resource": "*"
}
```

## AWS Batch job queues as targets
<a name="targets-specifics-batch"></a>

Certain parameters to AWS Batch `submitJob` can be configured via [BatchParameters](https://docs.aws.amazon.com/eventbridge/latest/APIReference/API_BatchParameters.html).

Others can be specified in the event payload. If the event payload (passed through or via [InputTransformers](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-transform-target-input.html)) contains the following keys, they are mapped to `submitJob` [request parameters](https://docs.aws.amazon.com/batch/latest/APIReference/API_SubmitJob.html#API_SubmitJob_RequestSyntax):
+ `ContainerOverrides: containerOverrides`
**Note**  
This includes only command, environment, memory, and vcpus
+ `DependsOn: dependsOn`
**Note**  
This includes only jobId
+ `Parameters: parameters`

## CloudWatch Logs groups as targets
<a name="targets-specifics-cwl"></a>

If you don’t use an [InputTransformer](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-transform-target-input.html) with a CloudWatch Logs target, the event payload is used as the log message, and the source of the event as the timestamp. If you do use an InputTransformer, the template must be:

`{"timestamp":<timestamp>,"message":<message>}`

EventBridge batches the entries sent to a log stream; therefore, EventBridge may deliver a single or multiple events to a log stream, depending on traffic.

## CodeBuild projects as targets
<a name="targets-specifics-codebuild"></a>

EventBridge supports both standard and batch builds as targets. 

If you use an [input transformer](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-transform-target-input.html) to shape the source event to match the [StartBuildRequest](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_StartBuild.html#API_StartBuild_RequestSyntax) structure before it is delivered to a CodeBuild target, the parameters will be mapped 1-to-1 and passed through to `codeBuild.StartBuild` by default. 

To pass the parameters to `codeBuild.StartBuildBatch` instead, transform the source event to match the [StartBuildBatchRequest](https://docs.aws.amazon.com/codebuild/latest/APIReference/API_StartBuildBatch.html#API_StartBuildBatch_RequestSyntax) structure, and add the following key/value pair to the root of the transformed event:

`"buildType": "BATCH"`

## Amazon ECS tasks as targets
<a name="targets-specifics-ecs-task"></a>

If you use [InputTransformers](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-transform-target-input.html) to shape the input event to a Target to match the Amazon ECS RunTask [TaskOverride](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_TaskOverride.html) structure, the parameters will be mapped 1-to-1 and passed through to `ecs.RunTask`.

## Incident Manager response plans as targets
<a name="targets-specifics-incident-manager"></a>

If the matched event came from CloudWatch Alarms, the alarm state change details are populated into the trigger details of the StartIncidentRequest call to Incident Manager.

## Systems Manager Run Command as a target
<a name="targets-specifics-ssm-run-command"></a>

When you specify Systems Manager Run Command as a target, EventBridge calls the [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_SendCommand.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_SendCommand.html) API on your behalf. Configure the target using [https://docs.aws.amazon.com/eventbridge/latest/APIReference/API_RunCommandParameters.html](https://docs.aws.amazon.com/eventbridge/latest/APIReference/API_RunCommandParameters.html), which specifies the SSM document to run and the target instances or tags.

`RunCommandParameters` contains the following fields:
+ `RunCommandTargets` — (Required) A list of key-value pairs that specify the target instances. Use `Key` set to `InstanceIds` with a list of instance IDs, or `Key` set to `tag:tag-name` with tag values to target instances by tag. You can specify between 1 and 5 run command targets.

To specify which SSM document to run and pass parameters to it, use the `Input` field on the [https://docs.aws.amazon.com/eventbridge/latest/APIReference/API_Target.html](https://docs.aws.amazon.com/eventbridge/latest/APIReference/API_Target.html) object. The `Input` value must be a JSON object with the following structure:

```
{
  "DocumentName": "document-name",
  "DocumentVersion": "version",
  "Parameters": {
    "parameter-key": ["parameter-value"]
  }
}
```

Where:
+ `DocumentName` — The name or ARN of the SSM document to run.
+ `DocumentVersion` — (Optional) The version of the document. If omitted, the default version is used.
+ `Parameters` — (Optional) A map of parameter names to value arrays, matching the parameters defined in the SSM document.

For example, the following AWS CLI command creates a rule that runs the `AWS-RunShellScript` document on a specific instance when an EventBridge event matches:

```
aws events put-targets --rule "my-rule" --targets '[{
  "Id": "ssm-target-1",
  "Arn": "arn:aws:ssm:region:account-id:document/AWS-RunShellScript",
  "RoleArn": "arn:aws:iam::account-id:role/EventBridgeSSMRole",
  "Input": "{\\"Parameters\\":{\\"commands\\":[\\"echo Hello from EventBridge\\"]}}",
  "RunCommandParameters": {
    "RunCommandTargets": [{
      "Key": "InstanceIds",
      "Values": ["i-0123456789abcdef0"]
    }]
  }
}]'
```

**Note**  
The `Input` field on the `Target` object is used to pass the document name and parameters to Systems Manager Run Command. This is different from the [https://docs.aws.amazon.com/eventbridge/latest/APIReference/API_InputTransformer.html](https://docs.aws.amazon.com/eventbridge/latest/APIReference/API_InputTransformer.html), which transforms the event payload. When using Systems Manager Run Command as a target, set the document parameters in `Input` and specify the target instances in `RunCommandParameters`.

## Amazon SQS queues as targets
<a name="targets-specifics-sqs"></a>

EventBridge does not support using Amazon SQS queues that are encrypted with an AWS owned key. This includes targets, as well as Amazon SQS queues specified as dead-letter queues for targets. For more information on AWS owned keys, see [AWS owned keys](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-owned-cmk) in the *AWS Key Management Service Developer Guide*.

# Amazon API Gateway targets for rules in Amazon EventBridge
<a name="eb-api-gateway-target"></a>

You can use Amazon API Gateway to create, publish, maintain, and monitor APIs. Amazon EventBridge supports sending events to an API Gateway endpoint. When you specify an API Gateway endpoint as a [target](eb-targets.md), each [event](eb-events.md) sent to the target maps to a request sent to the endpoint.

**Important**  
EventBridge supports using API Gateway *Edge-optimized* and *Regional* endpoints as targets. *Private* endpoints are not currently supported. To learn more about endpoints, see [https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-api-endpoint-types.html](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-api-endpoint-types.html).

You can use an API Gateway target for the following use cases:
+ To invoke a customer-specified API hosted in API Gateway based on AWS or third-party events.
+ To invoke an endpoint periodically on a schedule.

The EventBridge JSON event information is sent as the body of the HTTP request to your endpoint. You can specify the other request attributes in the target’s `HttpParameters` field as follows:
+ `PathParameterValues` lists the values that correspond sequentially to any path variables in your endpoint ARN, for example `"arn:aws:execute-api:us-east-1:112233445566:myapi/dev/POST/pets/*/*"`.
+ `QueryStringParameters` represents the query string parameters that EventBridge appends to the invoked endpoint.
+ `HeaderParameters` defines HTTP headers to add to the request.

**Note**  
For security considerations, the following HTTP header keys aren't permitted:  
Anything prefixed with `X-Amz` or `X-Amzn`
`Authorization`
`Connection`
`Content-Encoding`
`Content-Length`
`Host`
`Max-Forwards`
`TE`
`Transfer-Encoding`
`Trailer`
`Upgrade`
`Via`
`WWW-Authenticate`
`X-Forwarded-For`

## Dynamic Parameters
<a name="eb-targets-apigateway-dynamic"></a>

When invoking an API Gateway target, you can dynamically add data to events that are sent to the target. For more information, see [Target parameters](eb-targets.md#targets-specific-parms).

## Invocation Retries
<a name="eb-targets-apigateway-retries"></a>

As with all targets, EventBridge retries some failed invocations. For API Gateway, EventBridge retries responses sent with a 5xx or 429 HTTP status code for up to 24 hours with [exponential back off and jitter](https://aws.amazon.com/blogs/architecture/exponential-backoff-and-jitter/). After that, EventBridge publishes a `FailedInvocations` metric in Amazon CloudWatch. EventBridge doesn't retry other 4xx HTTP errors.

## Timeout
<a name="eb-targets-apigateway-timeout"></a>

EventBridge rule API Gateway requests must have a maximum client execution timeout of 5 seconds. If API Gateway takes longer than 5 seconds to respond, EventBridge times out the request and then retries.

EventBridge Pipes API Gateway requests have a maximum timeout of 29 seconds, the API Gateway maximum.

# AWS AppSync targets for rules in Amazon EventBridge
<a name="target-appsync"></a>

AWS AppSync enables developers to connect their applications and services to data and events with secure, serverless and high-performing GraphQL and Pub/Sub APIs. With AWS AppSync, you can publish real-time data updates to your applications with GraphQL mutations. EventBridge supports calling a valid GraphQL mutation operation for matched events. When you specify an AWS AppSync API mutation as a target, AWS AppSync processes the event via a mutation operation, which can then trigger subscriptions linked to the mutation.

**Note**  
EventBridge supports AWS AppSync public GraphQL APIs. EventBridge does not currently support AWS AppSync Private APIs.

You can use an AWS AppSync GraphQL API target for the following use cases:
+ To push, transform, and store event data into your configured data sources.
+ To send real-time notifications to connected application clients.

**Note**  
AWS AppSync targets only support calling AWS AppSync GraphQL APIs using the [`AWS_IAM` authorization type](https://docs.aws.amazon.com/appsync/latest/devguide/security-authz.html#aws-iam-authorization).

For more information on AWS AppSync GraphQL APIs, see the [GraphQL and AWS AppSync architecture](https://docs.aws.amazon.com/appsync/latest/devguide/graphql-overview.html) in the *AWS AppSync Developer Guide*.

**To specify an AWS AppSync target for an EventBridge rule using the console**

1. [Create or edit the rule.](eb-create-rule-visual.md)

1. Under **Target**, [specify the target](eb-create-rule-wizard.md#eb-create-rule-target) by choosing **AWS service** and then **AWS AppSync**.

1. Specify the mutation operation to be parsed and executed, along with the selection set.
   + Choose the AWS AppSync API, and then the GraphQL API mutation to invoke.
   + Under **Configure parameters and selection set**, choose to create a selection set using key-value mapping or an input transformer.

------
#### [ Key-value mapping ]

     To use key-value mapping to create your selection set:
     + Specify variables for the API parameters. Each variables can be either a static values or a dynamic JSON path expression to the event payload.
     + Under **Selection set**, choose the variables you want included in the response.

------
#### [ Input transformer ]

     To use an input transformer to create your selection set:
     + Specify an input path that defines the variables to use.
     + Specify an input template to define and format the information you want passed to the target.

     For more information, see [Configuring an input transformer when creating a rule in EventBridge](eb-transform-input-rule.md).

------

1. For **Execution role**, choose whether to create a new role or use an existing role.

1. Complete creating or editing the rule.

## Example: AWS AppSync targets for Amazon EventBridge
<a name="target-appsync-walkthrough"></a>

In the following example, we'll walk through how to specifying an AWS AppSync target for an EventBridge rule, including defining an input transformation to format events for delivery.

Suppose you have an AWS AppSync GraphQL API, `Ec2EventAPI`, defined by the following schema:

```
type Event {
    id: ID!
    statusCode: String
    instanceId: String
}

type Mutation {
    pushEvent(id: ID!, statusCode: String!, instanceId: String): Event
}

type Query {
    listEvents: [Event]
}

type Subscription {
    subscribeToEvent(id: ID, statusCode: String, instanceId: String): Event
        @aws_subscribe(mutations: ["pushEvent"])
}
```

Applications clients that use this API can subscribe to the `subscribeToEvent` subscription, which is triggered by the `pushEvent` mutation.

You can create an EventBridge rule with a target that sends events to the AppSync API via the `pushEvent` mutation. When the mutation is invoked, any client that is subscribed will receive the event.

To specifying this API as the target for an EventBridge rule, you would do the following:

1. Set the Amazon Resource Name (ARN) of the rule target to the GraphQL endpoint ARN of the `Ec2EventAPI` API.

1. Specify the mutation GraphQL Operation as a target parameter:

   ```
   mutation CreatePushEvent($id: ID!, $statusCode: String, $instanceId: String) {
     pushEvent(id: $input, statusCode: $statusCode, instanceId: $instanceId) {
       id
       statusCode
       instanceId
     }
   }
   ```

   Your mutation selection set must include all the fields you wish to subscribe to in your GraphQL subscription.

1. Configure an input transformer to specify how data from matched events is used in your operation.

   Suppose you selected the `“EC2 Instance Launch Successful”` sample event:

   ```
   {
     "version": "0",
     "id": "3e3c153a-8339-4e30-8c35-687ebef853fe",
     "detail-type": "EC2 Instance Launch Successful",
     "source": "aws.autoscaling",
     "account": "123456789012",
     "time": "2015-11-11T21:31:47Z",
     "region": "us-east-1",
     "resources": ["arn:aws:autoscaling:us-east-1:123456789012:autoScalingGroup:eb56d16b-bbf0-401d-b893-d5978ed4a025:autoScalingGroupName/sampleLuanchSucASG", "arn:aws:ec2:us-east-1:123456789012:instance/i-b188560f"],
     "detail": {
       "StatusCode": "InProgress",
       "AutoScalingGroupName": "sampleLuanchSucASG",
       "ActivityId": "9cabb81f-42de-417d-8aa7-ce16bf026590",
       "Details": {
         "Availability Zone": "us-east-1b",
         "Subnet ID": "subnet-95bfcebe"
       },
       "RequestId": "9cabb81f-42de-417d-8aa7-ce16bf026590",
       "EndTime": "2015-11-11T21:31:47.208Z",
       "EC2InstanceId": "i-b188560f",
       "StartTime": "2015-11-11T21:31:13.671Z",
       "Cause": "At 2015-11-11T21:31:10Z a user request created an AutoScalingGroup changing the desired capacity from 0 to 1.  At 2015-11-11T21:31:11Z an instance was started in response to a difference between desired and actual capacity, increasing the capacity from 0 to 1."
     }
   }
   ```

   You can define the following variables for use in your template, using the target input transformer's input path:

   ```
   {
     "id": "$.id",
     "statusCode": "$.detail.StatusCode",
     "EC2InstanceId": "$.detail.EC2InstanceId"
   }
   ```

   Compose the input transformer template to define the variables that EventBridge passes to the AWS AppSync mutation operation. The template must evaluate to JSON. Given our input path, you can compose the following template:

   ```
   {
     "id": <id>,
     "statusCode": <statusCode>,
     "instanceId": <EC2InstanceId>
   }
   ```

# Sending events to an AWS service in another account in EventBridge
<a name="eb-service-cross-account"></a>

EventBridge can send events from an event bus in one AWS account to supported AWS services in another account, thereby simplifying the architecture of your event-driven solutions and reducing latency.

For example, suppose you have a set of event buses, hosted in multiple accounts, that you require to send security-related events to an Amazon SQS queue in a centralized account for further asynchronous processing and analysis.

EventBridge supports sending events to cross-account targets in the same Region.

## Supported services
<a name="eb-service-cross-account-services"></a>

EventBridge supports sending events to the following targets in other AWS accounts:
+ Amazon API Gateway APIs
+ Amazon Kinesis Data Streams streams
+ Lambda functions
+ Amazon SNS topics
+ Amazon SQS queues

For pricing, see [Amazon EventBridge pricing](https://aws.amazon.com/eventbridge/pricing/).

## Permissions
<a name="eb-service-cross-account-permissions"></a>

Enabling access for cross-account event delivery to AWS services as targets involves the following steps: 
+ Specify an execution role
+ Attach a resource policy to the target

### Specify an execution role
<a name="eb-service-cross-account-permissions-role"></a>

Specify an execution role for EventBridge to use when sending events to the target when the rule is triggered.

This execution role must be in the same account as the event bus. EventBridge assumes this role when attempting to invoke the target, and any Service Control Policies (SCPs) affecting this account are applied. 

SCPs are a type of organization policy that you can use to manage permissions in your organization. For more information, see [Service control policies](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) in the *AWS Organizations User Guide*.

For example, the following policy allows the EventBridge service to assume the execution role:

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "events.amazonaws.com"
       },
      "Action": "sts:AssumeRole"
    }
  ]
}
```

------

And the following policy allows the role to send messages to Amazon SQS queues:

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "sqs:SendMessage",
      "Resource": "arn:aws:sqs:us-east-1:123456789012:queue-name"
    }
  ]
}
```

------

For accounts using AWS Organizations, you can apply an SCP to prevent invoking resources that do not belong to your organization, as shown in the following example:

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
          {
            "Action": [
                "*"
            ],
            "Resource": "*",
            "Effect": "Deny",
            "Condition": {
                "StringNotEquals": {
                    "aws:ResourceOrgID": "o-1234567890"
                }
            }
        }
    ]
}
```

------

**Note**  
For cross-account targets other than event buses, calling `PutTarget` from a different account than the event bus, even if supplying an execution role from the calling account, is not supported.

### Attach a resource access policy to the target
<a name="eb-service-cross-account-permissions-policy"></a>

The AWS services that can receive cross-account events support IAM resource-based policies. This enables you to attach a resource access policy to the target, so you can specify which account has access to it.

Building on our earlier example, the following policy allows the event bus account access to the Amazon SQS queue in the target account:

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Action": [
        "SQS:SendMessage"
      ],
      "Effect": "Allow",
      "Resource": "arn:aws:sqs:us-east-1:123456789012:queue-name",
      "Principal": {
      "AWS": "123456789012"
     }
    }
  ]
}
```

------

For more information, see [Identity-based policies and resource-based policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_identity-vs-resource.html) in the *AWS Identity and Access Management User Guide*.

## Creating rules that send events to AWS services in other accounts
<a name="eb-service-cross-account"></a>

Specifying an AWS service in another account as a target is part of creating the event bus rule.

**To create a rule that sends events to an AWS service in a different AWS account using the console**

1. Follow the steps in the [Creating rules using the Enhanced Builder](eb-create-rule-visual.md) procedure.

1. In the [Select targets](eb-create-rule-wizard.md#eb-create-rule-target) step, when prompted to choose a target type:

   1. Select **AWS service**.

   1. Select an AWS service that supports cross-account targets.

      For more information, see [Supported services](#eb-service-cross-account-services).

   1. For **Target location** choose **Target in another AWS account**.

   1. Enter the ARN of the target resource to which you want to send events.

   1. Select the name of the execution role to use from the dropdown list.

   1. Provide any additional information requested for the service you select. The fields displayed vary depending on the service selected.

1. Complete creating the rule following the procedure steps.

# Sending and receiving events between AWS accounts in Amazon EventBridge
<a name="eb-cross-account"></a>

You can configure EventBridge to send and receive [events](eb-events.md) between [event buses](eb-event-bus.md) in AWS accounts. When you configure EventBridge to send or receive events between accounts, you can specify which AWS accounts can send events to or receive events from the event bus in your account. You can also allow or deny events from specific [rules](eb-rules.md) associated with the event bus, or events from specific sources. For more information, see [Simplifying cross-account access with Amazon EventBridge resource policies](https://aws.amazon.com/blogs//compute/simplifying-cross-account-access-with-amazon-eventbridge-resource-policies/)

**Note**  
If you use AWS Organizations, you can specify an organization and grant access to all accounts in that organization. In addition, the sending event bus must have IAM roles attached to them when sending events to another account. For more information, see [What is AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html) in the *AWS Organizations User Guide*.

**Note**  
If you're using an Incident Manager response plan as a target, all the response plans that are shared with your account are available by default.

You can send and receive events between event buses in AWS accounts within the same Region in all Regions and between accounts in different Regions as long as the destination Region is a supported [cross-Region](eb-cross-region.md) destination Region.

The steps to configure EventBridge to send events to or receive events from an event bus in a different account include the following:
+ On the *receiver* account, edit the permissions on an 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 event bus as the target.

  If the sender account inherits permissions to send events from an AWS Organization, 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 event bus in the receiver account, the role is created 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.

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 EventBridge Pricing](https://aws.amazon.com/eventbridge/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.

If you have three event buses in the same account, and set up a rule on the first event bus to forward events from the second event bus to a third event bus, those events are not sent to the third event bus.

 The following video covers routing events between accounts:




## Grant permissions to allow events from other AWS accounts
<a name="eb-receiving-events-from-another-account"></a>

To receive events from other accounts or organizations, you must first edit the permissions on the event bus where you intend to receive events. The default event bus accepts events from AWS services, other authorized AWS accounts, and `PutEvents` calls. The permissions for an event bus are granted or denied using a resource-based policy attached to the event bus. In the policy, you can grant permissions to other AWS accounts using the account ID, or to an AWS organization using the organization ID. To learn more about event bus permissions, including example policies, see [Permissions for event buses in Amazon EventBridge](eb-event-bus-perms.md).

**Note**  
EventBridge now requires all new cross account event bus targets to add IAM roles. This only applies to event bus targets created after March 2, 2023. Applications created without an IAM role before that date are not affected. However, we recommend adding IAM roles to grant users access to resources in another account, as this ensures organization boundaries using Service Control Policies (SCPs) are applied to determine who can send and receive events from accounts in your organization. 

**Important**  
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 `Account` 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 `Account` field. For more information, see [Events in Amazon EventBridge](eb-events.md).

## Rules for events between AWS accounts
<a name="eb-writing-rules-that-match-events-from-another-account"></a>

If your account is set up to receive events from event buses in other AWS accounts, you can write rules that match those events. Set the [event pattern](eb-event-patterns.md) of the rule to match the events you are receiving from event buses in the other account.

Unless you specify `account` in the event pattern of a rule, any of your account's rules, both new and existing, that match events you receive from event buses in other accounts trigger based on those events. If you are receiving events from event buses in 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 `account` and specify your own account ID to the event pattern of the rule.

If you set up your AWS account to accept events from event buses in all AWS accounts, we strongly recommend that you add `account` to every EventBridge rule in your account. This prevents rules in your account from triggering on events from unknown AWS accounts. When you specify the `account` 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 event buses in AWS account that you have granted permissions to, do not specify \$1 in the `account` field of the rule. Doing so would not match any events, because \$1 never appears in the `account` field of an event. Instead, just omit the `account` field from the rule.

## Creating rules that send events between AWS accounts
<a name="eb-create-rule-cross-account-target"></a>

Specifying an event bus in another account as a target is part of creating the rule.

**To create a rule that sends events to a different AWS account using the console**

1. Follow the steps in the [Creating rules using the Enhanced Builder](eb-create-rule-visual.md) procedure.

1. In the [Select targets](eb-create-rule-wizard.md#eb-create-rule-target) step, when prompted to choose a target type:

   1. Select **EventBridge event bus**.

   1. Select **Event bus in a different account or Region**.

   1. For **Event bus as target**, enter the ARN of the event bus you want to use.

1. Complete creating the rule following the procedure steps.

# Sending and receiving events between AWS Regions in Amazon EventBridge
<a name="eb-cross-region"></a>

You can configure EventBridge to send and receive [events](eb-events.md) between AWS Regions. You can also allow or deny events from specific Regions, specific [rules](eb-rules.md) associated with the event bus, or events from specific sources. For more information, see [Introducing cross-Region event routing with Amazon EventBridge](https://aws.amazon.com/blogs//compute/introducing-cross-region-event-routing-with-amazon-eventbridge/)

 The following video covers routing events between Regions using the [https://console.aws.amazon.com/events/](https://console.aws.amazon.com/events/), AWS CloudFormation, and AWS Serverless Application Model:




## Creating rules that send events to a different AWS Region
<a name="eb-create-rule-cross-region-target"></a>

Specifying an event bus in another AWS Region as a target is part of creating the rule.

**To create a rule that sends events to a different AWS account using the console**

1. Follow the steps in the [Creating rules using the Enhanced Builder](eb-create-rule-visual.md) procedure.

1. In the [Select targets](eb-create-rule-wizard.md#eb-create-rule-target) step, when prompted to choose a target type:

   1. Select **EventBridge event bus**.

   1. Select **Event bus in a different account or Region**.

   1. For **Event bus as target**, enter the ARN of the event bus you want to use.

1. Complete creating the rule following the procedure steps.

# Sending events between event buses in the same account and Region in Amazon EventBridge
<a name="eb-bus-to-bus"></a>

You can configure EventBridge to send and receive [events](eb-events.md) between [event buses](eb-event-bus.md) in the same AWS account and Region. 

When you configure EventBridge to send or receive events between event buses, you use IAM roles on the *sender* event bus to give the *sender* event bus permission to send events to the *receiver* event bus. You use [Resource-based](eb-use-resource-based.md) policies on the *receiver* event bus to give the *receiver* event bus permission to receive events from the *sender* event bus. You can also allow or deny events from certain event buses, specific [rules](eb-rules.md) associated with the event bus, or events from specific sources. For more information about event bus permissions, including example policies, see [Permissions for event buses in Amazon EventBridge](eb-event-bus-perms.md).

The steps to configure EventBridge to send events to or receive events between event buses in your account include the following:
+ To use an existing IAM role, you need to give either the sender event bus permissions to the receiver event bus or the receiver event bus permissions to the sender event bus.
+ On the *sender* event bus, set up one or more rules that have the receiver event bus as the target and create an IAM role. For an example of the policy that should be attached to the role, see [Example policy: Send events to an event bus in the same account in Amazon EventBridge](eb-event-bus-example-policy-same-account.md).
+ On the *receiver* event bus, edit the permissions to allow events to be passed from the other event bus.
+ On the *receiver* event, set up one or more rules that match events that come from the sender event bus.
**Note**  
EventBridge can't route events received from a sender event bus to a third event bus.

Events sent from one event bus to another are charged as custom events. For more information, see [Amazon EventBridge Pricing](https://aws.amazon.com/eventbridge/pricing/).

## Creating rules that send events to a different event bus in the same AWS account and Region
<a name="eb-create-rule-same-account-region-target"></a>

To send events to another event bus, you create a rule with an event bus as a target. Specifying an event bus in the same AWS account and Region as a target is part of creating the rule.

**To create a rule that sends events to a different event bus in the same AWS account and Region using the console**

1. Follow the steps in the [Creating rules using the Enhanced Builder](eb-create-rule-visual.md) procedure.

1. In the [Select targets](eb-create-rule-wizard.md#eb-create-rule-target) step, when prompted to choose a target type:

   1. Select **EventBridge event bus**.

   1. Select **Event bus in the same AWS account and Region**.

   1. For **Event bus as a target**, select an event bus from the drop-down list.

1. Complete creating the rule following the procedure steps.

# Amazon EventBridge input transformation
<a name="eb-transform-target-input"></a>

You can customize the text from an [event](eb-events.md) before EventBridge passes the information to the [target](eb-targets.md) of a [rule](eb-rules.md). Using the input transformer in the console or the API, you define variables that use JSON path to reference values in the original event source. The transformed event is sent to a target instead of the original event. However, [dynamic path parameters](eb-targets.md#dynamic-path-parameters) must reference the original event, not the transformed event. You can define up to 100 variables, assigning each a value from the input. Then you can use those variables in the *Input Template* as <*variable-name*>. 

For a tutorial on using input transformer, see [Tutorial: Use input transformers to transform events in EventBridge](eb-input-transformer-tutorial.md).

**Note**  
EventBridge does not support all JSON Path syntax and evaluate it at runtime. Supported syntax includes:   
dot notation (for example,`$.detail`)
dashes
underscores
alphanumeric characters
array indices
wildcards (\$1)
forward slashes

**Topics**
+ [Predefined variables](#eb-transform-input-predefined)
+ [Input transform examples](#eb-transform-input-examples)
+ [Transforming input by using the EventBridge API](#eb-transform-input-api)
+ [Transforming input by using AWS CloudFormation](#eb-transform-input-cfn)
+ [Common Issues with transforming input](#eb-transform-input-issues)
+ [Configuring an input transformer when creating a rule in EventBridge](eb-transform-input-rule.md)
+ [Testing a target input transformer using the EventBridge Sandbox](eb-sandbox-input-trans.md)

## Predefined variables
<a name="eb-transform-input-predefined"></a>

There are pre-defined variables you can use without defining a JSON path. These variables are reserved, and you can't create variables with these names:
+ ****`aws.events.rule-arn` — The Amazon Resource Name (ARN) of the EventBridge rule. 
+ ****`aws.events.rule-name` — The Name of the EventBridge rule. 
+ ****`aws.events.event.ingestion-time` — The time at which the event was received by EventBridge. This is an ISO 8601 timestamp. This variable is generated by EventBridge and can't be overwritten.
+ ****`aws.events.event` — The original event payload as JSON (without the `detail` field). Can only be used as a value for a JSON field, as it's contents are not escaped.
+ ****`aws.events.event.json` — The full original event payload as JSON. (with the `detail` field). Can only be used as a value for a JSON field, as it's contents are not escaped.

## Input transform examples
<a name="eb-transform-input-examples"></a>

The following is an example Amazon EC2 event.

```
{
  "version": "0",
  "id": "7bf73129-1428-4cd3-a780-95db273d1602",
  "detail-type": "EC2 Instance State-change Notification",
  "source": "aws.ec2",
  "account": "123456789012",
  "time": "2015-11-11T21:29:54Z",
  "region": "us-east-1",
  "resources": [
    "arn:aws:ec2:us-east-1:123456789012:instance/i-abcd1111"
  ],
  "detail": {
    "instance-id": "i-0123456789",
    "state": "RUNNING"
  }
}
```

When defining a rule in the console, select the **Input Transformer** option under **Configure input**. This option displays two text boxes: one for the *Input Path* and one for the *Input Template*.

### Input path
<a name="eb-transform-target-input-path"></a>

*Input Path* is used to define variables. Use JSON path to reference items in your event and store those values in variables. For instance, you could create an *Input Path* to reference values in the example event by entering the following in the first text box. You can also use brackets and indices to get items from arrays.

**Note**  
EventBridge replaces input transformers at runtime to ensure a valid JSON output. Because of this, put quotes around variables that refer to JSON path parameters, but do not put quotes around variables that refer to JSON objects or arrays.

```
{
  "timestamp" : "$.time",
  "instance" : "$.detail.instance-id", 
  "state" : "$.detail.state",
  "resource" : "$.resources[0]"
}
```

This defines four variables, `<timestamp>`, `<instance>`, `<state>`, and `<resource>`. You can reference these variables as you create your *Input Template*.

**Note**  
Amazon CloudWatch Logs and SSM targets do not support the use of `Input` and `InputPath` in their input transformers.

### Input template
<a name="eb-transform-target-input-template"></a>

The *Input Template* is a template for the information you want to pass to your target. You can create a template that passes either a string or JSON to the target. Using the previous event and *Input Path*, the following *Input Template* examples will transform the event to the example output before routing it to a target.


| Description | Template | Output | 
| --- | --- | --- | 
| Simple string |  <pre>"instance <instance> is in <state>"</pre> |  <pre>"instance i-0123456789 is in RUNNING"</pre>  | 
|  **String with escaped quotes**  |  <pre>"instance \"<instance>\" is in <state>"</pre> |  <pre>"instance \"i-0123456789\" is in RUNNING"</pre> Note that this is the behavior in the EventBridge console. The AWS CLI escapes the slash characters and the result is `"instance "i-0123456789" is in RUNNING"`.  | 
|  **Simple JSON**  |  <pre>{<br />  "instance" : <instance>,<br />  "state": <state><br />}</pre> |  <pre>{<br />  "instance" : "i-0123456789",<br />  "state": "RUNNING"<br />}</pre>  | 
|  **JSON with strings and variables**  |  <pre>{<br /> "instance" : <instance>,<br /> "state": "<state>",<br /> "instanceStatus": "instance \"<instance>\" is in <state>"<br />}</pre>  |  <pre>{<br /> "instance" : "i-0123456789",<br /> "state": "RUNNING",<br /> "instanceStatus": "instance \"i-0123456789\" is in RUNNING"<br />}</pre>  | 
|  **JSON with a mix of variables and static information**  |  <pre>{<br />  "instance" : <instance>,<br />  "state": [ 9, <state>, true ],<br />  "Transformed" : "Yes"<br />}<br /></pre> |  <pre>{<br />  "instance" : "i-0123456789",<br />  "state": [<br />    9,<br />    "RUNNING",<br />    true<br />  ],<br />  "Transformed" : "Yes"<br />}</pre>  | 
|  **Including reserved variables in JSON**  |  <pre>{<br />  "instance" : <instance>,<br />  "state": <state>,<br />  "ruleArn" : <aws.events.rule-arn>,<br />  "ruleName" : <aws.events.rule-name>,<br />  "originalEvent" : <aws.events.event.json><br />}</pre> |  <pre>{<br />  "instance" : "i-0123456789",<br />  "state": "RUNNING",<br />  "ruleArn" : "arn:aws:events:us-east-2:123456789012:rule/example",<br />  "ruleName" : "example",<br />  "originalEvent" : {<br />    ... // commented for brevity<br />  }<br />}</pre>  | 
|  **Including reserved variables in a string**  | <pre>"<aws.events.rule-name> triggered"</pre> |  <pre>"example triggered"</pre>  | 
|  **Amazon CloudWatch log group**  | <pre>{<br />  "timestamp" : <timestamp>,<br />  "message": "instance \"<instance>\" is in <state>"<br />}</pre> |  <pre>{<br />  "timestamp" : 2015-11-11T21:29:54Z,<br />  "message": "instance "i-0123456789" is in RUNNING<br />}</pre>  | 

## Transforming input by using the EventBridge API
<a name="eb-transform-input-api"></a>

For information about using the EventBridge API to transform input, see [Use Input Transformer to extract data from an event and input that data to the target](https://docs.aws.amazon.com/eventbridge/latest/APIReference/API_PutTargets.html#API_PutTargets_Example_2).

## Transforming input by using AWS CloudFormation
<a name="eb-transform-input-cfn"></a>

For information about using AWS CloudFormation to transform input, see [AWS::Events::Rule InputTransformer](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-events-rule-inputtransformer.html).

## Common Issues with transforming input
<a name="eb-transform-input-issues"></a>

These are some common issues when transforming input in EventBridge:
+  For Strings, quotes are required.
+  There is no validation when creating JSON path for your template.
+  If you specify a variable to match a JSON path that doesn't exist in the event, that variable isn't created and won't appear in the output.
+ JSON properties like `aws.events.event.json` can only be used as the value of a JSON field, not inline in other strings.
+  EventBridge doesn't escape values extracted by *Input Path*, when populating the *Input Template* for a target.
+ If a JSON path references a JSON object or array, but the variable is referenced in a string, EventBridge removes any internal quotes to ensure a valid string. For example, for a variable `<detail>` pointed at `$.detail`, "Detail is <detail>" would result in EventBridge removing quotes from the object. 

  Therefore, if you want to output a JSON object based on a single JSON path variable, you must place it as a key. In this example, `{"detail": <detail>}`.
+ Quotes are not required for variables that represent strings. They are permitted, but EventBridge automatically adds quotes to string variable values during transformation, to ensure the transformation output is valid JSON. EventBridge does not add quotes to variables that represent JSON objects or arrays. Do not add quotes for variables that represent JSON objects or arrays.

  For example, the following input template includes variables that represent both strings and JSON objects:

  ```
  {
    "ruleArn" : <aws.events.rule-arn>,
    "ruleName" : <aws.events.rule-name>,
    "originalEvent" : <aws.events.event.json>
  }
  ```

  Resulting in valid JSON with proper quotation:

  ```
  {
    "ruleArn" : "arn:aws:events:us-east-2:123456789012:rule/example",
    "ruleName" : "example",
    "originalEvent" : {
      ... // commented for brevity
    }
  }
  ```
+ For (non-JSON) text output as multi-line strings, wrap each separate line in your input template in double quotes. 

  For example, if you were matching [Amazon Inspector Finding](https://docs.aws.amazon.com/inspector/latest/user/eventbridge-integration.html#event-finding) events against the following event pattern:

  ```
  {
    "detail": {
      "severity": ["HIGH"],
      "status": ["ACTIVE"]
    },
    "detail-type": ["Inspector2 Finding"],
    "source": ["inspector2"]
  }
  ```

  And using the following input path:

  ```
  {
    "account": "$.detail.awsAccountId",
    "ami": "$.detail.resources[0].details.awsEc2Instance.imageId",
    "arn": "$.detail.findingArn",
    "description": "$.detail.description",
    "instance": "$.detail.resources[0].id",
    "platform": "$.detail.resources[0].details.awsEc2Instance.platform",
    "region": "$.detail.resources[0].region",
    "severity": "$.detail.severity",
    "time": "$.time",
    "title": "$.detail.title",
    "type": "$.detail.type"
  }
  ```

  You could use the input template below to generate multi-line string output:

  ```
  "<severity> severity finding <title>"
  "Description: <description>"
  "ARN: \"<arn>\""
  "Type: <type>"
  "AWS Account: <account>"
  "Region: <region>"
  "EC2 Instance: <instance>"
  "Platform: <platform>"
  "AMI: <ami>"
  ```

# Configuring an input transformer when creating a rule in EventBridge
<a name="eb-transform-input-rule"></a>

As part of creating a rule, you can specify an input transformer for EventBridge to use to process matching events prior to sending those event to the specified target. You can configure input transformers for targets that are AWS services or API destinations.

**To create a target input transformer as part of a rule**

1. Follow the steps for creating a rule as detailed in [Creating rules using the Enhanced Builder](eb-create-rule-visual.md).

1. In **Step 3 - Select target(s)**, expand **Additional settings**.

1. For **Configure target input**, choose **Input transformer** in the dropdown.

   Click **Configure input transformer**.

   EventBridge displays the **Configure input transformer** dialog box.

1. In the **Sample event** section, choose a **Sample event type** against which you want to test your event pattern. You can choose an AWS event, a partner event, or enter your own custom event.

------
#### [ AWS events ]

   Select from events emitted from supported AWS services.

   1. Select **AWS events**.

   1. Under **Sample events**, choose the desired AWS event. Events are organized by AWS service.

      When you select an event, EventBridge populates the sample event.

      For example, if you choose **S3 Object Created**, EventBridge displays a sample S3 Object Created event.

   1. (Optional) You can also select **Copy** to copy the sample event to your device's clipboard.

------
#### [ Partner events ]

   Select from events emitted from third-party services that support EventBridge, such as Salesforce.

   1. Select **EventBridge partner events**.

   1. Under **Sample events**, choose the desired partner event. Events are organized by partner.

      When you select an event, EventBridge populates the sample event.

   1. (Optional) You can also select **Copy** to copy the sample event to your device's clipboard.

------
#### [ Enter your own ]

   Enter your own event in JSON text.

   1. Select **Enter your own**.

   1. EventBridge populates the sample event with a template of required event attributes.

   1. Edit and add to the sample event as desired. The sample event must be valid JSON.

   1. (Optional) You can also choose any of the following options:
      + **Copy** – Copy the sample event to your device's clipboard.
      + **Prettify** – Makes the JSON text easier to read by adding line breaks, tabs, and spaces.

------

1. (Optional) Expand the **Example input paths, Templates and Outputs** section to see examples of:
   + How JSON paths are used to define variables that represent event data
   + How those variables can be used in an input transformer template
   + The resulting output that EventBridge sends to the target

   For more detailed examples of input transformations, see [Input transform examples](eb-transform-target-input.md#eb-transform-input-examples).

1. In the **Target input transformer** section, define any variables you want to use in the input template.

   Variables use JSON path to reference values in the original event source. You can then reference those variables in the input template in order to include data from the original source event in the transformed event that EventBridge passes to the target. You can define up to 100 variables. The input transformer must be valid JSON.

   For example, suppose you had chosen AWS event **S3 Object Created** as your sample event for this input transformer. You could then define the following variables for use in your template:

   ```
   {
     "requester": "$.detail.requester",
     "key": "$.detail.object.key",
     "bucket": "$.detail.bucket.name"
   }
   ```

   (Optional) You can also choose **Copy** to copy the input transformer to your device's clipboard.

1. In the **Template** section, compose the template you want to use to determine what EventBridge passes to the target.

   You can use JSON, strings, static information, variables you've defined as well as reserved variables. For more detailed examples of input transformations, see [Input transform examples](eb-transform-target-input.md#eb-transform-input-examples).

   For example, suppose you had defined the variables in the previous example. You could then compose the following template, which references those variables, as well as reserved variables, and static information.

   ```
   {
       "message": "<requester> has created the object \"<key>\" in the bucket \"<bucket>\"",
       "RuleName": <aws.events.rule-name>,
       "ruleArn" : <aws.events.rule-arn>,
       "Transformed": "Yes"
   }
   ```

   (Optional) You can also choose **Copy** to copy the template to your device's clipboard.

1. To test your template, select **Generate output**.

   EventBridge processes the sample event based on the input template, and displays the transformed output generated under **Output**. This is the information that EventBridge will pass to the target in place of the original source event.

   The generated output for the example input template described above would be the following:

   ```
   {
       "message": "123456789012 has created the object "example-key" in the bucket "amzn-s3-demo-bucket"",
       "RuleName": rule-name,
       "ruleArn" : arn:aws:events:us-east-1:123456789012:rule/rule-name,
       "Transformed": "Yes"
   }
   ```

   (Optional) You can also choose **Copy** to copy the generated output to your device's clipboard.

1. Select **Confirm**

1. Follow the rest of the steps for creating a rule as detailed in [Creating rules using the Enhanced Builder](eb-create-rule-visual.md).

# Testing a target input transformer using the EventBridge Sandbox
<a name="eb-sandbox-input-trans"></a>

You can use input transformers to customize the text from an [event](eb-events.md) before EventBridge passes the information to the [target](eb-targets.md) of a [rule](eb-rules.md).

Configuring an input transformer is typically part of the larger process of specifying a target while [creating a new rule](eb-create-rule-visual.md) or editing an existing one. Using the Sandbox in EventBridge, however, you can quickly configure an input transformer and use a sample event to confirm you are getting the desired output, without having to create or edit a rule.

For more information about input transformations, see [Amazon EventBridge input transformation](eb-transform-target-input.md).

**To test a target input transformer**

1. Open the Amazon EventBridge console at [https://console.aws.amazon.com/events/](https://console.aws.amazon.com/events/).

1. Under **Developer resources**, choose **Sandbox**, and on the **Sandbox** page choose the **Target input transformer** tab.

1. In the **Sample event** section, choose a **Sample event type** against which you want to test your event pattern. You can choose an AWS event, a partner event, or enter your own custom event.

------
#### [ AWS events ]

   Select from events emitted from supported AWS services.

   1. Select **AWS events**.

   1. Under **Sample events**, choose the desired AWS event. Events are organized by AWS service.

      When you select an event, EventBridge populates the sample event.

      For example, if you choose **S3 Object Created**, EventBridge displays a sample S3 Object Created event.

   1. (Optional) You can also select **Copy** to copy the sample event to your device's clipboard.

------
#### [ Partner events ]

   Select from events emitted from third-party services that support EventBridge, such as Salesforce.

   1. Select **EventBridge partner events**.

   1. Under **Sample events**, choose the desired partner event. Events are organized by partner.

      When you select an event, EventBridge populates the sample event.

   1. (Optional) You can also select **Copy** to copy the sample event to your device's clipboard.

------
#### [ Enter your own ]

   Enter your own event in JSON text.

   1. Select **Enter your own**.

   1. EventBridge populates the sample event with a template of required event attributes.

   1. Edit and add to the sample event as desired. The sample event must be valid JSON.

   1. (Optional) You can also choose any of the following options:
      + **Copy** – Copy the sample event to your device's clipboard.
      + **Prettify** – Makes the JSON text easier to read by adding line breaks, tabs, and spaces.

------

1. (Optional) Expand the **Example input paths, Templates and Outputs** section to see examples of:
   + How JSON paths are used to define variables that represent event data
   + How those variables can be used in an input transformer template
   + The resulting output that EventBridge sends to the target

   For more detailed examples of input transformations, see [Input transform examples](eb-transform-target-input.md#eb-transform-input-examples).

1. In the **Target input transformer** section, define any variables you want to use in the input template.

   Variables use JSON path to reference values in the original event source. You can then reference those variables in the input template in order to include data from the original source event in the transformed event that EventBridge passes to the target. You can define up to 100 variables. The input transformer must be valid JSON.

   For example, suppose you had chosen AWS event **S3 Object Created** as your sample event for this input transformer. You could then define the following variables for use in your template:

   ```
   {
     "requester": "$.detail.requester",
     "key": "$.detail.object.key",
     "bucket": "$.detail.bucket.name"
   }
   ```

   (Optional) You can also choose **Copy** to copy the input transformer to your device's clipboard.

1. In the **Template** section, compose the template you want to use to determine what EventBridge passes to the target.

   You can use JSON, strings, static information, variables you've defined as well as reserved variables. For more detailed examples of input transformations, see [Input transform examples](eb-transform-target-input.md#eb-transform-input-examples).

   For example, suppose you had defined the variables in the previous example. You could then compose the following template, which references those variables, as well as reserved variables, and static information.

   ```
   {
       "message": "<requester> has created the object \"<key>\" in the bucket \"<bucket>\"",
       "RuleName": <aws.events.rule-name>,
       "ruleArn" : <aws.events.rule-arn>,
       "Transformed": "Yes"
   }
   ```

   (Optional) You can also choose **Copy** to copy the template to your device's clipboard.

1. To test your template, select **Generate output**.

   EventBridge processes the sample event based on the input template, and displays the transformed output generated under **Output**. This is the information that EventBridge will pass to the target in place of the original source event.

   The generated output for the example input template described above would be the following:

   ```
   {
       "message": "123456789012 has created the object "example-key" in the bucket "amzn-s3-demo-bucket"",
       "RuleName": rule-name,
       "ruleArn" : arn:aws:events:us-east-1:123456789012:rule/rule-name,
       "Transformed": "Yes"
   }
   ```

   (Optional) You can also choose **Copy** to copy the generated output to your device's clipboard.

# Archiving and replaying events in Amazon EventBridge
<a name="eb-archive"></a>

In EventBridge, you can create an archive of events so that you can easily *replay*, or resend them to the event bus that originally received them, at a later time. For example, you might want to replay events to recover from errors, or to validate new functionality in your application.

## Archiving events
<a name="eb-archive-archive"></a>

When you create an archive, you can specify: 
+ Which events to send to the archive.

  You can specify an event pattern for EventBridge to use when filtering the events it sends to the archive.
+ How long to retain events in the archive.

  You can specify the number of days to retain events in the archive. By default, EventBridge stores events in an archive indefinitely.

Each archive receives events from a single *source* event bus. You cannot change the source event bus once an archive is created. You can create multiple archives for a given event bus.

![\[Events are filtered by an event pattern and sent to an archive, from which they can be replayed.\]](http://docs.aws.amazon.com/eventbridge/latest/userguide/images/archive_eventbridge_conceptual.svg)


EventBridge charges apply to archives. Please refer to [Amazon EventBridge Pricing](https://aws.amazon.com/eventbridge/pricing/) for details.

### Encrypting archive events
<a name="eb-archive-encryption"></a>

By default, EventBridge encrypts event data in an archive using 256-bit Advanced Encryption Standard (AES-256) under an [AWS owned CMK](https://docs.aws.amazon.com//kms/latest/developerguide/concepts.html#aws-owned-cmk), which helps secure your data from unauthorized access.

### Event delivery
<a name="eb-archive-timing"></a>

Keep in the following considerations in mind about how EventBridge delivers events to archives:
+ There may be a delay between an event being received on an event bus and the event arriving in the archive. We recommend you delay replaying archived events for 10 minutes to make sure all events are replayed.
+ The `EventCount` and `SizeBytes` values of the [https://docs.aws.amazon.com/eventbridge/latest/APIReference/API_DescribeArchive.html](https://docs.aws.amazon.com/eventbridge/latest/APIReference/API_DescribeArchive.html) operation have a reconciliation period of 24 hours. Therefore, any recently-expired or newly-archived events may not be immediately reflected in these values.

### Preventing replayed events from being delivered to an archive
<a name="eb-archive-managed-rule"></a>

When you create an archive, EventBridge generates a [managed rule](eb-rules.md#eb-rules-managed) on the source event bus that prevents replayed events from being sent to the archive. The managed rule adds the following event pattern, which filters events based on whether it contains a `replay-name` field. (EventBridge adds this field to events when it replays them.)

```
{
  "replay-name": [{
    "exists": false
  }]
}
```

## Replaying events from an archive
<a name="eb-archive-replay"></a>

After you create an archive, you can then replay events from the archive. For example, if you update an application with additional functionality, you can replay historical events to ensure that the events are reprocessed to keep the application consistent. You can also use an archive to replay events for new functionality.

When you replay events from an archive, you specify:
+ The time frame from which to select events to replay.
+ Optionally, specific rules on the event bus to which EventBridge should replay the selected events.

Archive events can only be replayed to the source event bus.

You can have a maximum of ten active concurrent replays per account per AWS Region.

Replaying events does not remove them from the archive. You can replay events in multiple replays. EventBridge only removes events when they exceed the archive retention period, or you delete the archive itself.

EventBridge deletes replays after 90 days.

You can cancel replays while their status is `Starting` or `Running`. For more information, see [Canceling event replays](eb-replay-cancel.md).

### Identifying events that have been replayed
<a name="eb-archive-replay-event-transform"></a>

When EventBridge sends an event from an archive to the source event bus during a replay, it adds a metadata field to the event, `replay-name`, which contains the name of the replay. You can use this field to identify replayed events when they are delivered to a target.

EventBridge also uses this field to make sure that replayed events aren't sent to archives.

### Considerations when replaying events from an archive
<a name="eb-archive-replay-considerations"></a>

Keep the following considerations in mind when replaying events from an archive:
+ There may be a delay between an event being received on an event bus and the event arriving in the archive. We recommend you delay replaying archived events for 10 minutes to make sure all events are replayed.
+ Events aren't necessarily replayed in the same order that they were added to the archive. A replay processes events to replay based on the time in the event, and replays them on one minute intervals. If you specify an event start time and an event end time that covers a 20 minute time range, the events are replayed from the first minute of that 20 minute range first. Then the events from the second minute are replayed.
+ You can use the `DescribeReplay` operation of the EventBridge API to determine the progress of a replay. `EventLastReplayedTime` returns the time stamp of the last event replayed.
+ Events are replayed based on, but separate from, the `PutEvents` transactions per second limit for the AWS account. You can request an increase to the limit for PutEvents. For more information, see [ Amazon EventBridge Quotas](https://docs.aws.amazon.com/eventbridge/latest/userguide/cloudwatch-limits-eventbridge.html).

 The following video demonstrates the use of archive and replay:




# Creating event archives in Amazon EventBridge
<a name="eb-archive-event"></a>

When you create an archive in EventBridge, you can determine which events are sent to the archive by specifying an [event pattern](eb-event-patterns.md). EventBridge sends events that match the event pattern to the archive. You also set the retention period to store events in the archive before they are discarded.

You can also create archives as part of [creating an event bus](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-create-event-bus.html). These archives have an indefinite retention policy and no event filter, although this can be [updated](https://docs.aws.amazon.com/eventbridge/latest/userguide/event-bus-update-archive.html) once the archive is created.

**Topics**
+ [Define the archive](#eb-create-archive-define)
+ [Build the event pattern (optional)](#eb-create-archive-event-pattern)

## Define the archive
<a name="eb-create-archive-define"></a>

First, enter a name and description for archive, and specify the event bus from which it receives events. Optionally, you can also set how long to retain events in the archive.

**To define the archive**

1. Open the Amazon EventBridge console at [https://console.aws.amazon.com/events/](https://console.aws.amazon.com/events/).

1. Navigate to the source event bus, or create the archive directly:
   + In the navigation pane, choose **Event buses**.

     On the events bus details page, choose the **Archives** tab.
   + In the navigation pane, choose **Archives**.

1. Choose **Create archive**.

1. Under **Archive detail**, enter a name and optionally, a description for the archive. 

    The name must be unique to your account in the selected Region. You can't change the name after you create the archive.

1. For **Source**, select the event bus you want to send events to the archive

   If you navigated from an existing event bus details page, the name of that event bus appears by default.

   You cannot change the source event bus once you have created the archive.

1. For **Retention period**, specify how long to retain the events in the archive:
   + Choose **Indefinite** to retain the events in the archive and not ever delete them.
   + For a set retention period, enter the number of days after which EventBridge should delete the events from the archive.

1. For **Encryption**, choose the KMS key for EventBridge to use when encrypting the events stored in the archive.
**Important**  
If you have specify that EventBridge use a customer managed key for encrypting the source event bus, we strongly recommend you also specify a customer managed key for any archives for the event bus as well.
   + Choose **Use AWS owned key** for EventBridge to encrypt the data using an AWS owned key.

     This AWS owned key is a KMS key that EventBridge owns and manages for use in multiple AWS accounts. In general, unless you are required to audit or control the encryption key that protects your resources, an AWS owned key is a good choice. 

     This is the default.
   + Choose **Use customer managed key** for EventBridge to encrypt the data using the customer managed key that you specify or create.

     Customer managed key are KMS keys in your AWS account that you create, own, and manage. You have full control over these KMS keys.

     1. Specify an existing customer managed key, or choose **Create a new KMS key />**.

       EventBridge displays the key status and any key aliases that have been associated with the specified customer managed key.

1. Choose **Next**.

## Build the event pattern (optional)
<a name="eb-create-archive-event-pattern"></a>

Next, as an optional step, you can build an event pattern to filter which events EventBridge sends to the archive. To do this, specify the event source, choose the basis for the event pattern, and define the attributes and values to match on. You can also generate the event pattern in JSON and test it against a sample event.

For more information on event patterns, see [](eb-event-patterns.md).

**To build the event pattern**

1. For **Event source**, choose **AWS events or EventBridge partner events**.

1. (Optional) In the **Sample events** section, choose a **Sample event type** against which you want to test your event pattern. 

   The following sample event types are available:
   + **AWS events **– Select from events emitted from supported AWS services.
   + **EventBridge partner events** – Select from events emitted from third-party services that support EventBridge, such as Salesforce.
   + **Enter my own** – Enter your own event in JSON text.

     You can also use an AWS or partner event as the starting point for creating your own custom event.

     1. Select **AWS events** or **EventBridge partner events**.

     1. Use the **Sample events** dropdown to select the event you want to use as a starting point for your custom event.

        EventBridge displays the sample event.

     1. Select **Copy**.

     1. Select **Enter my own** for **Event type.**

     1. Delete the sample event structure in the JSON editing pane, and paste the AWS or partner event in its place.

     1. Edit the event JSON to create your own sample event.

1. Choose a **Creation method**. You can create an event pattern from an EventBridge schema or template, or you can create a custom event pattern.

------
#### [ Existing schema ]

   To use an existing EventBridge schema to create the event pattern, do the following:

   1. In the **Creation method** section, for **Method**, select **Use schema**.

   1. In the **Event pattern** section, for **Schema type**, select **Select schema from Schema registry**.

   1. For **Schema registry**, choose the dropdown box and enter the name of a schema registry, such as `aws.events`. You can also select an option from the dropdown list that appears.

   1. For **Schema**, choose the dropdown box and enter the name of the schema to use. For example, `aws.s3@ObjectDeleted`. You can also select an option from the dropdown list that appears.

   1. In the **Models** section, choose the **Edit** button next to any attribute to open its properties. Set the **Relationship** and **Value** fields as needed, then choose **Set** to save the attribute.
**Note**  
For information about an attribute's definition, choose the **Info** icon next to the attribute's name. For a reference on how to set attribute properties in your event, open the **Note** section of the attribute properties dialog box.  
To delete an attribute's properties, choose the **Edit** button for that attribute, then choose **Clear**.

   1. Choose **Generate event pattern in JSON** to generate and validate your event pattern as JSON text. 

   1. (Optional) To test the sample event against your test pattern, choose **Test pattern**. 

      EventBridge displays a message box stating whether your sample event matches the event pattern.

      You can also choose any of the following options:
      + **Copy** – Copy the event pattern to your device's clipboard.
      + **Prettify** – Makes the JSON text easier to read by adding line breaks, tabs, and spaces.

------
#### [ Custom schema ]

   To write a custom schema and convert it to an event pattern, do the following:

   1. In the **Creation method** section, for **Method**, choose **Use schema**.

   1. In the **Event pattern** section, for **Schema type**, choose **Enter schema**.

   1. Enter your schema into the text box. You must format the schema as valid JSON text.

   1. In the **Models** section, choose the **Edit** button next to any attribute to open its properties. Set the **Relationship** and **Value** fields as needed, then choose **Set** to save the attribute.
**Note**  
For information about an attribute's definition, choose the **Info** icon next to the attribute's name. For a reference on how to set attribute properties in your event, open the **Note** section of the attribute properties dialog box.  
To delete an attribute's properties, choose the **Edit** button for that attribute, then choose **Clear**.

   1. Choose **Generate event pattern in JSON** to generate and validate your event pattern as JSON text. 

   1. (Optional) To test the sample event against your test pattern, choose **Test pattern**. 

      EventBridge displays a message box stating whether your sample event matches the event pattern.

      You can also choose any of the following options:
      + **Copy** – Copy the event pattern to your device's clipboard.
      + **Prettify** – Makes the JSON text easier to read by adding line breaks, tabs, and spaces.

------
#### [ Event pattern ]

   To write a custom event pattern in JSON format, do the following:

   1. In the **Creation method** section, for **Method**, choose **Custom pattern (JSON editor)**.

   1. For **Event pattern**, enter your custom event pattern in JSON-formatted text. 

   1. (Optional) To test the sample event against your test pattern, choose **Test pattern**. 

      EventBridge displays a message box stating whether your sample event matches the event pattern.

      You can also choose any of the following options:
      + **Copy** – Copy the event pattern to your device's clipboard.
      + **Prettify** – Makes the JSON text easier to read by adding line breaks, tabs, and spaces.
      + **Event pattern form** – Opens the event pattern in Pattern Builder. If the pattern can't be rendered in Pattern Builder as-is, EventBridge warns you before it opens Pattern Builder.

------

1. Choose **Create archive**.

To confirm that events are successfully sent to the archive, you can use the [https://docs.aws.amazon.com/eventbridge/latest/APIReference/API_DescribeArchive.html](https://docs.aws.amazon.com/eventbridge/latest/APIReference/API_DescribeArchive.html) operation of the EventBridge API to see if the `EventCount` reflects the number of events in the archive. If it is 0, there are no events in the archive.

# Updating archives on Amazon EventBridge event buses
<a name="event-bus-update-archive"></a>

You can update the following: 
+ Archive description
+ The event pattern used to filter which events are sent to the archive.
+ The retention period for events.
+ The AWS KMS key used for event encryption.

  For more information, see [Encrypting archives](encryption-archives.md).

You cannot change the name or source event bus for an archive once it has been created.

**Note**  
Schema discovery is not supported for event buses encrypted using a customer managed key. To enable schema discovery on an event bus, choose to use an AWS owned key. For more information, see [KMS key options](eb-encryption-at-rest-key-options.md).

**To update an archive (console)**

1. Open the Amazon EventBridge console at [https://console.aws.amazon.com/events/](https://console.aws.amazon.com/events/).

1. Navigate to the archive directly, or from the source event bus:
   + In the navigation pane, choose **Event buses**.

     On the events bus details page, choose the **Archives** tab.
   + In the navigation pane, choose **Archives**.

1. Select the archive, and then select **Edit**.

1. Update the archive.

**To update an archive for an event bus (AWS CLI)**
+ Use [update-archive](https://docs.aws.amazon.com/cli/latest/reference/events/update-archive.html).

# Deleting event archives in Amazon EventBridge
<a name="eb-archive-delete"></a>

When you delete an archive, EventBridge deletes the following resources:
+ The archive and any events it contains.
+ The event pattern, if any, specified for the archive.
+ The managed rule EventBridge generated for the archive.

**To delete an archive from an event bus (console)**

1. Open the Amazon EventBridge console at [https://console.aws.amazon.com/events/](https://console.aws.amazon.com/events/).

1. Navigate to the archive directly, or from the source event bus:
   + In the navigation pane, choose **Event buses**.

     On the events bus details page, choose the **Archives** tab.
   + In the navigation pane, choose **Archives**.

1. Choose the event bus that contains the archive you want to delete.

1. On the event bus details page, select the **Archives** tab.

1. Select the archive, and then select **Delete**.

**To delete an archive (AWS CLI)**
+ Use [delete-archive](https://docs.aws.amazon.com/cli/latest/reference/events/delete-archive.html).

# Creating replays of archived events in Amazon EventBridge
<a name="eb-replay-archived-event"></a>

When you start a new replay, you specify a time period for the event you want EventBridge to resend to the source event bus. You can also specify for EventBridge to send the events to specific rules.

**To start an event replay (console)**

1. Open the Amazon EventBridge console at [https://console.aws.amazon.com/events/](https://console.aws.amazon.com/events/).

1. Navigate to the replays directly, or from the archive you want to replay:
   + In the navigation pane, choose **Archives**.

     On the **Archives** page, choose the archive and then choose**Replay**.
   + In the navigation pane, choose **Replays**.

     Choose **Start new replay**.

1. Enter a **Name** for the replay and, optionally, a **Description**.

1. For **Source**, select the archive to replay events from.

1. For destination, you can replay events only to the same event bus that emitted the events.

1. For **Specify rules**, do one of the following:
   + Choose **All rules** to replay events to all rules.
   + Choose **Specify rules**, and then select the rule or rules to replay the events to.

1. Under **Replay time frame**, specify the **Date**, **Time**, and **Time zone** for the **Start time** and the **End time**. 

   Only events that occurred between the **Start time** and **End time** are replayed. 

1. Choose **Start replay**.

**To start a replay (AWS CLI)**
+ Use [start-replay](https://docs.aws.amazon.com/cli/latest/reference/events/start-replay.html).

# Canceling replays of archived events in Amazon EventBridge
<a name="eb-replay-cancel"></a>

If you start a replay and then want to stop it, you can cancel it while its status is `Starting` or `Running`.

**To cancel a replay (console)**

1. Open the Amazon EventBridge console at [https://console.aws.amazon.com/events/](https://console.aws.amazon.com/events/).

1. In the left navigation pane, choose **Replays**.

1. Choose the replay to cancel.

1. Choose **Cancel**.

**To cancel a replay (AWS CLI)**
+ Use [cancel-replay](https://docs.aws.amazon.com/cli/latest/reference/events/cancel-replay.html).

# Making applications Regional-fault tolerant with global endpoints in EventBridge
<a name="eb-global-endpoints"></a>

You can improve your application's availability with Amazon EventBridge global endpoints. Global endpoints help make your application regional-fault tolerant at no additional cost. To start, you assign an Amazon Route 53 health check to the endpoint. When failover is initiated, the health check reports an “unhealthy” state. Within minutes of failover initiation, all custom [events](eb-events.md) are routed to an [event bus](eb-event-bus.md) in the secondary Region and are processed by that event bus. Once the health check reports a “healthy” state, events are processed by the event bus in the primary Region.

When you use global endpoints, you can enable [event replication](#eb-ge-event-replication). Event replication sends all custom events to the event buses in the primary and secondary Regions using managed rules.

**Note**  
If you're using custom buses, you'll need a custom bus in each Region with the same name and in the same account for failover to work properly.

## Recovery Time & Recovery Point Objectives
<a name="eb-ge-rpo-rto"></a>

The Recovery Time Objective (RTO) is the time that it takes for the secondary Region to start receiving events after a failure. For RTO, the time includes time period for triggering CloudWatch alarms and updating statuses for Route 53 health checks. The Recovery Point Objective (RPO) is the measure of the data that will be left unprocessed during a failure. 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. With global endpoints, if you follow our prescriptive guidance for alarm configuration, you can expect the RTO and RPO to be 360 seconds with a maximum of 420 seconds.

## Event replication
<a name="eb-ge-event-replication"></a>

Events are processed in the secondary Region asynchronously. This means that events are not guaranteed to be processed at the same time in both Regions. When failover is triggered, the events are processed by the secondary Region and will be processed by the primary Region when it’s available. Enabling event replication will increase your monthly costs. For more information, see [Amazon EventBridge pricing](https://aws.amazon.com/eventbridge/pricing)

We recommend enabling event replication when setting up global endpoints for the following reasons:
+ Event replication helps you verify that your global endpoints are configured correctly. This helps to ensure that you’ll be covered in the event of failover.
+ Event replication is required to automatically recover from a failover event. If you don’t have event replication enabled, you’ll have to manually reset the Route 53 health check to “healthy” before events will go back to the primary Region.

### Replicated event payload
<a name="eb-ge-event-replication-ep"></a>

The following is an example of a replicated event payload:

**Note**  
For `region`, the Region that the event was replicated from is listed.

```
{
    "version": "0",
    "id": "a908baa3-65e5-ab77-367e-527c0e71bbc2",
    "detail-type": "Test",
    "source": "test.service.com",
    "account": "0123456789",
    "time": "1900-01-01T00:00:00Z",
    "region": "us-east-1",
    "resources": [
        "arn:aws:events:us-east-1:0123456789:endpoint/MyEndpoint"
    ],
    "detail": {
        "a": "b"
    }
}
```

## Working with global endpoints by using an AWS SDK
<a name="eb-ge-sdk-update"></a>

**Note**  
Support for C\$1\$1 is coming soon.

When using an AWS SDK to work with global endpoints, keep the following in mind:
+ You'll need to have the AWS Common Runtime (CRT) library installed for your specific SDK. If you don't have the CRT installed, you'll get an exception message indicating what needs to be installed. For more information, see the following:
  + [AWS Common Runtime (CRT) libraries](https://docs.aws.amazon.com/sdkref/latest/guide/common-runtime.html)
  + [awslabs/aws-crt-java](https://github.com/awslabs/aws-crt-java)
  + [awslabs/aws-crt-nodejs](https://github.com/awslabs/aws-crt-nodejs)
  + [awslabs/aws-crt-python](https://github.com/awslabs/aws-crt-python)
+ Once you have created a global endpoint, you'll need to add the `endpointId` and `EventBusName` to any `PutEvents` calls that you use.
+ Global endpoints support Signature Version 4A. This version of SigV4 allows requests to be signed for multiple AWS Regions. This is useful in API operations that might result in data access from one of several Regions. When using the AWS SDK, you supply your credentials and the requests to global endpoints will use Signature Version 4A without additional configuration. For more information about SigV4A, see [Signing AWS API requests](https://docs.aws.amazon.com/general/latest/gr/signing_aws_api_requests.html ) in the *AWS General Reference*.

  If you request temporary credentials from the global AWS STS endpoint (sts.amazonaws.com), AWS STS vends credentials which, by default, do not support SigV4A. See [Managing AWS STS in an AWS Region](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_enable-regions.html) in the *AWS Identity and Access Management User Guide* for further information.

## Available Regions
<a name="eb-ge-avail-regions"></a>

The following Regions support global endpoints:
+ US East (N. Virginia)
+ US East (Ohio)
+ US West (N. California)
+ US West (Oregon)
+ Canada (Central)
+ Europe (Frankfurt)
+ Europe (Ireland)
+ Europe (London)
+ Europe (Milan)
+ Europe (Paris)
+ Europe (Stockholm)
+ Asia Pacific (Mumbai)
+ Asia Pacific (Osaka)
+ Asia Pacific (Seoul)
+ Asia Pacific (Singapore)
+ Asia Pacific (Sydney)
+ Asia Pacific (Tokyo)
+ South America (São Paulo)

# Creating a global endpoint in Amazon EventBridge
<a name="eb-ge-create-endpoint"></a>

Complete the following steps to set up a global endpoint:

1. Make sure that you have matching event buses and rules in both the primary and secondary Region.

1. Create a [Route 53 health check](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/health-checks-creating.html) to monitor your event buses. For assistance in creating your health check, choose **New Health Check** when creating your global endpoint.

1. Create your global endpoint.

Once you have set up the Route 53 health check, you can create a global endpoint.

## To create a global endpoint by using the console
<a name="eb-ge-create-endpoint-console"></a>

1. Open the Amazon EventBridge console at [https://console.aws.amazon.com/events/](https://console.aws.amazon.com/events/).

1. In the navigation pane, choose **Global endpoints**.

1. Choose **Create Endpoint**.

1. Enter a name and description for the endpoint.

1. For **Event bus in primary Region**, choose the event bus you’d like the endpoint associated with.

1. For **Secondary Region**, choose the Region you'd like to direct events to in the event of a failover.
**Note**  
The **Event bus in secondary Region** is auto-filled and not editable.

1. For **Route 53 health check for triggering failover and recovery**, choose the health check that the endpoint will monitor. If you don't already have a health check, choose **New Health check** to open the CloudFormation console and create a health check using a CloudFormation template.
**Note**  
Missing data will cause the health check to fail. If you only need to send events intermittently, consider using a longer **MinimumEvaluationPeriod**, or treat missing data as 'missing' instead of 'breaching'.

1. (Optional) For **Event replication** do the following:

   1. Select **Event replication enabled**.

   1. For **Execution role**, choose whether to create a new AWS Identity and Access Management role or use an existing one. Do the following:
      + Choose **Create a new role for this specific resource**. Optionally, you can update the **Role name** to create a new role.
      + Choose **Use existing role**. Then, for **Execution role**, choose the desired role to use.

1. Choose **Create**.

## To create a global endpoint by using the API
<a name="eb-ge-create-endpoint-api"></a>

To create a global endpoint using the EventBridge API, see [CreateEndpoint](https://docs.aws.amazon.com/eventbridge/latest/APIReference/API_CreateEndpoint.html) in the Amazon EventBridge API Reference.

## To create a global endpoint by using CloudFormation
<a name="eb-ge-create-endpoint-cfn"></a>

To create a global endpoint using the AWS CloudFormation API, see [AWS::Events::Endpoints](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-events-endpoint.html) in the AWS CloudFormation User Guide.

# Best practices for Amazon EventBridge global endpoints
<a name="eb-ge-best-practices"></a>

The following best practices are recommended when you set up global endpoints.

## Enabling event replication
<a name="eb-ge-bp-enable-replication"></a>

We strongly recommend that you turn on replication and process your events in the secondary Region that you assign to your global endpoint. This ensures that your application in the secondary Region is configured correctly. You should also turn on replication to ensure automatic recovery to the primary Region after an issue has been mitigated.

Event IDs can change across API calls so correlating events across Regions requires you to have an immutable, unique identifier. Consumers should also be designed with idempotency in mind. That way, if you're replicating events, or replaying them from archives, there are no side effects from the events being processed in both Regions.

## Preventing event throttling
<a name="eb-ge-bp-throttling"></a>

To prevent events from being throttled, we recommend updating your `PutEvents` and targets limits so they're consistent across Regions.

## Using subscriber metrics in Amazon Route 53 health checks
<a name="eb-ge-bp-sub-metrics"></a>

Avoid including subscriber metrics in your Amazon Route 53 health checks. Including these metrics may cause your publisher to failover to the secondary Regions if a subscriber encounters an issue despite all other subscribers remaining healthy in the primary Region. If one of your subcribers is failing to process events in the primary Region, you should turn on replication to ensure that your subscriber in the secondary Region can process events successfully.

# Setting up the Route 53 health check for EventBridge global endpoints
<a name="eb-ge-cfn"></a>

When using global endpoints you have to have a Route 53 health check to monitor the status of your Regions. The following template defines a [Amazon CloudWatch alarm](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-cw-alarm.html) and uses it to define a [Route 53 health check](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-route53-healthcheck.html).

**Topics**
+ [CloudFormation template for defining a Route 53 health check](#eb-ge-cfn-template)
+ [CloudWatch alarm template properties](#eb-ge-cfn-cw-alarm-definitions)
+ [Route 53 health check template properties](#eb-ge-cfn-health-check-definitions)

## CloudFormation template for defining a Route 53 health check
<a name="eb-ge-cfn-template"></a>

Use the following template to define your Route 53 health check.

```
Description: |-
  Global endpoints health check that will fail when the average Amazon EventBridge 
  latency is above 30 seconds for a duration of 5 minutes. Note, missing data will 
  cause the health check to fail, so if you only send events intermittently, consider 
  changing the heath check to use a longer evaluation period or instead treat missing 
  data as 'missing' instead of 'breaching'.

Metadata:
  AWS::CloudFormation::Interface:
    ParameterGroups: 
      - Label: 
          default: "Global endpoint health check alarm configuration"
        Parameters:
          - HealthCheckName
          - HighLatencyAlarmPeriod
          - MinimumEvaluationPeriod
          - MinimumThreshold
          - TreatMissingDataAs
    ParameterLabels:
      HealthCheckName:
        default: Health check name
      HighLatencyAlarmPeriod:
        default: High latency alarm period
      MinimumEvaluationPeriod:
        default: Minimum evaluation period
      MinimumThreshold:
        default: Minimum threshold
      TreatMissingDataAs:
        default: Treat missing data as

Parameters:
  HealthCheckName:
    Description: Name of the health check
    Type: String
    Default: LatencyFailuresHealthCheck
  HighLatencyAlarmPeriod:
    Description: The period, in seconds, over which the statistic is applied. Valid values are 10, 30, 60, and any multiple of 60.
    MinValue: 10
    Type: Number
    Default: 60
  MinimumEvaluationPeriod:
    Description: The number of periods over which data is compared to the specified threshold. You must have at least one evaluation period.
    MinValue: 1
    Type: Number
    Default: 5
  MinimumThreshold:
    Description: The value to compare with the specified statistic.
    Type: Number
    Default: 30000
  TreatMissingDataAs:
    Description: Sets how this alarm is to handle missing data points.
    Type: String
    AllowedValues:
      - breaching
      - notBreaching
      - ignore
      - missing
    Default: breaching  

Mappings:
  "InsufficientDataMap":
    "missing":
      "HCConfig": "LastKnownStatus"
    "breaching":
      "HCConfig": "Unhealthy"  

Resources:
  HighLatencyAlarm:
      Type: AWS::CloudWatch::Alarm
      Properties:
        AlarmDescription: High Latency in Amazon EventBridge
        MetricName: IngestionToInvocationStartLatency
        Namespace: AWS/Events
        Statistic: Average
        Period: !Ref HighLatencyAlarmPeriod
        EvaluationPeriods: !Ref MinimumEvaluationPeriod
        Threshold: !Ref MinimumThreshold
        ComparisonOperator: GreaterThanThreshold
        TreatMissingData: !Ref TreatMissingDataAs

  LatencyHealthCheck:
      Type: AWS::Route53::HealthCheck
      Properties:
        HealthCheckTags:
          - Key: Name
            Value: !Ref HealthCheckName
        HealthCheckConfig:
          Type: CLOUDWATCH_METRIC
          AlarmIdentifier:
            Name:
              Ref: HighLatencyAlarm
            Region: !Ref AWS::Region
          InsufficientDataHealthStatus: !FindInMap [InsufficientDataMap, !Ref TreatMissingDataAs, HCConfig]

Outputs:
  HealthCheckId:
    Description: The identifier that Amazon Route 53 assigned to the health check when you created it.
    Value: !GetAtt LatencyHealthCheck.HealthCheckId
```

Event IDs can change across API calls so correlating events across Regions requires you to have an immutable, unique identifier. Consumers should also be designed with idempotency in mind. That way, if you're replicating events, or replaying them from archives, there are no side effects from the events being processed in both Regions.

## CloudWatch alarm template properties
<a name="eb-ge-cfn-cw-alarm-definitions"></a>

**Note**  
For all **editable** fields, consider your throughput per second. If you only send events intermittently, consider changing the heath check to use a longer evaluation period or instead treat missing data as `missing` instead of `breaching`. 

The following properties are used in th CloudWatch alarm section of the template:


| Metric | Description | 
| --- | --- | 
|  `AlarmDescription`  |  The description of the alarm. Default: **High Latency in Amazon EventBridge**  | 
|  `MetricName`  |  The name of the metric associated with the alarm. This is required for an alarm based on a metric. For an alarm based on a math expression, you use `Metrics` instead and you can't specify `MetricName`. Default: IngestionToInvocationStartLatency  | 
|  `Namespace`  |  The namespace of the metric associated with the alarm. This is required for an alarm based on a metric. For an alarm based on a math expression, you can't specify `Namespace` and you use `Metrics` instead. Default: `AWS/Events`  | 
|  `Statistic`  |  The statistic for the metric associated with the alarm, other than percentile. Default: Average  | 
|  `Period`  |  The period, in seconds, over which the statistic is applied. This is required for an alarm based on a metric. Valid values are 10, 30, 60, and any multiple of 60. Default: **60**  | 
|  `EvaluationPeriods`  |  The number of periods over which data is compared to the specified threshold. If you are setting an alarm that requires that a number of consecutive data points be breaching to trigger the alarm, this value specifies that number. If you are setting an "M out of N" alarm, this value is the N, and `DatapointsToAlarm` is the M. Default: **5**  | 
|  `Threshold`  |  The value to compare with the specified statistic. Default: **30,000**  | 
|  `ComparisonOperator`  |  The arithmetic operation to use when comparing the specified statistic and threshold. The specified statistic value is used as the first operand. Default: `GreaterThanThreshold`  | 
|  `TreatMissingData`  |  Sets how this alarm is to handle missing data points. Valid values: `breaching`, `notBreaching`, `ignore`, and `missing` Default: `breaching`  | 

## Route 53 health check template properties
<a name="eb-ge-cfn-health-check-definitions"></a>

**Note**  
For all **editable** fields, consider your throughput per second. If you only send events intermittently, consider changing the heath check to use a longer evaluation period or instead treat missing data as `missing` instead of `breaching`. 

The following properties are used in th Route 53 health check section of the template:


| Metric | Description | 
| --- | --- | 
|  `HealthCheckName`  |  The name of the health check. Default: **LatencyFailuresHealthCheck**  | 
|  `InsufficientDataHealthStatus`  |  When CloudWatch has insufficient data about the metric to determine the alarm state, the status that you want Amazon Route 53 to assign to the health check Valid values: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/eventbridge/latest/userguide/eb-ge-cfn.html) Default: Unhealthy This field is updated based on the input to the `TreatMissingData` field. If `TreatingMissingData` is set to `Missing`, it will be updated to `LastKnownStatus`.If `TreatingMissingData` is set to `Breaching`, it will be updated to `Unhealthy`.  | 

# Configuring logs for Amazon EventBridge event buses
<a name="eb-event-bus-logs"></a>

You can configure EventBridge to send logs detailing how an event bus is processing events, to help with troubleshooting and debugging.

You can select the following AWS services as *log destinations* to which EventBridge delivers logs for the specified event bus:
+ Amazon CloudWatch Logs

  EventBridge delivers logs to the specified CloudWatch Logs log group. 

  Use CloudWatch Logs to centralize the logs from all of your systems, applications, and AWS services that you use, in a single, highly scalable service. For more information, see [Working with log groups and log streams](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Working-with-log-groups-and-streams.html) in the *Amazon CloudWatch Logs User Guide*.
+ Amazon Data Firehose 

  EventBridge delivers logs to a Firehose delivery stream. 

  Amazon Data Firehose is a fully-managed service for delivering real-time streaming data to destinations such as certain AWS services, as well as any custom HTTP endpoint or HTTP endpoints owned by supported third-party service providers. For more information, see [Creating an Amazon Data Firehose delivery stream](https://docs.aws.amazon.com/firehose/latest/dev/basic-create.html) in the *Amazon Data Firehose User Guide*.
+ Amazon S3 

  EventBridge delivers logs as Amazon S3 objects to the specified bucket.

  Amazon S3 is an object storage service that offers industry-leading scalability, data availability, security, and performance. For more information, see [Uploading, downloading, and working with objects in Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/uploading-downloading-objects.html) in the *Amazon Simple Storage Service User Guide*.

## How logging works for event buses
<a name="eb-event-logs-overview"></a>

EventBridge generates logs for: 
+ Any AWS service events that matches a rule on the event bus
+ Any events delivered by the following methods, whether or not the event is ingested successfully or matches any rule:
  + Events from [partner event sources](eb-saas.md)
  + Events [replayed from an archive](eb-archive.md)
  + Events sent to the bus via [`PutEvents`](eb-putevents.md)

EventBridge does not log events that only match [managed rules](eb-rules.md#eb-rules-managed).

The log data sent to each selected log destination is the same.

You can customize the logs EventBridge sends to the selected destinations in the following way:
+ You can specify the *log level*, which determines the steps for which EventBridge sends logs to the selected destinations. For more information, see [Specifying event bus log level](#eb-event-bus-logs-level).
+ You can specify whether EventBridge includes more granular information when relevant, including:
  + Event details
  + Target input information
  + Target request information

  For more information, see [Including detail data in event bus logs](#eb-event-logs-data).

### Log delivery considerations
<a name="eb-event-logs-delivery"></a>

Keep the following considerations in mind as you configure logging for event buses:
+ Event bus log records are delivered on a best effort basis. Most requests for an event bus that is properly configured for logging result in a delivered log record. The completeness and timeliness of event bus logging is not guaranteed. 
+ In some circumstances, delivering event bus log records itself generates events that are then sent to EventBridge, which can lead to disruption in log record delivery. For this reason, EventBridge does not log the following events:
  + AWS KMS `[Decrypt](https://docs.aws.amazon.com/kms/latest/APIReference/API_Decrypt.html)` and `[GenerateDataKey](https://docs.aws.amazon.com/kms/latest/APIReference/API_GenerateDataKey.html)` events generated when log records encrypted using a customer managed key are delivered to a log destination.
  + `[PutRecordBatch](https://docs.aws.amazon.com/firehose/latest/APIReference/API_PutRecordBatch.html)` events in Firehose generated by the delivery of event bus logs.
+ For S3 log destinations, specifying a destination bucket with [event notification for EventBridge](https://docs.aws.amazon.com/AmazonS3/latest/userguide/enable-event-notifications-eventbridge.html) enabled is not recommended, as this can result in disruption in the delivery of your logs.

### Logging encryption
<a name="eb-event-logs-encryption"></a>

When sending logs, EventBridge encrypts the `detail` and `error` sections of each log record with the KMS key specified for the event bus. Once delivered, the record is decrypted and then re-encrypted with the KMS key specified for the log destination.

For more information, see [Encrypting event bus logs](encryption-bus-logs.md).

### Specifying event bus logging permissions
<a name="eb-event-logs-permission"></a>

To enable logging from an event bus, you must grant permissions for EventBridge to send logs from that bus. Add a policy that grants **AllowVendedLogDeliveryForResource** to the event bus.

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "ServiceLevelAccessForLogDelivery",
            "Effect": "Allow",
            "Action": [
                "events:AllowVendedLogDeliveryForResource"
            ],
            "Resource": "arn:aws:events:us-east-1:123456789012:event-bus/my-event-bus*"
        }
    ]
}
```

------

For more information, see [Service-specific permissions](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AWS-logs-and-resource-policy.html#AWS-vended-logs-permissions) in the *CloudWatch Logs User Guide*.

## Specifying event bus log level
<a name="eb-event-bus-logs-level"></a>

You can specify the types of event processing steps which EventBridge logs to the selected log destinations. 

Choose from the following levels of detail to include in logs. The log level applies to all log destinations specified for the event bus. Each log level includes the steps of the previous log levels.
+ **OFF** – EventBridge does not send any logs. This is the default.
+ **ERROR** – EventBridge sends any logs related to errors generated during event processing and target delivery.
+ **INFO** – EventBridge sends any logs related to errors, as well as major steps performed during event processing.
+ **TRACE** – EventBridge sends any logs generated during all steps in the event processing.

The following table lists the event processing steps included in each log level.


| Step | TRACE | INFO | ERROR | OFF | 
| --- | --- | --- | --- | --- | 
|  Event Ingested  | x | x |  |  | 
|  Event Ingestion Failed  | x | x | x |  | 
|  Event Received  | x |  |  |  | 
|  Invocation Attempt Started  | x |  |  |  | 
|  Invocation Attempt Permanent Failure  | x | x | x |  | 
|  Invocation Attempt Retry-able Failure  | x | x | x |  | 
|  Invocation Attempt Succeeded  | x |  |  |  | 
|  Invocation Attempt Throttled  | x | x | x |  | 
|  Invocation DLQ  | x | x | x |  | 
|  Invocation Failed  | x | x | x |  | 
|  Invocation Started  | x | x |  |  | 
|  Invocation Succeeded  | x | x |  |  | 
|  Invocation Throttle Started  | x | x | x |  | 
|  No Rules Matched  | x | x |  |  | 
|  Rule Matched   | x | x |  |  | 
|  Rule Matching Started   | x |  |  |  | 

## Including detail data in event bus logs
<a name="eb-event-logs-data"></a>

You can specify for EventBridge to include more granular information in the logs it generates. This data can be useful for troubleshooting and debugging. If you select this option, EventBridge includes this data in the relevant records for all the specified log destinations.

Detail information includes the following fields: 
+ `event_detail`: The details of the event itself.
+ `target_input`: The request EventBridge sends to the target.
+ `target_properties`: 

## Truncating data in event bus logs
<a name="eb-event-logs-data-truncation"></a>

Due to log destination constraints, EventBridge limits log records to 1 MB. If a log record exceeds this limit, EventBridge truncates the record by removing the following fields in the following order:
+ `target_input`
+ `target_properties`
+ `target_response_body`

EventBridge removes the `event_detail` field from the following log record types if necessary:
+ `EVENT_RECEIVED`
+ `EVENT_INGESTED`
+ `EVENT_INGESTED_FAILED`
+ `RULE_MATCH_STARTED`

If truncation is necessary, EventBridge removes the entire field.

If EventBridge does truncate fields in the event, the `dropped_fields` field includes a list of the excised data fields.

## Error reporting in event bus logs
<a name="eb-event-logs-errors"></a>

EventBridge also includes error data, where available, in steps that represent failure states. These steps include:
+ `EVENT_INGEST_FAILURE`
+ `INVOCATION_THROTTLE_START`
+ `INVOCATION_ATTEMPT_THROTTLE`
+ `INVOCATION_ATTEMPT_RETRYABLE_FAILURE`
+ `INVOCATION_ATTEMPT_PERMANENT_FAILURE`
+ `INVOCATION_FAILURE`
+ `INVOCATION_DLQ`

# What Amazon EventBridge logs for event buses
<a name="eb-event-logs-execution-steps"></a>

Understanding how EventBridge processes events can aid you in using logs to troubleshoot or debug event bus issues.

If logging is enabled, EventBridge generates multiple log records as an event is processed. 

Here are the main steps EventBridge performs when processing an event:
+ An event is sent to an event bus

  EventBridge generates logs for events sent from partner sources, replayed from archives, or sent using `PutEvents`, whether or not they match any rules.
+ EventBridge determines if the event matches any rules on the bus.

  If the event matches one or more rules, EventBridge proceeds to the next step.

  If an AWS event doesn't match any rules, EventBridge discards the event and does not generate any logs.
+ EventBridge invokes the target.

  EventBridge retries invoking the target as necessary until:
  + The event has been successfully delivered.
  + Event delivery fails, such as if the retry policy expires or a permanent failure occurs.

    If delivery fails, EventBridge sends the event to a dead-letter queue (DLQ) if one is specified, or drops the event if no DLQ is specified.

The diagram below presents a detailed view of the event processing flow, with all possible steps represented, along with the log level of each step.

For a complete list of steps, see [Specifying log level](eb-event-bus-logs.md#eb-event-bus-logs-level).

![\[EventBridge proceeds through steps to process each event sent to the bus.\]](http://docs.aws.amazon.com/eventbridge/latest/userguide/images/bus_logging_eventbridge_conceptual.svg)


# Amazon EventBridge event bus log schema
<a name="eb-event-logs-schema"></a>

The following reference details the schema for EventBridge event bus log records. Each record represent a step EventBridge performs processing a specific event.

For more information, see [Logging event buses ](eb-event-bus-logs.md).

```
{    
    "resource\$1arn": "arn:aws:events:region:account:event-bus/bus-name",
    "request\$1id": "guid", 
    "event\$1id": "guid", 
    "invocation\$1id": "guid",
    "message\$1timestamp\$1ms": "date_time",    
    "message\$1type": "step",  
    "log\$1level": "TRACE | INFO | ERROR",
    "details": {
      },
    "error": {  
        "http\$1status\$1code": code,  
        "error\$1message": "error_message",  
        "aws\$1service": "service_name",  
        "request\$1id": "service_request_id"  
    }  
}
```

**resource\$1arn**  <a name="event-log-schema-resource-arn"></a>
The Amazon Resource Name (ARN) for the event bus.

**request\$1id**  <a name="event-log-schema-request-id"></a>
The ID of the request.

**event\$1id**  <a name="event-log-schema-event-id"></a>
The ID of the event being processed.

**invocation\$1id**  <a name="event-log-schema-invocation-id"></a>
The ID of the invocation for the event.

**message\$1timestamp\$1ms**  <a name="event-log-schema-timestamp"></a>
The date and time the log event was emitted.  
Unit: millisecond

**message\$1type**  <a name="event-log-schema-message-type"></a>
The event processing step for which the log record was generated.  
For more information on the steps EventBridge performs when processing an event, see [What Amazon EventBridge logs for event buses](eb-event-logs-execution-steps.md).  
*Valid values:*  
+ `EVENT_INGEST_FAILURE`
+ `EVENT_INGEST_SUCCESS`
+ `EVENT_RECEIPT`
+ `INVOCATION_ATTEMPT_PERMANENT_FAILURE`
+ `INVOCATION_ATTEMPT_RETRYABLE_FAILURE`
+ `INVOCATION_ATTEMPT_START`
+ `INVOCATION_ATTEMPT_SUCCESS`
+ `INVOCATION_ATTEMPT_THROTTLE`
+ `INVOCATION_DLQ`
+ `INVOCATION_FAILURE`
+ `INVOCATION_START`
+ `INVOCATION_SUCCESS`
+ `INVOCATION_THROTTLE_START`
+ `NO_STANDARD_RULES_MATCHED`
+ `RULE_MATCH`
+ `RULE_MATCH_START`

**log\$1level**  <a name="event-log-schema-loglevel"></a>
The level of detail specified for the event bus log.  
*Valid values*: `ERROR` \$1 `INFO` \$1 `TRACE`  
For more information, see [Specifying event bus log level](eb-event-bus-logs.md#eb-event-bus-logs-level).

**details**  <a name="event-log-schema-details"></a>
Contains step details, based on the step detail type.  
The fields listed below are returned for the following message types:  
+ `EVENT_INGEST_SUCCESS`
+ `EVENT_INGEST_FAILURE`
+ `EVENT_RECEIPT`
+ `RULE_MATCH_START`

```
{
  "caller_account_id": "account_id",
  "source_time_ms": date_time,
  "source": "source",
  "detail_type": " type",
  "resources": [],
  "event_detail": "{}"
}
```
The fields listed below are returned for the following message type:  
+ `RULE_MATCH`

```
{
  "rule_arn": "ARN",
  "target_arns": [
    "ARN"
  ],
  "invocation_ids": [
    "guid"
  ]
}
```
The fields listed below are returned for the following message types:  
+ `INVOCATION_ATTEMPT_START`
+ `INVOCATION_START`
+ `INVOCATION_THROTTLE_START`

```
{
  "rule_arn": "ARN",
  "role_arn": "ARN",
  "target_arn": "ARN",
  "attempt_count": Integer,
  "target_input": "string",
  "target_properties": "string"
}
```
The fields listed below are returned for the following message types:  
+ `INVOCATION_DLQ`
+ `INVOCATION_FAILURE`
+ `INVOCATION_SUCCESS`

```
{
  "rule_arn": "ARN",
  "role_arn": "ARN",
  "target_arn": "ARN",
  "target_input": "string",
  "target_properties": "string",
  "total_attempts": Integer,
  "final_invocation_status": "status",
  "ingestion_to_start_latency_ms": Integer,
  "ingestion_to_complete_latency_ms": Integer,
  "ingestion_to_success_latency_ms": Integer,
  "target_duration_ms": Integer,
  "target_response_body": "string"
}
```
The `ingestion_to_start_latency_ms` and `ingestion_to_complete_latency_ms` are only included in the first invocation attempt. The `ingestion_to_success_latency_ms` field is only included for successful invocations.  
The fields listed below are returned for the following message types:  
+ `INVOCATION_ATTEMPT_PERMANENT_FAILURE`
+ `INVOCATION_ATTEMPT_RETRYABLE_FAILURE`
+ `INVOCATION_ATTEMPT_SUCCESS`
+ `INVOCATION_ATTEMPT_THROTTLE`

```
{
  "rule_arn": "ARN",
  "role_arn": "ARN",
  "target_arn": "ARN",
  "attempt_type": "FIRST | THROTTLE | RETRY",
  "attempt_count": Integer,
  "invocation_status": "status",
  "target_duration_ms": Integer,
  "target_response_body": "string"
}
```

**dropped\$1fields**  <a name="event-log-schema-dropped_fields"></a>
A list of any data fields EventBridge has truncated to keep the record below the 1 MB size limitation.  
EventBridge does not include this field if it has truncated any detail fields.  
For more information, see [Truncating data in event bus logs](eb-event-bus-logs.md#eb-event-logs-data-truncation).

**error**  <a name="event-log-schema-error"></a>
Contains information for any error generated during this step. For errors, EV always includes the following fields:  
+ `error_message`
+ `aws_service`
And the following fields if available:  
+ `request_id`
+ `http_status_code`
If no error was generated during this step, EventBridge does not include this field in the log record.    
**http\$1status\$1code**  <a name="event-log-schema-http-status-code"></a>
The HTTP status code returned by the called service.  
**error\$1message**  <a name="event-log-schema-message"></a>
The error message returned by the called service.  
**aws\$1service**  <a name="event-log-schema-aws-service"></a>
The name of the service called.  
**request\$1id**  <a name="event-log-schema-error-request-id"></a>
The request ID for this request from the called service.