# Amazon EventBridge and AWS Identity and Access Management
To access Amazon EventBridge, you need credentials that AWS can use to authenticate your requests. Your credentials must have permissions to access AWS resources, such as retrieving event data from other AWS resources. The following sections provide details on how you can use [AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) and EventBridge to help secure your resources by controlling who can access them.
**Topics**
+ [
## Authentication
](#eb-authentication)
+ [
## Access control
](#eb-access-control)
+ [
# Managing access permissions to your Amazon EventBridge resources
](eb-manage-iam-access.md)
+ [
# Using identity-based policies (IAM policies) for Amazon EventBridge
](eb-use-identity-based.md)
+ [
# Using resource-based policies for Amazon EventBridge
](eb-use-resource-based.md)
+ [
# Cross-service confused deputy prevention in Amazon EventBridge
](cross-service-confused-deputy-prevention.md)
+ [
# Resource-based policies for Amazon EventBridge schemas
](eb-resource-based-schemas.md)
+ [
# Amazon EventBridge permissions reference
](eb-permissions-reference.md)
+ [
# Using IAM policy conditions in Amazon EventBridge
](eb-use-conditions.md)
+ [
# Using service-linked roles for EventBridge
](using-service-linked-roles.md)
## Authentication
You can access AWS as any of the following types of identities:
+ **AWS account root user** – When you sign up for AWS, you provide an email address and password that is associated with your account. These are your *root credentials*, and they provide complete access to all of your AWS resources.
**Important**
For security reasons, we recommend that you use the root credentials only to create an *administrator*, which is an *IAM user* with full permissions to your account. Then you can use this administrator to create other users and roles with limited permissions. For more information, see [IAM Best Practices](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#create-iam-users) and [Creating an Admin User and Group](https://docs.aws.amazon.com/IAM/latest/UserGuide/getting-started_create-admin-group.html) in the *IAM User Guide*.
+ **IAM user** – An [IAM user](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html) is an identity within your account that has specific permissions, for example, permission to send event data to a target in EventBridge. You can use an IAM sign-in credentials to sign in to secure AWS webpages such as the [AWS Management Console](https://console.aws.amazon.com/), [AWS Discussion Forums](https://forums.aws.amazon.com/), or the [AWS Support Center](https://console.aws.amazon.com/support/home#/).
In addition to sign-in credentials, you can also generate [access keys](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html) for each user. You can use these keys when you access AWS services programmatically to cryptographically sign your request, either through [one of the SDKs](https://aws.amazon.com/tools/) or by using the [AWS Command Line Interface (AWS CLI)](https://aws.amazon.com/cli/). If you don’t use AWS tools, you must sign the request yourself with *Signature Version 4*, a protocol for authenticating inbound API requests. For more information about authenticating requests, see [Signature Version 4 Signing Process](https://docs.aws.amazon.com/general/latest/gr/signature-version-4.html) in the *Amazon Web Services General Reference*.
+ **IAM role** – An [IAM role](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) is another IAM identity that you can create in your account that has specific permissions. It's similar to an *IAM user*, but it isn't associated with a specific person. Using an IAM role, you can obtain temporary access keys to access AWS services and resources. IAM roles with temporary credentials are useful in the following situations:
+ **Federated user access** – Instead of creating a user, you can use identities from Directory Service, your enterprise user directory, or a web identity provider (IdP). These are known as *federated users*. AWS assigns a role to a federated user when the user requests access through an [identity provider](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html). For more information about federated users, see [Federated Users and Roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_access-management.html#intro-access-roles) in the *IAM User Guide*.
+ **Cross-account access** – You can use an IAM role in your account to grant another account permission to access your account’s resources. For an example, see [Tutorial: Delegate Access Across AWS Accounts Using IAM Roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html) in the *IAM User Guide*.
+ **AWS service access** – You can use an IAM role in your account to grant an AWS service permission to access your account’s resources. For example, you can create a role that allows Amazon Redshift to load data stored in an Amazon S3 bucket into an Amazon Redshift cluster. For more information, see [Creating a Role to Delegate Permissions to an AWS Service](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html) in the *IAM User Guide*.
+ **Applications running on Amazon EC2** – For Amazon EC2 applications that need access to EventBridge, you can either store access keys in the EC2 instance or you can use an IAM role to manage temporary credentials. To assign an AWS role to an EC2 instance, you create an instance profile that is attached to the instance. An instance profile contains the role, and it provides temporary credentials to applications running on the EC2 instance. For more information, see [Using Roles for Applications on Amazon EC2](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2.html) in the *IAM User Guide*.
## Access control
To create or access EventBridge resources, you need both valid credentials and permissions. For example, to invoke AWS Lambda, Amazon Simple Notification Service (Amazon SNS), and Amazon Simple Queue Service (Amazon SQS) targets, you must have permissions to those services.
# Managing access permissions to your Amazon EventBridge resources
You manage access to EventBridge resources such as [rules](eb-rules.md) or [events](eb-events.md) by using [identity-based](eb-use-identity-based.md) or [resource-based](eb-use-resource-based.md) policies.
## EventBridge resources
EventBridge resources and subresources have unique Amazon Resource Names (ARNs) associated with them. You use ARNs in EventBridge to create event patterns. For more information about ARNs, see [Amazon Resource Names (ARN) and AWS Service Namespaces](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html) in the *Amazon Web Services General Reference*.
For a list of operations EventBridge provides for working with resources, see [Amazon EventBridge permissions reference](eb-permissions-reference.md).
**Note**
Most services in AWS treat a colon (`:`) or a forward slash (`/`) as the same character in ARNs. However, EventBridge uses an exact match in [event patterns](eb-event-patterns.md) and rules. Be sure to use the correct ARN characters when creating event patterns so that they match the ARN syntax in the event that you want to match.
The following table shows the resources in EventBridge.
| Resource Type | ARN Format |
| --- | --- |
| Archive | `arn:aws:events:region:account:archive/archive-name` |
| Replay | `arn:aws:events:region:account:replay/replay-name` |
| Rule | `arn:aws:events:region:account:rule/[event-bus-name]/rule-name` |
| Event bus | `arn:aws:events:region:account:event-bus/event-bus-name` |
| All EventBridge resources | `arn:aws:events:*` |
| All EventBridge resources owned by the specified account in the specified Region | `arn:aws:events:region:account:*` |
The following example shows how to indicate a specific rule (*myRule*) in your statement using its ARN.
```
"Resource": "arn:aws:events:us-east-1:123456789012:rule/myRule"
```
To specify all rules that belong to a specific account by using the asterisk (\$1) wildcard as follows.
```
"Resource": "arn:aws:events:us-east-1:123456789012:rule/*"
```
To specify all resources, or if a specific API action doesn't support ARNs, use the asterisk (\$1) wildcard in the `Resource` element as follows.
```
"Resource": "*"
```
To specify multiple resources or `PutTargets` in a single statement, separate their ARNs with commas as follows.
```
"Resource": ["arn1", "arn2"]
```
## Resource ownership
An account owns the resources in the account, no matter who creates the resources. The resource owner is the account of the *[principal entity](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html)*, the account root user, an IAM user or role that authenticates the request to create the resource. The following examples illustrate how this works:
+ If you use the root user credentials of your account to create a rule, your account is the owner of the EventBridge resource.
+ If you create an user in your account and grant permissions to create EventBridge resources to that user, the user can create EventBridge resources. However, your account, which the user belongs to, owns the EventBridge resources.
+ If you create an IAM role in your account with permissions to create EventBridge resources, anyone who can assume the role can create EventBridge resources. Your account, which the role belongs to, owns the EventBridge resources.
## Managing access to resources
A *permissions policy* describes who has access to what. The following section explains the available options for creating permissions policies.
**Note**
This section discusses using IAM in the context of EventBridge. It doesn't provide detailed information about the IAM service. For complete IAM documentation, see [What is IAM?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) in the *IAM User Guide*. For information about IAM policy syntax and descriptions, see [IAM policy reference](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies.html) in the *IAM User Guide*.
Policies attached to an IAM identity are referred to as *identity-based policies* (IAM policies) and policies attached to a resource are referred to as *resource-based policies*. In EventBridge, you can use both identity-based (IAM policies) and resource-based policies.
**Topics**
+ [
### Identity-based policies (IAM policies)
](#eb-identity-based-policies)
+ [
### Resource-based policies (IAM policies)
](#eb-resource-based-policies-overview)
### Identity-based policies (IAM policies)
You can attach policies to IAM identities. For example, you can do the following:
+ **Attach a permissions policy to a user or a group in your account** – To grant a user permission to view rules in the Amazon CloudWatch console, attach a permissions policy to a user or group that the user belongs to.
+ **Attach a permissions policy to a role (grant cross-account permissions)** – You can attach an identity-based permissions policy to an IAM role to grant cross-account permissions. For example, the administrator in account A can create a role to grant cross-account permissions to another account B or an AWS service as follows:
1. Account A administrator creates an IAM role and attaches a permissions policy to the role that grants permission on resources in account A.
1. Account A administrator attaches a trust policy to the role identifying account B as the principal who can assume the role.
1. Account B administrator can then delegate permissions to assume the role to any users in account B. Doing this allows users in account B to create or access resources in account A. The principal in the trust policy can also be an AWS service principal to grant to an AWS service the permission needed to assume the role.
For more information about using IAM to delegate permissions, see [Access Management](https://docs.aws.amazon.com/IAM/latest/UserGuide/access.html) in the *IAM User Guide*.
You can create specific IAM policies to restrict the calls and resources that users in your account have access to and then attach those policies to users. For more information about how to create IAM roles and to explore example IAM policy statements for EventBridge, see [Managing access permissions to your Amazon EventBridge resources](#eb-manage-iam-access).
### Resource-based policies (IAM policies)
When a rule runs in EventBridge, all of the [targets](eb-targets.md) associated with the rule are invoked, which means invoking the AWS Lambda functions, publishing to the Amazon SNS topics, or relaying the event to the Amazon Kinesis streams. To make API calls on the resources that you own, EventBridge needs the appropriate permission. For Lambda, Amazon SNS, and Amazon SQS resources, EventBridge uses resource-based policies. For Kinesis streams, EventBridge uses IAM roles.
For more information about how to create IAM roles and to explore example resource-based policy statements for EventBridge, see [Using resource-based policies for Amazon EventBridge](eb-use-resource-based.md).
## Specifying policy elements: actions, effects, and principals
For each EventBridge resource, EventBridge defines a set of API operations. To grant permissions for these API operations, EventBridge defines a set of actions that you can specify in a policy. Some API operations require permissions for more than one action to perform the API operation. For more information about resources and API operations, see [EventBridge resources](#eb-arn-format) and [Amazon EventBridge permissions reference](eb-permissions-reference.md).
The following are the basic policy elements:
+ **Resource** – Use an Amazon Resource Name (ARN) to identify the resource that the policy applies to. For more information, see [EventBridge resources](#eb-arn-format).
+ **Action** – Use keywords to identify resource operations that you want to allow or deny. For example, the `events:Describe` permission allows the user to perform the `Describe` operation.
+ **Effect** – Specify either **allow** or **deny**. If you don't explicitly grant access to (allow) a resource, access is denied. You can also explicitly deny access to a resource, which you do to make sure that a user can't access it, even if a different policy grants access.
+ **Principal** – In identity-based policies (IAM policies), the user that the policy is attached to is the implicit principal. For resource-based policies, you specify the user, account, service, or other entity that you want to receive permissions (applies to resource-based policies only).
For more information about IAM policy syntax and descriptions, see [IAM JSON Policy Reference](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies.html) in the *IAM User Guide*.
For information about EventBridge API actions and the resources that they apply to, see [Amazon EventBridge permissions reference](eb-permissions-reference.md).
## Specifying conditions in a policy
When you grant permissions, you can use the access policy language to specify the conditions when a policy should take effect. For example, you might want a policy to be applied only after a specific date. For more information about specifying conditions in a policy language, see [Condition](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) in the *IAM User Guide*.
To define conditions, you use condition keys. There are AWS condition keys and EventBridge specific keys that you can use as appropriate. For a complete list of AWS keys, see [Available Keys for Conditions](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html#AvailableKeys) in the *IAM User Guide*. For a complete list of EventBridge specific keys, see [Using IAM policy conditions in Amazon EventBridge](eb-use-conditions.md).
# Using identity-based policies (IAM policies) for Amazon EventBridge
Identity-based policies are permissions policies that you can attach to IAM identities.
## AWS managed policies for EventBridge
AWS addresses many common use cases by providing standalone IAM policies that are created and administered by AWS. *Managed*, or predefined, policies grant the necessary permissions for common use cases, so you don't need to investigate what permissions are needed. For more information, see [AWS managed policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) in the *IAM User Guide*.
The following AWS managed policies that you can attach to users in your account are specific to EventBridge:
+ [**AmazonEventBridgeFullAccess**](#eb-full-access-policy) – Grants full access to EventBridge, including EventBridge Pipes, EventBridge Schemas and EventBridge Scheduler.
+ [**AmazonEventBridgeReadOnlyAccess**](#eb-read-only-access-policy) – Grants read-only access to EventBridge, including EventBridge Pipes, EventBridge Schemas and EventBridge Scheduler.
## AWS managed policy: AmazonEventBridgeFullAccess
The AmazonEventBridgeFullAccess policy grants permissions to use all EventBridge actions, as well as the following permissions:
+ `iam:CreateServiceLinkedRole` – EventBridge requires this permission to create the service role in your account for API destinations. This permission grants only the IAM service permissions to create a role in your account specifically for API destinations.
+ `iam:PassRole` – EventBridge requires this permission to pass an invocation role to EventBridge to invoke the target of a rule.
+ **Secrets Manager permissions** – EventBridge requires these permissions to manage secrets in your account when you provide credentials through the connection resource to authorize API Destinations.
To view the permissions for this policy, see [ AmazonEventBridgeFullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEventBridgeFullAccess.html) in the *AWS Managed Policy Reference*.
## AWS managed policy: AmazonEventBridgeReadOnlyAccess
The AmazonEventBridgeReadOnlyAccess policy grants permissions to use all read EventBridge actions.
To view the permissions for this policy, see [ AmazonEventBridgeReadOnlyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEventBridgeReadOnlyAccess.html) in the *AWS Managed Policy Reference*.
## AWS managed policy: AmazonEventBridgeApiDestinationsServiceRolePolicy
You can't attach AmazonEventBridgeApiDestinationsServiceRolePolicy to your IAM entities. This policy is attached to a service-linked role that allows EventBridge permissions to access AWS Secrets Manager resources on your behalf.
To view the permissions for this policy, see [ AmazonEventBridgeApiDestinationsServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEventBridgeApiDestinationsServiceRolePolicy.html) in the *AWS Managed Policy Reference*.
## AWS managed policies: EventBridge Schemas
[A schema](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-schema.html) defines the structure of events that are sent to EventBridge. EventBridge provides schemas for all events that are generated by AWS services. The following AWS managed policies specific to EventBridge Schemas are available:
+ [AmazonEventBridgeSchemasFullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEventBridgeSchemasFullAccess.html)
You can attach the AmazonEventBridgeSchemasFullAccess policy to your IAM identities.
Provides full access to EventBridge schemas.
+ [AmazonEventBridgeSchemasReadOnlyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEventBridgeSchemasReadOnlyAccess.html)
You can attach the AmazonEventBridgeSchemasReadOnlyAccess policy to your IAM identities.
Provides read only access to EventBridge Schemas.
+ [AmazonEventBridgeSchemasServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEventBridgeSchemasServiceRolePolicy.html)
You can't attach AmazonEventBridgeSchemasServiceRolePolicy to your IAM entities. This policy is attached to a service-linked role that allows EventBridge permissions to managed rules created by EventBridge schemas.
## AWS managed policies: EventBridge Scheduler
Amazon EventBridge Scheduler is a serverless scheduler that allows you to create, run, and manage tasks from one central, managed service. For AWS managed policies that are specific to EventBridge Scheduler, see [AWS managed policies for EventBridge Scheduler](https://docs.aws.amazon.com/scheduler/latest/UserGuide/security_iam_id-based-policies.html#security_iam_id-based-policies-managed-policies) in the *EventBridge Scheduler User Guide*.
## AWS managed policies: EventBridge Pipes
EventBridge Pipes connects event sources to targets. Pipes reduces the need for specialized knowledge and integration code when developing event driven architectures. This helps ensures consistency across your company’s applications. The following AWS managed policies specific to EventBridge Pipes are available:
+ [AmazonEventBridgePipesFullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEventBridgePipesFullAccess.html)
You can attach the AmazonEventBridgePipesFullAccess policy to your IAM identities.
Provides full access to EventBridge Pipes.
**Note**
This policy provides `iam:PassRole` – EventBridge Pipes requires this permission to pass an invocation role to EventBridge to create, and start pipes.
+ [AmazonEventBridgePipesReadOnlyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEventBridgePipesReadOnlyAccess.html)
You can attach the AmazonEventBridgePipesReadOnlyAccess policy to your IAM identities.
Provides read-only access to EventBridge Pipes.
+ [AmazonEventBridgePipesOperatorAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEventBridgePipesOperatorAccess.html)
You can attach the AmazonEventBridgePipesOperatorAccess policy to your IAM identities.
Provides read-only and operator (that is, the ability to stop and start running Pipes) access to EventBridge Pipes.
## Amazon EventBridge updates to AWS managed policies
View details about updates to AWS managed policies for EventBridge since this service began tracking these changes. For automatic alerts about changes to this page, subscribe to the RSS feed on the EventBridge Document history page.
| Change | Description | Date |
| --- | --- | --- |
| [AmazonEventBridgeApiDestinationsServiceRolePolicy](#api-destination-slr-policy) – Updated policy | EventBridge updated policy to restrict the scope of permissions for Secrets Manager operations to the same account. | May 29, 2025 |
| [AmazonEventBridgeApiDestinationsServiceRolePolicy](#api-destination-slr-policy) – Updated policy | EventBridge updated policy to grant AWS KMS encrypt and decrypt permissions via Secrets Manager. This enables EventBridge to update connection secret resources with new OAuth token value when access token refresh is required. | March 28, 2025 |
| [AmazonEventBridgeFullAccess](#eb-full-access-policy) – Updated policy | AWS GovCloud (US) Regions only The following permission is not included, as it is not used: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/eventbridge/latest/userguide/eb-use-identity-based.html) | May 9, 2024 |
| [AmazonEventBridgeSchemasFullAccess](#eb-schemas-access-policies) – Updated policy | AWS GovCloud (US) Regions only The following permission is not included, as it is not used: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/eventbridge/latest/userguide/eb-use-identity-based.html) | May 9, 2024 |
| [AmazonEventBridgePipesFullAccess](#eb-pipes-access-policies) – New policy added | EventBridge added managed policy for full permissions for using EventBridge Pipes. | December 1, 2022 |
| [AmazonEventBridgePipesReadOnlyAccess](#eb-pipes-access-policies) – New policy added | EventBridge added managed policy for permissions to view EventBridge Pipes information resources. | December 1, 2022 |
| [AmazonEventBridgePipesOperatorAccess](#eb-pipes-access-policies) – New policy added | EventBridge added managed policy for permissions to view EventBridge Pipes information, as well as start and stop running pipes. | December 1, 2022 |
| [AmazonEventBridgeFullAccess](#eb-full-access-policy) – Update to an existing policy | EventBridge updated the policy to include permissions necessary for using EventBridge Pipes features. | December 1, 2022 |
| [AmazonEventBridgeReadOnlyAccess](#eb-read-only-access-policy) – Update to an existing policy | EventBridge added permissions necessary for view EventBridge Pipes information resources. The following actions were added: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/eventbridge/latest/userguide/eb-use-identity-based.html) | December 1, 2022 |
| [CloudWatchEventsReadOnlyAccess](#eb-read-only-access-policy) – Update to an existing policy | Updated to match AmazonEventBridgeReadOnlyAccess. | December 1, 2022 |
| [CloudWatchEventsFullAccess](#eb-full-access-policy) – Update to an existing policy | Updated to match AmazonEventBridgeFullAccess. | December 1, 2022 |
| [AmazonEventBridgeFullAccess](#eb-full-access-policy) – Update to an existing policy | EventBridge updated the policy to include permissions necessary for using schemas and scheduler features. The following permissions were added: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/eventbridge/latest/userguide/eb-use-identity-based.html) | November 10, 2022 |
| [AmazonEventBridgeReadOnlyAccess](#eb-read-only-access-policy) – Update to an existing policy | EventBridge added permissions necessary for view schema and scheduler information resources. The following actions were added: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/eventbridge/latest/userguide/eb-use-identity-based.html) | November 10, 2022 |
| [AmazonEventBridgeReadOnlyAccess](#eb-read-only-access-policy) – Update to an existing policy | EventBridge added permissions necessary for view endpoint information. The following actions were added: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/eventbridge/latest/userguide/eb-use-identity-based.html) | April 7, 2022 |
| [AmazonEventBridgeReadOnlyAccess](#eb-read-only-access-policy) – Update to an existing policy | EventBridge added permissions necessary for view connection and API destination information. The following actions were added: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/eventbridge/latest/userguide/eb-use-identity-based.html) | March 4, 2021 |
| [AmazonEventBridgeFullAccess](#eb-full-access-policy) – Update to an existing policy | EventBridge updated the policy to include `iam:CreateServiceLinkedRole` and AWS Secrets Manager permissions necessary for using API destinations. The following actions were added: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/eventbridge/latest/userguide/eb-use-identity-based.html) | March 4, 2021 |
| EventBridge started tracking changes | EventBridge started tracking changes for its AWS managed policies. | March 4, 2021 |
# IAM roles for sending events to targets in Amazon EventBridge
To relay events to targets, EventBridge needs an IAM role.
**To create an IAM role for sending events to EventBridge**
1. Open the IAM console at [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).
1. To create an IAM role, follow the steps in [Creating a Role to Delegate Permissions to an AWS Service](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html) in the *IAM User Guide* . As you follow the steps, do the following:
+ In **Role Name**, use a name that is unique within your account.
+ In **Select Role Type**, choose **AWS Service Roles**, and then choose **Amazon EventBridge**. This grants EventBridge permissions to assume the role.
+ In **Attach Policy**, choose **AmazonEventBridgeFullAccess**.
You can also create your own custom IAM policies to allow permissions for EventBridge actions and resources. You can attach these custom policies to the IAM users or groups that require those permissions. For more information about IAM policies, see [Overview of IAM Policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) in the *IAM User Guide*. For more information about managing and creating custom IAM policies, see [Managing IAM Policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/ManagingPolicies.html) in the *IAM User Guide*.
## Permissions required for EventBridge to access targets using IAM roles
EventBridge targets typically require IAM roles that grant permission to EventBridge to invoke the target. The following are some examples for various AWS services and targets. For others, use the EventBridge console to create a Rule and create a new Role which will be created with a policy with well-scoped permissions preconfigured.
Amazon SQS, Amazon SNS, Lambda, CloudWatch Logs, and EventBridge bus targets do not use roles, and permissions to EventBridge must be granted via a resource policy. API Gateway targets can use either resource policies or IAM roles.
### API destinations
If the target is an API destination, the role that you specify must include a policy with the following statement:
+ **Effect**: `Allow`
+ **Action**: `events:InvokeApiDestination`
+ **Resource**: `arn:aws:events:*:*:api-destination/*`
### Kinesis streams
If the target is a Kinesis stream, the role used to send event data to that target must include a policy with the following statement:
+ **Effect**: `Allow`
+ **Action**: `kinesis:PutRecord`
+ **Resource**: `*`
### Systems Manager run commands
If the target is Systems Manager run command, and you specify one or more `InstanceIds` values for the command, the role that you specify must include a policy with the following statement:
+ **Effect**: `Allow`
+ **Action**: `ssm:SendCommand`
+ **Resources**: `arn:aws:ec2:us-east-1:accountId:instance/instanceIds`, `arn:aws:ssm:us-east-1:*:document/documentName`
If the target is Systems Manager run command, and you specify one or more tags for the command, the role that you specify must include a policy with the following two actions:
+ **Effect**: `Allow`
+ **Action**: `ssm:SendCommand`
+ **Resources**: `arn:aws:ec2::accountId:instance/*`
+ **Condition:**
```
"StringEquals": {
"ec2:ResourceTag/*": [
"[[tagValues]]"
]
}
```
And:
+ **Effect**: `Allow`
+ **Action**: `ssm:SendCommand`
+ **Resources**: `arn:aws:ssm:us-east-1:*:document/documentName`
### Step Functions state machines
If the target is an AWS Step Functions state machine, the role that you specify must include a policy with the following:
+ **Effect**: `Allow`
+ **Action**: `states:StartExecution`
+ **Resource**: `arn:aws:states:*:*:stateMachine:*`
### Amazon ECS tasks
If the target is an Amazon ECS task, the role that you specify must include the following policy.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ecs:RunTask"
],
"Resource": [
"arn:aws:ecs:*:111122223333:task-definition/task-definition-name"
],
"Condition": {
"ArnLike": {
"ecs:cluster": "arn:aws:ecs:*:111122223333:cluster/cluster-name"
}
}
},
{
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": [
"*"
],
"Condition": {
"StringLike": {
"iam:PassedToService": "ecs-tasks.amazonaws.com"
}
}
}
]
}
```
------
The following policy allows built-in targets in EventBridge to perform Amazon EC2 actions on your behalf. You need to use the AWS Management Console to create rules with built-in targets.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "TargetInvocationAccess",
"Effect": "Allow",
"Action": [
"ec2:Describe*",
"ec2:RebootInstances",
"ec2:StopInstances",
"ec2:TerminateInstances",
"ec2:CreateSnapshot"
],
"Resource": "*"
}
]
}
```
------
The following policy allows EventBridge to relay events to the Kinesis streams in your account.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "KinesisAccess",
"Effect": "Allow",
"Action": [
"kinesis:PutRecord"
],
"Resource": "*"
}
]
}
```
------
## Customer-managed policy example: Using tagging to control access to rules
The following example shows a user policy that grant permissions for EventBridge actions. This policy works when you use the EventBridge API, AWS SDKs, or the AWS CLI.
You can grant users access to specific EventBridge rules while preventing them from accessing other rules. To do so, you tag both sets of rules and then use IAM policies that refer to those tags. For more information about tagging EventBridge resources, see [Tagging resources in Amazon EventBridge](eb-tagging.md).
You can grant an IAM policy to a user to allow access to only the rules with a particular tag. You choose which rules to grant access to by tagging them with that particular tag. For example, the following policy grants a user access to rules with the value of `Prod` for the tag key `Stack`.
```
{
"Statement": [
{
"Effect": "Allow",
"Action": "events:*",
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:ResourceTag/Stack": "Prod"
}
}
}
]
}
```
For more information about using IAM policy statements, see [Controlling Access Using Policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_controlling.html) in the *IAM User Guide*.
# Using resource-based policies for Amazon EventBridge
When a [rule](eb-rules.md) runs in EventBridge, all of the [targets](eb-targets.md) associated with the rule are invoked. Rules can invoke AWS Lambda functions, publish to Amazon SNS topics, or relay the event to Kinesis streams. To make API calls against the resources you own, EventBridge needs the appropriate permissions. For Lambda, Amazon SNS, Amazon SQS, and Amazon CloudWatch Logs resources, EventBridge uses resource-based policies. For Kinesis streams, EventBridge uses [identity-based](eb-use-identity-based.md) policies.
**Important**
For targets that use resource-based policies (Lambda, Amazon SNS, Amazon SQS, and Amazon CloudWatch Logs), do not specify a `RoleArn` in the target configuration. When you specify a `RoleArn` for these target types, event delivery may fail, particularly for Amazon SQS and Amazon SNS targets with AWS KMS encryption enabled. Use resource-based policies only for these targets.
You use the AWS CLI to add permissions to your targets. For information about how to install and configure the AWS CLI, see [Getting Set Up with the AWS Command Line Interface](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-set-up.html) in the *AWS Command Line Interface User Guide*.
**Topics**
+ [
## Amazon API Gateway permissions
](#eb-api-gateway-permissions)
+ [
## CloudWatch Logs permissions
](#eb-cloudwatchlogs-permissions)
+ [
## AWS Lambda permissions
](#eb-lambda-permissions)
+ [
## Amazon SNS permissions
](#eb-sns-permissions)
+ [
## Amazon SQS permissions
](#eb-sqs-permissions)
+ [
## EventBridge Pipes specifics
](#eb-pipes-identity-diff)
## Amazon API Gateway permissions
To invoke your Amazon API Gateway endpoint by using a EventBridge rule, add the following permission to the policy of your API Gateway endpoint.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "events.amazonaws.com"
},
"Action": "execute-api:Invoke",
"Condition": {
"ArnEquals": {
"aws:SourceArn": "arn:aws:events:us-east-1:123456789012:rule/rule-name"
}
},
"Resource": [
"arn:aws:execute-api:us-east-1:123456789012:API-id/stage/GET/api"
]
}
]
}
```
------
## CloudWatch Logs permissions
When CloudWatch Logs is the target of a rule, EventBridge creates log streams, and CloudWatch Logs stores the text from the events as log entries. To allow EventBridge to create the log stream and log the events, CloudWatch Logs must include a resource-based policy that enables EventBridge to write to CloudWatch Logs.
If you use the AWS Management Console to add CloudWatch Logs as the target of a rule, the resource-based policy is created automatically. If you use the AWS CLI to add the target, and the policy doesn't already exist, you must create it.
The following resource-based policy example allows EventBridge to write to all log groups that have names that start with `/aws/events/`. If you use a different naming policy for these types of logs, adjust the resource ARN accordingly.
```
{
"Effect": "Allow",
"Principal": {
"Service": [
"events.amazonaws.com",
"delivery.logs.amazonaws.com"
]
},
"Action": [
"logs:CreateLogStream",
"logs:PutLogEvents"
],
"Resource": "arn:aws:logs:region:account-id:log-group:/aws/events/*:*"
}
```
**To create a resource policy for CloudWatch Logs using the AWS CLI**
+ At a command prompt, enter the following command.
```
aws logs put-resource-policy --policy-name EventBridgeToCWLogsPolicy \
--policy-document '{"Version":"2012-10-17", "Statement":[{"Effect":"Allow","Principal":{"Service":["events.amazonaws.com","delivery.logs.amazonaws.com"]},"Action":["logs:CreateLogStream","logs:PutLogEvents"],"Resource":"arn:aws:logs:region:account-id:log-group:/aws/events/*:*"}]}'
```
For more information, see [PutResourcePolicy](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_PutResourcePolicy.html) in the *CloudWatch Logs API Reference guide*.
## AWS Lambda permissions
To invoke your AWS Lambda function by using a EventBridge rule, add the following permission to the policy of your Lambda function.
```
{
"Effect": "Allow",
"Action": "lambda:InvokeFunction",
"Resource": "arn:aws:lambda:region:account-id:function:function-name",
"Principal": {
"Service": "events.amazonaws.com"
},
"Condition": {
"ArnLike": {
"AWS:SourceArn": "arn:aws:events:region:account-id:rule/rule-name"
}
},
"Sid": "InvokeLambdaFunction"
}
```
**To add the above permissions that enable EventBridge to invoke Lambda functions using the AWS CLI**
+ At a command prompt, enter the following command.
```
aws lambda add-permission --statement-id "InvokeLambdaFunction" \
--action "lambda:InvokeFunction" \
--principal "events.amazonaws.com" \
--function-name "arn:aws:lambda:region:account-id:function:function-name" \
--source-arn "arn:aws:events:region:account-id:rule/rule-name"
```
For more information about setting permissions that enable EventBridge to invoke Lambda functions, see [AddPermission](https://docs.aws.amazon.com/lambda/latest/dg/API_AddPermission.html) and [Using Lambda with Scheduled Events](https://docs.aws.amazon.com/lambda/latest/dg/with-scheduled-events.html) in the *AWS Lambda Developer Guide*.
## Amazon SNS permissions
To allow EventBridge to publish to an Amazon SNS topic, use the `aws sns get-topic-attributes` and the `aws sns set-topic-attributes` commands.
**Note**
You can't use `Condition` blocks in Amazon SNS topic policies for EventBridge.
**To add permissions that enable EventBridge to publish SNS topics**
1. To list the attributes of an SNS topic, use the following command.
```
aws sns get-topic-attributes --topic-arn "arn:aws:sns:region:account-id:topic-name"
```
The following example shows the result of a new SNS topic.
```
{
"Attributes": {
"SubscriptionsConfirmed": "0",
"DisplayName": "",
"SubscriptionsDeleted": "0",
"EffectiveDeliveryPolicy": "{\"http\":{\"defaultHealthyRetryPolicy\":{\"minDelayTarget\":20,\"maxDelayTarget\":20,\"numRetries\":3,\"numMaxDelayRetries\":0,\"numNoDelayRetries\":0,\"numMinDelayRetries\":0,\"backoffFunction\":\"linear\"},\"disableSubscriptionOverrides\":false}}",
"Owner": "account-id",
"Policy": "{\"Version\":\"2012-10-17\", \"Id\":\"__default_policy_ID\",\"Statement\":[{\"Sid\":\"__default_statement_ID\",\"Effect\":\"Allow\",\"Principal\":{\"AWS\":\"*\"},\"Action\":[\"SNS:GetTopicAttributes\",\"SNS:SetTopicAttributes\",\"SNS:AddPermission\",\"SNS:RemovePermission\",\"SNS:DeleteTopic\",\"SNS:Subscribe\",\"SNS:ListSubscriptionsByTopic\",\"SNS:Publish\"],\"Resource\":\"arn:aws:sns:region:account-id:topic-name\",\"Condition\":{\"StringEquals\":{\"AWS:SourceAccount\":\"account-id\"}}}]}",
"TopicArn": "arn:aws:sns:region:account-id:topic-name",
"SubscriptionsPending": "0"
}
}
```
1. Use a [JSON to string converter](https://tools.knowledgewalls.com/jsontostring) to convert the following statement to a string.
```
{
"Sid": "PublishEventsToMyTopic",
"Effect": "Allow",
"Principal": {
"Service": "events.amazonaws.com"
},
"Action": "sns:Publish",
"Resource": "arn:aws:sns:region:account-id:topic-name"
}
```
After you convert the statement to a string, it looks like the following example.
```
{\"Sid\":\"PublishEventsToMyTopic\",\"Effect\":\"Allow\",\"Principal\":{\"Service\":\"events.amazonaws.com\"},\"Action\":\"sns:Publish\",\"Resource\":\"arn:aws:sns:region:account-id:topic-name\"}
```
1. Add the string you created in the previous step to the `"Statement"` collection inside the `"Policy"` attribute.
1. Use the `aws sns set-topic-attributes` command to set the new policy.
```
aws sns set-topic-attributes --topic-arn "arn:aws:sns:region:account-id:topic-name" \
--attribute-name Policy \
--attribute-value "{\"Version\":\"2012-10-17\", \"Id\":\"__default_policy_ID\",\"Statement\":[{\"Sid\":\"__default_statement_ID\",\"Effect\":\"Allow\",\"Principal\":{\"AWS\":\"*\"},\"Action\":[\"SNS:GetTopicAttributes\",\"SNS:SetTopicAttributes\",\"SNS:AddPermission\",\"SNS:RemovePermission\",\"SNS:DeleteTopic\",\"SNS:Subscribe\",\"SNS:ListSubscriptionsByTopic\",\"SNS:Publish\"],\"Resource\":\"arn:aws:sns:region:account-id:topic-name\",\"Condition\":{\"StringEquals\":{\"AWS:SourceAccount\":\"account-id\"}}}, {\"Sid\":\"PublishEventsToMyTopic\",\"Effect\":\"Allow\",\"Principal\":{\"Service\":\"events.amazonaws.com\"},\"Action\":\"sns:Publish\",\"Resource\":\"arn:aws:sns:region:account-id:topic-name\"}]}"
```
For more information, see the [SetTopicAttributes](https://docs.aws.amazon.com/sns/latest/api/API_SetTopicAttributes.html) action in the *Amazon Simple Notification Service API Reference*.
## Amazon SQS permissions
To allow an EventBridge rule to invoke an Amazon SQS queue, use the `aws sqs get-queue-attributes` and `aws sqs set-queue-attributes` commands.
If the policy for the SQS queue is empty, you first need to create a policy and then you can add the permissions statement to it. A new SQS queue has an empty policy.
If the SQS queue already has a policy, you need to copy the original policy and combine it with a new statement to add the permissions statement to it.
**To add permissions that enable EventBridge rules to invoke an SQS queue**
1. To list SQS queue attributes. At a command prompt, enter the following command.
```
aws sqs get-queue-attributes \
--queue-url https://sqs.region.amazonaws.com/account-id/queue-name \
--attribute-names Policy
```
1. Add the following statement.
```
{
"Sid": "AWSEvents_custom-eventbus-ack-sqs-rule_dlq_sqs-rule-target",
"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:rule/bus-name/rule-name"
}
}
}
```
1. Use a [JSON to string converter](https://tools.knowledgewalls.com/jsontostring) to convert the preceding statement into a string. After you convert the policy to a string, it looks like the following.
```
{\"Sid\": \"EventsToMyQueue\", \"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:rule/rule-name\"}}
```
1. Create a file called `set-queue-attributes.json` with the following content.
```
{
"Policy": "{\"Version\":\"2012-10-17\", \"Id\":\"arn:aws:sqs:region:account-id:queue-name/SQSDefaultPolicy\",\"Statement\":[{\"Sid\": \"EventsToMyQueue\", \"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:rule/rule-name\"}}}]}"
}
```
1. Set the policy attribute by using the `set-queue-attributes.json` file you just created as the input, as shown in the following command.
```
aws sqs set-queue-attributes \
--queue-url https://sqs.region.amazonaws.com/account-id/queue-name \
--attributes file://set-queue-attributes.json
```
For more information, see [Amazon SQS Policy Examples](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/SQSExamples.html) in the *Amazon Simple Queue Service Developer Guide*.
## EventBridge Pipes specifics
EventBridge Pipes does not support resource-based policies and has no APIs which support resource based policy conditions.
However, if you configure pipe access through an interface VPC endpoint, that VPC endpoint supports resource policies that enable you to manage access to EventBridge Pipe APIs. For more information, see [Using Amazon EventBridge with Interface VPC endpoints](eb-related-service-vpc.md)
# Cross-service confused deputy prevention in Amazon EventBridge
The confused deputy problem is a security issue where an entity that doesn't have permission to perform an action can coerce a more-privileged entity to perform the action. In AWS, cross-service impersonation can result in the confused deputy problem. Cross-service impersonation can occur when one service (the *calling service*) calls another service (the *called service*). The calling service can be manipulated to use its permissions to act on another customer's resources in a way it should not otherwise have permission to access. To prevent this, AWS provides tools that help you protect your data for all services with service principals that have been given access to resources in your account.
We recommend using the [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn) and [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount) global condition context keys in resource policies to limit the permissions that Amazon EventBridge gives another service to the resource. Use `aws:SourceArn` if you want only one resource to be associated with the cross-service access. Use `aws:SourceAccount` if you want to allow any resource in that account to be associated with the cross-service use.
The most effective way to protect against the confused deputy problem is to use the `aws:SourceArn` global condition context key with the full ARN of the resource. If you don't know the full ARN of the resource or if you are specifying multiple resources, use the `aws:SourceArn` global context condition key with wildcard characters (`*`) for the unknown portions of the ARN. For example, `arn:aws:servicename:*:123456789012:*`.
If the `aws:SourceArn` value does not contain the account ID, such as an Amazon S3 bucket ARN, you must use both global condition context keys to limit permissions.
## Event buses
For EventBridge event bus rule targets, the value of `aws:SourceArn` must be the rule ARN.
The following example shows how you can use the `aws:SourceArn` and `aws:SourceAccount` global condition context keys in EventBridge to prevent the confused deputy problem. This example is for use in a role trust policy, for a role used by an EventBridge rule.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Sid": "ConfusedDeputyPreventionExamplePolicy",
"Effect": "Allow",
"Principal": {
"Service": "events.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"ArnLike": {
"aws:SourceArn": "arn:aws:events:*:123456789012:rule/myRule"
},
"StringEquals": {
"aws:SourceAccount": "123456789012"
}
}
}
}
```
------
## EventBridge Pipes
For EventBridge Pipes, the value of `aws:SourceArn` must be the pipe ARN.
The following example shows how you can use the `aws:SourceArn` and `aws:SourceAccount` global condition context keys in EventBridge to prevent the confused deputy problem. This example is for use in a role trust policy, for a role used by EventBridge Pipes.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Sid": "ConfusedDeputyPreventionExamplePolicy",
"Effect": "Allow",
"Principal": {
"Service": "pipes.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"ArnLike": {
"aws:SourceArn": "arn:aws:pipes:*:123456789012:pipe/example"
},
"StringEquals": {
"aws:SourceAccount": "123456789012"
}
}
}
}
```
------
# Resource-based policies for Amazon EventBridge schemas
The EventBridge [schema registry](eb-schema-registry.md) supports [resource-based policies](eb-use-resource-based.md). A *resource-based policy* is a policy that is attached to a resource rather than to an IAM identity. For example, in Amazon Simple Storage Service (Amazon S3), a resource policy is attached to an Amazon S3 bucket.
For more information about EventBridge Schemas and resource-based policies, see the following.
+ [Amazon EventBridge Schemas REST API Reference](https://docs.aws.amazon.com/eventbridge/latest/schema-reference/what-is-eventbridge-schemas.html)
+ [Identity-Based Policies and Resource-Based Policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_identity-vs-resource.html) in the IAM User Guide
## Supported APIs for resource-based policies
You can use the following APIs with resource-based policies for the EventBridge schema registry.
+ `DescribeRegistry`
+ `UpdateRegistry`
+ `DeleteRegistry`
+ `ListSchemas`
+ `SearchSchemas`
+ `DescribeSchema`
+ `CreateSchema`
+ `DeleteSchema`
+ `UpdateSchema`
+ `ListSchemaVersions`
+ `DeleteSchemaVersion`
+ `DescribeCodeBinding`
+ `GetCodeBindingSource`
+ `PutCodeBinding`
## Example policy granting all supported actions to an AWS account
For the EventBridge schema registry, you must always attach a resource-based policy to a registry. To grant access to a schema, you specify the schema ARN and the registry ARN in the policy.
To grant a user access to all available APIs for EventBridge Schemas, use a policy similar to the following, replacing the `"Principal"` with the account ID of the account you want to grant access.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "Test",
"Effect": "Allow",
"Action": [
"schemas:*"
],
"Principal": {
"AWS": [
"109876543210"
]
},
"Resource": [
"arn:aws:schemas:us-east-1:012345678901:registry/default",
"arn:aws:schemas:us-east-1:012345678901:schema/default*"
]
}
]
}
```
------
## Example policy granting read-only actions to an AWS account
The following example grants access to an account for only the read-only APIs for EventBridge schemas.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "Test",
"Effect": "Allow",
"Action": [
"schemas:DescribeRegistry",
"schemas:ListSchemas",
"schemas:SearchSchemas",
"schemas:DescribeSchema",
"schemas:ListSchemaVersions",
"schemas:DescribeCodeBinding",
"schemas:GetCodeBindingSource"
],
"Principal": {
"AWS": [
"109876543210"
]
},
"Resource": [
"arn:aws:schemas:us-east-1:012345678901:registry/default",
"arn:aws:schemas:us-east-1:012345678901:schema/default*"
]
}
]
}
```
------
## Example policy granting all actions to an organization
You can use resource-based policies with the EventBridge schema registry to grant access to an organization. For more information, see the [AWS Organizations User Guide](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html). The following example grants organization with an ID of `o-a1b2c3d4e5` access to the schema registry.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "Test",
"Effect": "Allow",
"Action": [
"schemas:*"
],
"Principal": "*",
"Resource": [
"arn:aws:schemas:us-east-1:012345678901:registry/default",
"arn:aws:schemas:us-east-1:012345678901:schema/default*"
],
"Condition": {
"StringEquals": {
"aws:PrincipalOrgID": [
"o-a1b2c3d4e5"
]
}
}
}
]
}
```
------
# Amazon EventBridge permissions reference
To specify an action in an EventBridge policy, use the `events:` prefix followed by the API operation name, as shown in the following example.
```
"Action": "events:PutRule"
```
To specify multiple actions in a single statement, separate them with commas as follows.
```
"Action": ["events:action1", "events:action2"]
```
To specify multiple actions, you can also use wildcards. For example, you can specify all actions that begin with the word `"Put"` as follows.
```
"Action": "events:Put*"
```
To specify all EventBridge API actions, use the `*` wildcard as follows.
```
"Action": "events:*"
```
The following table lists the EventBridge API operations and corresponding actions that you can specify in an IAM policy.
| EventBridge API operation | Required permissions | Description |
| --- | --- | --- |
| [DeleteRule](https://docs.aws.amazon.com/eventbridge/latest/APIReference/API_DeleteRule.html) | `events:DeleteRule` | Required to delete a rule. |
| [DescribeEventBus](https://docs.aws.amazon.com/eventbridge/latest/APIReference/API_DescribeEventBus.html) | `events:DescribeEventBus` | Required to list accounts that are allowed to write events to the current account's event bus. |
| [DescribeRule](https://docs.aws.amazon.com/eventbridge/latest/APIReference/API_DescribeRule.html) | `events:DescribeRule` | Required to list the details about a rule. |
| [DisableRule](https://docs.aws.amazon.com/eventbridge/latest/APIReference/API_DisableRule.html) | `events:DisableRule` | Required to disable a rule. |
| [EnableRule](https://docs.aws.amazon.com/eventbridge/latest/APIReference/API_EnableRule.html) | `events:EnableRule` | Required to enable a rule. |
| [ListRuleNamesByTarget](https://docs.aws.amazon.com/eventbridge/latest/APIReference/API_ListRuleNamesByTarget.html) | `events:ListRuleNamesByTarget` | Required to list rules associated with a target. |
| [ListRules](https://docs.aws.amazon.com/eventbridge/latest/APIReference/API_ListRules.html) | `events:ListRules` | Required to list all rules in your account. |
| [ListTagsForResource](https://docs.aws.amazon.com/eventbridge/latest/APIReference/API_ListTagsForResource.html) | `events:ListTagsForResource` | Required to list all tags associated with an EventBridge resource. Currently, only rules can be tagged. |
| [ListTargetsByRule](https://docs.aws.amazon.com/eventbridge/latest/APIReference/API_ListTargetsByRule.html) | `events:ListTargetsByRule` | Required to list all targets associated with a rule. |
| [PutEvents](https://docs.aws.amazon.com/eventbridge/latest/APIReference/API_PutEvents.html) | `events:PutEvents` | Required to add custom events that can be matched to rules. |
| [PutPermission](https://docs.aws.amazon.com/eventbridge/latest/APIReference/API_PutPermission.html) | `events:PutPermission` | Required to give another account permission to write events to this account’s default event bus. |
| [PutRule](https://docs.aws.amazon.com/eventbridge/latest/APIReference/API_PutRule.html) | `events:PutRule` | Required to create or update a rule. |
| [PutTargets](https://docs.aws.amazon.com/eventbridge/latest/APIReference/API_PutTargets.html) | `events:PutTargets` | Required to add targets to a rule. |
| [RemovePermission](https://docs.aws.amazon.com/eventbridge/latest/APIReference/API_RemovePermission.html) | `events:RemovePermission` | Required to revoke another account’s permissions for writing events to this account’s default event bus. |
| [RemoveTargets](https://docs.aws.amazon.com/eventbridge/latest/APIReference/API_RemoveTargets.html) | `events:RemoveTargets` | Required to remove a target from a rule. |
| [TestEventPattern](https://docs.aws.amazon.com/eventbridge/latest/APIReference/API_TestEventPattern.html) | `events:TestEventPattern` | Required to test an event pattern against a given event. |
# Using IAM policy conditions in Amazon EventBridge
To grant permissions, you use the IAM policy language in a policy statement to specify the conditions when a policy should take effect. For example, you can have a policy that is applied only after a specific date.
A condition in a policy consists of key-value pairs. Condition keys aren't case sensitive.
If you specify multiple conditions or keys in a single condition, all conditions and keys must be met for EventBridge to grant permission. If you specify a single condition with multiple values for one key, EventBridge grants permission if one of the values is met.
You can use placeholders or *policy variables* when you specify conditions. For more information, see [Policy Variables](https://docs.aws.amazon.com/IAM/latest/UserGuide/policyvariables.html) in the *IAM User Guide*. For more information about specifying conditions in an IAM policy language, see [Condition](https://docs.aws.amazon.com/IAM/latest/UserGuide/AccessPolicyLanguage_ElementDescriptions.html#Condition) in the *IAM User Guide*.
By default, IAM users and roles can't access the [events](eb-events.md) in your account. To access events, a user must be authorized for the `PutRule` API action. If an IAM user or role is authorized for the `events:PutRule` action, they can create a [rule](eb-rules.md) that matches certain events. However, for the rule to be useful, the user must also have permissions for the `events:PutTargets` action because, if you want the rule to do more than publish a CloudWatch metric, you must also add a [target](eb-targets.md) to a rule.
You can provide a condition in the policy statement of an IAM user or role that allows the user or role to create a rule that only matches a specific set of sources and event types. To grant access to specific sources and types of events, use the `events:source` and `events:detail-type` condition keys.
Similarly, you can provide a condition in the policy statement of an IAM user or role that allows the user or role to create a rule that only matches a specific resource in your accounts. To grant access to a specific resource, use the `events:TargetArn` condition key.
## EventBridge condition keys
The following table shows the condition keys and key and value pairs that you can use in a policy in EventBridge.
| Condition key | Key value pair | Evaluation types |
| --- | --- | --- |
| aws:SourceAccount | The account in which the rule specified by `aws:SourceArn` exists. | Account Id, Null |
| aws:SourceArn | The ARN of the rule that is sending the event. | ARN, Null |
| events:creatorAccount | `"events:creatorAccount":"creatorAccount"` For *creatorAccount*, use the account ID for the account that created the rule. Use this condition to authorize API calls on rules from a specific account. | creatorAccount, Null |
| events:detail-type | `"events:detail-type":"detail-type "` Where *detail-type* is the literal string for the **detail-type** field of the event such as `"AWS API Call via CloudTrail"` and `"EC2 Instance State-change Notification"`. | Detail Type, Null |
| events: detail.eventTypeCode | `"events:detail.eventTypeCode":"eventTypeCode"` For *eventTypeCode*, use the literal string for the **detail.eventTypeCode** field of the event, such as `"AWS_ABUSE_DOS_REPORT"`. | eventTypeCode, Null |
| events: detail.service | `"events:detail.service":"service"` For *service*, use the literal string for the **detail.service** field of the event, such as `"ABUSE"`. | service, Null |
| events: detail.userIdentity.principalId | `"events:detail.userIdentity.principalId":"principal-id"` For *principal-id*, use the literal string for the **detail.userIdentity.principalId** field of the event with detail-type `"AWS API Call via CloudTrail"` such as `"AROAIDPPEZS35WEXAMPLE:AssumedRoleSessionName."`. | Principal Id, Null |
| events:eventBusInvocation | `"events:eventBusInvocation":"boolean"` For *boolean*, use true when a rule sends an event to a target that is an event bus in another account. Use false when when a `PutEvents` API call is used. | eventBusInvocation, Null |
| events:ManagedBy | Used internally by AWS services. For a rule created by an AWS service on your behalf, the value is the principal name of the service that created the rule. | Not intended for use in customer policies. |
| events:source | `"events:source":"source "` Use *source* for the literal string for the source field of the event such as `"aws.ec2"` or `"aws.s3"`. For more possible values for *source*, see the example events in [Events from AWS services](eb-events.md#eb-service-event). | Source, Null |
| events:TargetArn | `"events:TargetArn":"target-arn "` For *target-arn*, use the ARN of the target for the rule, for example `"arn:aws:lambda:*:*:function:*"`. | ArrayOfARN, Null |
For example policy statements for EventBridge, see [Managing access permissions to your Amazon EventBridge resources](eb-manage-iam-access.md).
**Topics**
+ [
## EventBridge condition keys
](#conditions-table)
+ [
## EventBridge Pipes specifics
](#eb-pipes-condition-diff)
+ [
## Example: Using the `creatorAccount` condition
](#eb-events-creator-account)
+ [
## Example: Using the `eventBusInvocation` condition
](#eb-events-bus-invocation)
+ [
## Example: Limiting access to a specific source
](#eb-events-limit-access-control)
+ [
## Example: Defining multiple sources that can be used in an event pattern individually
](#eb-events-pattern-sources)
+ [
## Example: Ensuring that the source is defined in the event pattern
](#eb-source-defined-events-pattern)
+ [
## Example: Defining a list of allowed sources in an event pattern with multiple sources
](#eb-allowed-sources-events-pattern)
+ [
## Example: Limiting `PutRule` access by `detail.service`
](#eb-limit-rule-by-service)
+ [
## Example: Limiting `PutRule` access by `detail.eventTypeCode`
](#eb-limit-rule-by-type-code)
+ [
## Example: Ensuring that only AWS CloudTrail events for API calls from a certain `PrincipalId` are allowed
](#eb-consume-specific-events)
+ [
## Example: Limiting access to targets
](#eb-limiting-access-to-targets)
## EventBridge Pipes specifics
EventBridge Pipes does not support any additional IAM policy condition keys.
## Example: Using the `creatorAccount` condition
The following example policy statement shows how to use the `creatorAccount` condition in a policy to only allow rules to be created if the account specified as the `creatorAccount` is the account that created the rule.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowPutRuleForOwnedRules",
"Effect": "Allow",
"Action": "events:PutRule",
"Resource": "*",
"Condition": {
"StringEqualsIfExists": {
"events:creatorAccount": "${aws:PrincipalAccount}"
}
}
}
]
}
```
------
## Example: Using the `eventBusInvocation` condition
The `eventBusInvocation` indicates whether the invocation originates from a cross-account target or a `PutEvents` API request. The value is **true** when the invocation results from a rule that include a cross-account target, such as when the target is an event bus in another account. The value is **false** when the invocation results from a `PutEvents` API request. The following example indicates an invocation from a cross-account target.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowCrossAccountInvocationEventsOnly",
"Effect": "Allow",
"Action": "events:PutEvents",
"Resource": "*",
"Condition": {
"BoolIfExists": {
"events:eventBusInvocation": "true"
}
}
}
]
}
```
------
## Example: Limiting access to a specific source
The following example policies can be attached to an IAM user. Policy A allows the `PutRule` API action for all events, whereas Policy B allows `PutRule` only if the event pattern of the rule being created matches Amazon EC2 events.
**Policy A: allow all events**
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowPutRuleForAllEvents",
"Effect": "Allow",
"Action": "events:PutRule",
"Resource": "*"
}
]
}
```
------
**Policy B:—allow events only from Amazon EC2**
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowPutRuleForAllEC2Events",
"Effect": "Allow",
"Action": "events:PutRule",
"Resource": "*",
"Condition": {
"ForAllValues:StringEquals": {
"events:source": "aws.ec2"
}
}
}
]
}
```
------
`EventPattern` is a mandatory argument to `PutRule`. Hence, if the user with Policy B calls `PutRule` with an event pattern like the following.
```
{
"source": [ "aws.ec2" ]
}
```
The rule would be created because the policy allows for this specific source: that is, `"aws.ec2"`. However, if the user with Policy B calls `PutRule` with an event pattern like the following, the rule creation would be denied because the policy doesn't allow for this specific source: that is, `"aws.s3"`.
```
{
"source": [ "aws.s3" ]
}
```
Essentially, the user with Policy B is only allowed to create a rule that would match the events originating from Amazon EC2; hence, they're only allowed access to the events from Amazon EC2.
See the following table for a comparison of Policy A and Policy B.
| Event Pattern | Allowed by Policy A | Allowed by Policy B |
| --- | --- | --- |
| {
"source": [ "aws.ec2" ]
} | Yes | Yes |
| {
"source": [ "aws.ec2", "aws.s3" ]
} | Yes | No (Source aws.s3 isn't allowed) |
| {
"source": [ "aws.ec2" ],
"detail-type": [ "EC2 Instance State-change Notification" ]
} | Yes | Yes |
| {
"detail-type": [ "EC2 Instance State-change Notification" ]
} | Yes | No (Source must be specified) |
## Example: Defining multiple sources that can be used in an event pattern individually
The following policy allows an IAM user or role to create a rule where the source in the `EventPattern` is either Amazon EC2 or Amazon ECS.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowPutRuleIfSourceIsEC2OrECS",
"Effect": "Allow",
"Action": "events:PutRule",
"Resource": "*",
"Condition": {
"ForAllValues:StringEquals": {
"events:source": [
"aws.ec2",
"aws.ecs"
]
}
}
}
]
}
```
------
The following table shows some examples of event patterns that are allowed or denied by this policy.
| Event pattern | Allowed by the policy |
| --- | --- |
| {
"source": [ "aws.ec2" ]
} | Yes |
| {
"source": [ "aws.ecs" ]
} | Yes |
| {
"source": [ "aws.s3" ]
} | No |
| {
"source": [ "aws.ec2", "aws.ecs" ]
} | No |
| {
"detail-type": [ "AWS API Call via CloudTrail" ]
} | No |
## Example: Ensuring that the source is defined in the event pattern
The following policy allows users to only create rules with `EventPatterns` that have the source field. With this policy, an IAM user or role can't create a rule with an `EventPattern` that doesn't provide a specific source.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowPutRuleIfSourceIsSpecified",
"Effect": "Allow",
"Action": "events:PutRule",
"Resource": "*",
"Condition": {
"Null": {
"events:source": "false"
}
}
}
]
}
```
------
The following table shows some examples of event patterns that are allowed or denied by this policy.
| Event Pattern | Allowed by the Policy |
| --- | --- |
| {
"source": [ "aws.ec2" ],
"detail-type": [ "EC2 Instance State-change Notification" ]
} | Yes |
| {
"source": [ "aws.ecs", "aws.ec2" ]
} | Yes |
| {
"detail-type": [ "EC2 Instance State-change Notification" ]
} | No |
## Example: Defining a list of allowed sources in an event pattern with multiple sources
The following policy allows users to create rules with `EventPatterns` that have multiple sources in them. Each source in the event pattern must be a member of the list provided in the condition. When you use the `ForAllValues` condition, make sure that at least one of the items in the condition list is defined.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowPutRuleIfSourceIsSpecifiedAndIsEitherS3OrEC2OrBoth",
"Effect": "Allow",
"Action": "events:PutRule",
"Resource": "*",
"Condition": {
"ForAllValues:StringEquals": {
"events:source": [ "aws.ec2", "aws.s3" ]
},
"Null": {
"events:source": "false"
}
}
}
]
}
```
------
The following table shows some examples of event patterns that are allowed or denied by this policy.
| Event Pattern | Allowed by the Policy |
| --- | --- |
| {
"source": [ "aws.ec2" ]
} | Yes |
| {
"source": [ "aws.ec2", "aws.s3" ]
} | Yes |
| {
"source": [ "aws.ec2", "aws.autoscaling" ]
} | No |
| {
"detail-type": [ "EC2 Instance State-change Notification" ]
} | No |
## Example: Limiting `PutRule` access by `detail.service`
You can restrict an IAM user or role to creating rules only for events that have a certain value in the `events:details.service` field. The value of `events:details.service` isn't necessarily the name of an AWS service.
This policy condition is helpful when you work with events from AWS Health that relate to security or abuse. By using this policy condition, you can limit access to these sensitive alerts to only those users who need to see them.
For example, the following policy allows the creation of rules only for events where the value of `events:details.service` is `ABUSE`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowPutRuleEventsWithDetailServiceEC2",
"Effect": "Allow",
"Action": "events:PutRule",
"Resource": "*",
"Condition": {
"StringEquals": {
"events:detail.service": "ABUSE"
}
}
}
]
}
```
------
## Example: Limiting `PutRule` access by `detail.eventTypeCode`
You can restrict an IAM user or role to creating rules only for events that have a certain value in the `events:details.eventTypeCode` field. This policy condition is helpful when you work with events from AWS Health that relate to security or abuse. By using this policy condition, you can limit access to these sensitive alerts to only those users who need to see them.
For example, the following policy allows the creation of rules only for events where the value of `events:details.eventTypeCode` is `AWS_ABUSE_DOS_REPORT`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowPutRuleEventsWithDetailServiceEC2",
"Effect": "Allow",
"Action": "events:PutRule",
"Resource": "*",
"Condition": {
"StringEquals": {
"events:detail.eventTypeCode": "AWS_ABUSE_DOS_REPORT"
}
}
}
]
}
```
------
## Example: Ensuring that only AWS CloudTrail events for API calls from a certain `PrincipalId` are allowed
All AWS CloudTrail events have the PrincipalId of the user who made the API call in the `detail.userIdentity.principalId` path of an event. Using the `events:detail.userIdentity.principalId` condition key, you can limit the access of IAM users or roles to the CloudTrail events for only those coming from a specific account.
```
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowPutRuleOnlyForCloudTrailEventsWhereUserIsASpecificIAMUser",
"Effect": "Allow",
"Action": "events:PutRule",
"Resource": "*",
"Condition": {
"StringEquals": {
"events:detail-type": [ "AWS API Call via CloudTrail" ],
"events:detail.userIdentity.principalId": [ "AIDAJ45Q7YFFAREXAMPLE" ]
}
}
}
]
}
```
The following table shows some examples of event patterns that are allowed or denied by this policy.
| Event pattern | Allowed by the policy |
| --- | --- |
| {
"detail-type": [ "AWS API Call via CloudTrail" ]
} | No |
| {
"detail-type": [ "AWS API Call via CloudTrail" ],
"detail.userIdentity.principalId": [ "AIDAJ45Q7YFFAREXAMPLE" ]
} | Yes |
| {
"detail-type": [ "AWS API Call via CloudTrail" ],
"detail.userIdentity.principalId": [ "AROAIDPPEZS35WEXAMPLE:AssumedRoleSessionName" ]
} | No |
## Example: Limiting access to targets
If an IAM user or role has `events:PutTargets` permission, they can add any target under the same account to the rules that they are allowed to access. The following policy limits users to adding targets to only a specific rule: `MyRule` under account `123456789012`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowPutTargetsOnASpecificRule",
"Effect": "Allow",
"Action": "events:PutTargets",
"Resource": "arn:aws:events:us-east-1:123456789012:rule/MyRule"
}
]
}
```
------
To limit what target can be added to the rule, use the `events:TargetArn` condition key. You can limit targets to only Lambda functions, as in the following example.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowPutTargetsOnASpecificRuleAndOnlyLambdaFunctions",
"Effect": "Allow",
"Action": "events:PutTargets",
"Resource": "arn:aws:events:us-east-1:123456789012:rule/rule-name",
"Condition": {
"ForAnyValue:ArnLike": {
"events:TargetArn": "arn:aws:lambda:*:*:function:*"
}
}
}
]
}
```
------
# Using service-linked roles for EventBridge
Amazon EventBridge uses AWS Identity and Access Management (IAM) [service-linked roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-linked-role). A service-linked role is a unique type of IAM role that is linked directly to EventBridge. Service-linked roles are predefined by EventBridge and include all the permissions that the service requires to call other AWS services on your behalf.
A service-linked role makes setting up EventBridge easier because you don’t have to manually add the necessary permissions. EventBridge defines the permissions of its service-linked roles, and unless defined otherwise, only EventBridge can assume its roles. The defined permissions include the trust policy and the permissions policy, and that permissions policy cannot be attached to any other IAM entity.
You can delete a service-linked role only after first deleting their related resources. This protects your EventBridge resources because you can't inadvertently remove permission to access the resources.
For information about other services that support service-linked roles, see [AWS services that work with IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) and look for the services that have **Yes** in the **Service-linked roles** column. Choose a **Yes** with a link to view the service-linked role documentation for that service.
# Using roles to create secrets for API destinations in EventBridge
The following topic details usage of the ****AWSServiceRoleForAmazonEventBridgeApiDestinations**** service-linked role.
## Service-linked role permissions for EventBridge
EventBridge uses the service-linked role named ****AWSServiceRoleForAmazonEventBridgeApiDestinations**** – Enables access to the Secrets Manager Secrets created by EventBridge.
The **AWSServiceRoleForAmazonEventBridgeApiDestinations** service-linked role trusts the following services to assume the role:
+ `apidestinations.events.amazonaws.com`
The role permissions policy named **AmazonEventBridgeApiDestinationsServiceRolePolicy** allows EventBridge to complete the following actions on the specified resources:
+ Action: `create, describe, update and delete secrets; get and put secret values` on `secrets created for all connections by EventBridge`
You must configure permissions to allow your users, groups, or roles to create, edit, or delete a service-linked role. For more information, see [Service-linked role permissions](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions) in the *IAM User Guide*.
## Creating a service-linked role for EventBridge
You don't need to manually create a service-linked role. When you create a connection in the AWS Management Console, the AWS CLI, or the AWS API, EventBridge creates the service-linked role for you.
**Important**
This service-linked role can appear in your account if you completed an action in another service that uses the features supported by this role. If you were using the EventBridge service before February 11, 2021, when it began supporting service-linked roles, then EventBridge created the **AWSServiceRoleForAmazonEventBridgeApiDestinations** role in your account. To learn more, see [A new role appeared in my AWS account](https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_roles.html#troubleshoot_roles_new-role-appeared).
If you delete this service-linked role, and then need to create it again, you can use the same process to recreate the role in your account. When you create a connection, EventBridge creates the service-linked role for you again.
## Editing a service-linked role for EventBridge
EventBridge does not allow you to edit the **AWSServiceRoleForAmazonEventBridgeApiDestinations** service-linked role. After you create a service-linked role, you cannot change the name of the role because various entities might reference the role. However, you can edit the description of the role using IAM. For more information, see [Editing a service-linked role](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role) in the *IAM User Guide*.
## Deleting a service-linked role for EventBridge
If you no longer need to use a feature or service that requires a service-linked role, we recommend that you delete that role. That way you don’t have an unused entity that is not actively monitored or maintained. However, you must clean up your service-linked role before you can manually delete it.
### Cleaning up a service-linked role
Before you can use IAM to delete a service-linked role, you must first delete any resources used by the role.
**Note**
If the EventBridge service is using the role when you try to delete the resources, then the deletion might fail. If that happens, wait for a few minutes and try the operation again.
**To delete EventBridge resources used by the **AWSServiceRoleForAmazonEventBridgeApiDestinations** (console)**
1. Open the Amazon EventBridge console at [https://console.aws.amazon.com/events/](https://console.aws.amazon.com/events/).
1. Under **Integrations** choose **API destinations**, then choose the **Connections** tab.
1. Choose the connection, then choose **Delete**.
**To delete EventBridge resources used by the **AWSServiceRoleForAmazonEventBridgeApiDestinations** (AWS CLI)**
+ Use the following command: `[delete-connection](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/events/delete-connection.html)`.
**To delete EventBridge resources used by the **AWSServiceRoleForAmazonEventBridgeApiDestinations** (API)**
+ Use the following command: `[DeleteConnection](https://docs.aws.amazon.com/eventbridge/latest/APIReference/API_DeleteConnection.html)`.
### Manually delete the service-linked role
Use the IAM console, the AWS CLI, or the AWS API to delete the **AWSServiceRoleForAmazonEventBridgeApiDestinations** service-linked role. For more information, see [Deleting a service-linked role](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role) in the *IAM User Guide*.
## Supported Regions for EventBridge service-linked roles
EventBridge supports using service-linked roles in all of the Regions where the service is available. For more information, see [AWS Regions and endpoints](https://docs.aws.amazon.com/general/latest/gr/rande.html).
# Using roles for schema discovery in Amazon EventBridge
The following topic details usage of the ****AWSServiceRoleForSchemas**** service-linked role.
## Service-linked role permissions for EventBridge
EventBridge uses the service-linked role named ****AWSServiceRoleForSchemas**** – Grants permissions to Managed Rules created by Amazon EventBridge schemas..
The **AWSServiceRoleForSchemas** service-linked role trusts the following services to assume the role:
+ `schemas.amazonaws.com`
The role permissions policy named ****AmazonEventBridgeSchemasServiceRolePolicy**** allows EventBridge to complete the following actions on the specified resources:
+ Action: `put, enable, disable, and delete rules; put and remove targets; list targets per rule` on `all managed rules created by EventBridge`
You must configure permissions to allow your users, groups, or roles to create, edit, or delete a service-linked role. For more information, see [Service-linked role permissions](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions) in the *IAM User Guide*.
## Creating a service-linked role for EventBridge
You don't need to manually create a service-linked role. When you conduct a Schema Discovery in the AWS Management Console, the AWS CLI, or the AWS API, EventBridge creates the service-linked role for you.
**Important**
This service-linked role can appear in your account if you completed an action in another service that uses the features supported by this role. If you were using the EventBridge service before November 27, 2019, when it began supporting service-linked roles, then EventBridge created the **AWSServiceRoleForSchemas** role in your account. To learn more, see [A new role appeared in my AWS account](https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_roles.html#troubleshoot_roles_new-role-appeared).
If you delete this service-linked role, and then need to create it again, you can use the same process to recreate the role in your account. When you conduct a Schema Discovery, EventBridge creates the service-linked role for you again.
## Editing a service-linked role for EventBridge
EventBridge does not allow you to edit the **AWSServiceRoleForSchemas** service-linked role. After you create a service-linked role, you cannot change the name of the role because various entities might reference the role. However, you can edit the description of the role using IAM. For more information, see [Editing a service-linked role](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role) in the *IAM User Guide*.
## Deleting a service-linked role for EventBridge
If you no longer need to use a feature or service that requires a service-linked role, we recommend that you delete that role. That way you don’t have an unused entity that is not actively monitored or maintained. However, you must clean up your service-linked role before you can manually delete it.
### Cleaning up a service-linked role
Before you can use IAM to delete a service-linked role, you must first delete any resources used by the role.
**Note**
If the EventBridge service is using the role when you try to delete the resources, then the deletion might fail. If that happens, wait for a few minutes and try the operation again.
**To delete EventBridge resources used by the **AWSServiceRoleForSchemas** (console)**
1. Open the Amazon EventBridge console at [https://console.aws.amazon.com/events/](https://console.aws.amazon.com/events/).
1. Under **Buses** choose **Event buses**, then choose an event bus.
1. Choose **Stop discovery**.
**To delete EventBridge resources used by the **AWSServiceRoleForSchemas** (AWS CLI)**
+ Use the following command: `[delete-discoverer](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/events/delete-discoverer.html)`.
**To delete EventBridge resources used by the **AWSServiceRoleForSchemas** (API)**
+ Use the following command: `[DeleteDiscoverer](https://docs.aws.amazon.com/eventbridge/latest/schema-reference/v1-discoverers-id-discovererid.html#DeleteDiscoverer)`.
### Manually delete the service-linked role
Use the IAM console, the AWS CLI, or the AWS API to delete the **AWSServiceRoleForSchemas** service-linked role. For more information, see [Deleting a service-linked role](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role) in the *IAM User Guide*.
## Supported Regions for EventBridge service-linked roles
EventBridge supports using service-linked roles in all of the Regions where the service is available. For more information, see [AWS Regions and endpoints](https://docs.aws.amazon.com/general/latest/gr/rande.html).