decryptResult = crypto.decryptData(kmsMasterKeyProvider, encryptedByteArray);
final byte[] decryptedByteArray = decryptResult.getResult();
// Decode the event json plaintext from byte array into string with UTF_8 standard.
String eventJson = new String(decryptedByteArray, StandardCharsets.UTF_8);
```
# Encrypting EventBridge Pipes data with AWS KMS keys
You can specify that EventBridge use a customer managed key to encrypt pipe data stored at rest, rather than use an AWS owned key as is the default. You can specify a customer managed key when you create or update a pipe. For more information about key types, see [KMS key options](eb-encryption-at-rest-key-options.md).
The pipe data EventBridge encrypts at rest includes:
+ [Event patterns](eb-event-patterns.md)
+ [Input transformers](eb-pipes-input-transformation.md)
Events flowing through a pipe are never stored at rest.
## EventBridge Pipes encryption context
An [encryption context](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#encrypt_context) is a set of key–value pairs that contain arbitrary nonsecret data. When you include an encryption context in a request to encrypt data, AWS KMS cryptographically binds the encryption context to the encrypted data. To decrypt the data, you must pass in the same encryption context.
You can also use the encryption context as a condition for authorization in policies and grants.
If you use a customer managed key to protect your EventBridge resources, you can use the encryption context to identify use of the KMS key in audit records and logs. It also appears in plaintext in logs, such as [AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html) and [Amazon CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html).
For EventBridge Pipes, EventBridge uses the same encryption context in all AWS KMS cryptographic operations. The context includes a single key–value pair, which contains the pipe ARN.
```
"encryptionContext": {
"kms:EncryptionContext:aws:pipes:arn": "pipe-arn"
}
```
For vended logs, EventBridge uses the following encryption context.
```
"encryptionContext": {
"kms:EncryptionContext:SourceArn": "arn:partition:logs:region:account:*"
}
```
## AWS KMS key policy for EventBridge Pipes
The following example key policy provides the required permissions for a pipe:
+ `kms:DescribeKey`
+ `kms:GenerateDataKey`
+ `kms:Decrypt`
As a security best practice, we recommend you include condition keys in the key policy to helps ensure that EventBridge uses the AWS KMS key only for the specified resource or account. For more information, see [Security considerations](eb-encryption-key-policy.md#eb-encryption-event-bus-confused-deputy).
------
#### [ JSON ]
****
```
{
"Id": "CMKKeyPolicy",
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:role/pipe-execution-role"
},
"Action": [
"kms:DescribeKey"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:role/pipe-execution-rolee"
},
"Action": [
"kms:GenerateDataKey",
"kms:Decrypt"
],
"Resource": "*",
"Condition": {
"ArnLike": {
"kms:EncryptionContext:aws:pipe:arn": "arn:aws:pipes:us-east-1:123456789012:pipe/pipe-name"
},
"ForAnyValue:StringEquals": {
"kms:EncryptionContextKeys": [
"aws:pipe:arn"
]
}
}
}
]
}
```
------
### Permissions for pipe logs that include execution data
If you have configured pipes logging to include execution data, the key policy must include the following permissions for the logging service:
+ `kms:Decrypt`
+ `kms:GenerateDataKey`
For more information, see [Including execution data in EventBridge Pipes logs](eb-pipes-logs.md#eb-pipes-logs-execution-data).
The following example key policy provides the required permissions for pipes logging:
```
{
"Sid": "Enable log service encryption",
"Effect": "Allow",
"Principal": {
"Service": "delivery.logs.amazonaws.com"
},
"Action": [
"kms:Decrypt",
"kms:GenerateDataKey"
],
"Resource": "*",
"Condition": {
"StringLike": {
"kms:EncryptionContext:SourceArn": "arn:partition:logs:region:account:*"
}
}
}
```
In addition, the pipe execution role requires the `kms:GenerateDataKey` permisson.
```
{
"Sid": "Enable log service encryption",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::account:role/pipe-execution-role"
},
"Action": [
"kms:GenerateDataKey"
],
"Resource": "*",
"Condition": {
"StringLike": {
"kms:EncryptionContext:SourceArn": "arn:partition:logs:region:account:*"
}
}
}
```
The pipe execution role should also include:
```
"Action": [
"kms:GenerateDataKey"
],
"Resource": "key-arn",
"Condition": {
"StringLike": {
"kms:EncryptionContext:SourceArn": "arn:partition:logs:region:account:*"
}
}
```
# Configuring encryption in EventBridge Pipes
You can specify the KMS key for EventBridge to use when you create or update a pipe.
## Specifying the AWS KMS key used for encryption when creating a pipe
Choosing the AWS KMS key used for encryption is an option creating a pipe. The default is to use the AWS owned key provided by EventBridge.
**To specify a customer managed key for encryption when creating a pipe (console)**
+ Follow these instructions:
[Creating a pipe](eb-pipes-create.md).
**To specify a customer managed key for encryption when creating a pipe (CLI)**
+ When calling `[create-pipe](https://docs.aws.amazon.com/cli/latest/reference/pipes/create-pipe.html)`, use the `kms-key-identifier` option to specify the customer managed key for EventBridge to use for encryption on the event bus.
## Updating the AWS KMS key used for encryption on EventBridge Pipes
You can update the AWS KMS key being used for encryption at rest on an existing pipe. This includes:
+ Changing from the default AWS owned key to a customer managed key.
+ Changing from a customer managed key to the default AWS owned key.
+ Changing from one customer managed key to another.
When you update a pipe to use a different AWS KMS key, EventBridge decrypts any data stored on the pipe and then encrypts it using the new key.
**To update the KMS key used for encryption on a pipe (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 **Pipes**.
1. Choose the pipe you want to update.
1. On the pipe bus details page, choose the **Encryption** tab.
1. Choose the KMS key for EventBridge to use when encrypting the data stored on pipe:
+ 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.
**To update the KMS key used for encryption on a pipe (CLI)**
+ When calling `[update-pipe](https://docs.aws.amazon.com/cli/latest/reference/pipes/update-pipe.html)`, use the `kms-key-identifier` option to specify the customer managed key for EventBridge to use for encrypting pipe data.
# Encrypting EventBridge archives with AWS KMS keys
You can specify that EventBridge use a customer managed key to encrypt events stored in an archive, rather than use an AWS owned key as is the default. You can specify a customer managed key when you create or update an archive. For more information about key types, see [KMS key options](eb-encryption-at-rest-key-options.md).
This includes:
+ Events stored in the archive
+ The event pattern, if any, specified to filter the events sent to the archive
This does not include archive metadata, such as the size of the archive or number of events it contains.
If you specify a customer managed key for an archive, EventBridge encrypts events prior to sending it to the archive, ensuring encryption in transit and at rest.
## Archive encryption context
An [encryption context](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#encrypt_context) is a set of key–value pairs that contain arbitrary nonsecret data. When you include an encryption context in a request to encrypt data, AWS KMS cryptographically binds the encryption context to the encrypted data. To decrypt the data, you must pass in the same encryption context.
You can also use the encryption context as a condition for authorization in policies and grants.
If you use a customer managed key to protect your EventBridge resources, you can use the encryption context to identify use of the KMS key in audit records and logs. It also appears in plaintext in logs, such as [AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html) and [Amazon CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html).
For event archives, EventBridge uses the same encryption context in all AWS KMS cryptographic operations. The context includes a single key–value pair, which contains the event bus ARN.
```
"encryptionContext": {
"kms:EncryptionContext:aws:events:event-bus:arn": "event-bus-arn"
}
```
## AWS KMS key policy for archives
The following example key policy provides the required permissions for an event archive:
+ `kms:DescribeKey`
+ `kms:GenerateDataKey`
+ `kms:Decrypt`
+ `kms:ReEncrypt`
As a security best practice, we recommend you include condition keys in the key policy to helps ensure that EventBridge uses the KMS key only for the specified resource or account. For more information, see [Security considerations](eb-encryption-key-policy.md#eb-encryption-event-bus-confused-deputy).
------
#### [ JSON ]
****
```
{
"Id": "CMKKeyPolicy",
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "events.amazonaws.com"
},
"Action": [
"kms:DescribeKey"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Principal": {
"Service": "events.amazonaws.com"
},
"Action": [
"kms:GenerateDataKey",
"kms:Decrypt",
"kms:ReEncrypt*"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"kms:EncryptionContext:aws:events:event-bus:arn": "arn:aws:events:us-east-1:123456789012:event-bus/event-bus-arn"
}
}
}
]
}
```
------
# Configuring encryption on archives
You can specify the KMS key for EventBridge to use when you create or update an archive.
## Specifying encryption when creating an archive
Choosing the AWS KMS key used for encryption is an option creating an archive. The default is to use the AWS owned key provided by EventBridge.
**To specify a customer managed key for encryption when creating an archive (console)**
+ Follow these instructions:
[Creating archives](eb-archive-event.md).
**To specify a customer managed key for encryption when creating an archive (CLI)**
+ When calling `[create-archive](https://docs.aws.amazon.com/cli/latest/reference/events/create-archive.html)`, use the `kms-key-identifier` option to specify the customer managed key for EventBridge to use for encrypting events stored in the archive.
## Updating encryption on archives
You can update the AWS KMS key being used for encryption at rest on an existing archive. This includes:
+ Changing from the default AWS owned key to a customer managed key.
+ Changing from a customer managed key to the default AWS owned key.
+ Changing from one customer managed key to another.
**To update the KMS key used for encrypting events in 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. Choose the archive you want to update.
1. On the archive details page, choose the **Encryption** tab.
1. 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 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.
**To update the KMS key used for encrypting events stored in an archive (CLI)**
+ When calling `[update-archive](https://docs.aws.amazon.com/cli/latest/reference/events/update-archive.html)`, use the `kms-key-identifier` option to specify the customer managed key for EventBridge to use for encrypting events stored in the archive.
# Encrypting EventBridge connection authorization with AWS KMS keys
When you create or update a connection, you can specify authorization parameters for that connection. EventBridge then securely stores those parameters in a secret in AWS Secrets Manager. By default, EventBridge uses an AWS owned key to encrypt and decrypt this secret. You can specify that EventBridge use a customer managed key instead.
## AWS KMS key policy for connections
The AWS KMS key policy must grant EventBridge the following permissions on your behalf:
+ `kms:DescribeKey`
+ `kms:GenerateDataKey`
+ `kms:Decrypt`
The following policy example grants all AWS KMS permissions.
------
#### [ JSON ]
****
```
{
"Id": "key-policy-example",
"Version":"2012-10-17",
"Statement": [
{
"Sid": "Enable IAM User Permissions",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::012345678901:root"
},
"Action": "kms:*",
"Resource": "*"
}
]
}
```
------
For EventBridge to use a customer managed key, you must add a resource tag to the key with a key of `EventBridgeApiDestinations` and a value of `true`. For more information on resource tags, see [Add tags to a KMS key](https://docs.aws.amazon.com/kms/latest/developerguide/add-tags.html) in the *AWS Key Management Service Developer Guide*.
As a security best practice, we recommend you include condition keys in the key policy to helps ensure that EventBridge uses the KMS key only for the specified resource or account. For more information, see [Security considerations](eb-encryption-key-policy.md#eb-encryption-event-bus-confused-deputy).
```
"Condition": {
"StringLike": {
"kms:ViaService": "secretsmanager.*.amazonaws.com",
"kms:EncryptionContext:SecretARN": [
"arn:aws:secretsmanager:*:*:secret:events!connection/*"
]
},
"StringEquals": {
"kms:ResourceTag/EventBridgeApiDestinations": "true"
}
}
```
## Connection encryption context
An [encryption context](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#encrypt_context) is a set of key–value pairs that contain arbitrary nonsecret data. When you include an encryption context in a request to encrypt data, AWS KMS cryptographically binds the encryption context to the encrypted data. To decrypt the data, you must pass in the same encryption context.
You can also use the encryption context as a condition for authorization in policies and grants.
If you use a customer managed key to protect your EventBridge resources, you can use the encryption context to identify use of the KMS key in audit records and logs. It also appears in plaintext in logs, such as [AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html) and [Amazon CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html).
For connections, EventBridge uses the same encryption context in all AWS KMS cryptographic operations. The context includes a single key–value pair, which contains the secret ARN.
```
"encryptionContext": {
"kms:EncryptionContext:SecretARN": "secret-arn"
}
```
## Using cross-account or cross-Region customer managed keys for connections
You can allow users or roles in a different AWS account to use a KMS key in your account. Cross-account access requires permission in the key policy of the KMS key and in an IAM policy in the external user's account.
To use a customer managed key from another account, the account with the customer managed key must include the following policy:
```
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::account:role/AmazonEventBridgeApiDestinationsInternalServiceRolePolicy"
},
"Action": [
"kms:Decrypt",
"kms:DescribeKey"
],
"Resource": "*"
}
```
For more information, see [ Allowing users in other accounts to use a KMS key ](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-modifying-external-accounts.html) in the *AWS Key Management Service Developer Guide*.
## Revoking customer managed key access to connections
Be aware that when you revoke a customer managed key--through disabling, deleting, or rotating the key, or updating the key policy--EventBridge may have cached the key value, and so that key may still retain access to a connection's secret for a short period of time.
To immediately revoke customer managed key access to a connection's secret, de-authorize or delete the connection. For more information, see [De-authorizing connections](eb-target-connection-deauthorize.md) and [Deleting connections](eb-target-connection-delete.md).
## Connection de-authorization due to customer managed key errors
EventBridge de-authorizes a connection if it encounters the following errors when attempting to encrypt or decrypt the connection's secret:
+ The customer managed key has been deleted.
+ The customer managed key has been disabled.
+ The connection does not have the necessary permissions to access the customer managed key.
For more information, see [De-authorizing connections](eb-target-connection-deauthorize.md).
# Configuring encryption on connections
You can specify the KMS key for EventBridge to use when you create or update a connection.
## Specifying AWS KMS keys when creating connections
Choosing the AWS KMS key used for encryption is optional when creating a connection. By default, EventBridge uses an AWS owned key.
**To specify a customer managed key for encryption when creating a connection (console)**
+ Follow these instructions:
[Creating connections](eb-target-connection-create.md).
**To specify a customer managed key for encryption when creating a connection (CLI)**
+ When calling `[create-connection](https://docs.aws.amazon.com/cli/latest/reference/events/create-connection.html)`, use the `kms-key-identifier` option to specify the customer managed key for EventBridge to use for encryption of the connection's secret.
## Updating AWS KMS keys for connections
You can update the KMS key being used for encrypting an existing connection. This includes:
+ Changing from the default AWS owned key to a customer managed key.
+ Changing from a customer managed key to the default AWS owned key.
+ Changing from one customer managed key to another.
When you update a connection to use a different KMS key , EventBridge decrypts the connection's secret and then encrypts it using the new key. Make sure the KMS key you specify has the necessary permissions. For more information, see [Connection key policy](encryption-connections.md#encryption-connections-key-policy).
**To update the KMS key used for encryption on a connection (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 **Integration**, and then choose **Connections**.
1. Choose the connection you want to update.
1. On the connection details page, under **Encryption**, choose the KMS key for EventBridge to use when encrypting the connection's secret:
+ Choose **Use AWS owned key** for EventBridge to encrypt the secret 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 **Choose a different AWS KMS key (advanced)** for EventBridge to encrypt the secret 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**.
Make sure the KMS key you specify has the necessary permissions. For more information, see [Connection key policy](encryption-connections.md#encryption-connections-key-policy).
EventBridge displays the key status and any key aliases that have been associated with the specified customer managed key.
**To update the KMS key used for encryption on a connection (CLI)**
+ When calling `[update-connection](https://docs.aws.amazon.com/cli/latest/reference/events/update-connection.html)`, use the `kms-key-identifier` option to specify the customer managed key for EventBridge to use for encrypting the connection secret.
# Tag-based policies in Amazon EventBridge
In Amazon EventBridge, you can use policies based on tags to control access to resources.
For example, you could restrict access to resources that include a tag with the key `environment` and the value `production`. The following example policy denies any resource with this tag the ability to create, delete, or modify tags, rules, or event buses for resources that have been tagged `environment/production`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": [
"events:PutRule",
"events:DescribeRule",
"events:DeleteRule",
"events:CreateEventBus",
"events:DescribeEventBus",
"events:DeleteEventBus"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:ResourceTag/environment": "production"
}
}
}
]
}
```
------
For more information about tagging, see the following.
+ [Tagging resources in Amazon EventBridge](eb-tagging.md)
+ [Controlling Access Using IAM Tags](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_iam-tags.html)
# 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).
# Logging Amazon EventBridge API calls using AWS CloudTrail
Amazon EventBridge is integrated with [AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html), a service that provides a record of actions taken by a user, role, or an AWS service. CloudTrail captures all API calls for EventBridge as events. The calls captured include calls from the EventBridge console and code calls to the EventBridge API operations. Using the information collected by CloudTrail, you can determine the request that was made to EventBridge, the IP address from which the request was made, when it was made, and additional details.
Every event or log entry contains information about who generated the request. The identity information helps you determine the following:
+ Whether the request was made with root user or user credentials.
+ Whether the request was made on behalf of an IAM Identity Center user.
+ Whether the request was made with temporary security credentials for a role or federated user.
+ Whether the request was made by another AWS service.
CloudTrail is active in your AWS account when you create the account and you automatically have access to the CloudTrail **Event history**. The CloudTrail **Event history** provides a viewable, searchable, downloadable, and immutable record of the past 90 days of recorded management events in an AWS Region. For more information, see [Working with CloudTrail Event history](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/view-cloudtrail-events.html) in the *AWS CloudTrail User Guide*. There are no CloudTrail charges for viewing the **Event history**.
For an ongoing record of events in your AWS account past 90 days, create a trail or a [CloudTrail Lake](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-lake.html) event data store.
**CloudTrail trails**
A *trail* enables CloudTrail to deliver log files to an Amazon S3 bucket. All trails created using the AWS Management Console are multi-Region. You can create a single-Region or a multi-Region trail by using the AWS CLI. Creating a multi-Region trail is recommended because you capture activity in all AWS Regions in your account. If you create a single-Region trail, you can view only the events logged in the trail's AWS Region. For more information about trails, see [Creating a trail for your AWS account](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-and-update-a-trail.html) and [Creating a trail for an organization](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/creating-trail-organization.html) in the *AWS CloudTrail User Guide*.
You can deliver one copy of your ongoing management events to your Amazon S3 bucket at no charge from CloudTrail by creating a trail, however, there are Amazon S3 storage charges. For more information about CloudTrail pricing, see [AWS CloudTrail Pricing](https://aws.amazon.com/cloudtrail/pricing/). For information about Amazon S3 pricing, see [Amazon S3 Pricing](https://aws.amazon.com/s3/pricing/).
**CloudTrail Lake event data stores**
*CloudTrail Lake* lets you run SQL-based queries on your events. CloudTrail Lake converts existing events in row-based JSON format to [ Apache ORC](https://orc.apache.org/) format. ORC is a columnar storage format that is optimized for fast retrieval of data. Events are aggregated into *event data stores*, which are immutable collections of events based on criteria that you select by applying [advanced event selectors](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-lake-concepts.html#adv-event-selectors). The selectors that you apply to an event data store control which events persist and are available for you to query. For more information about CloudTrail Lake, see [Working with AWS CloudTrail Lake](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-lake.html) in the *AWS CloudTrail User Guide*.
CloudTrail Lake event data stores and queries incur costs. When you create an event data store, you choose the [pricing option](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-lake-manage-costs.html#cloudtrail-lake-manage-costs-pricing-option) you want to use for the event data store. The pricing option determines the cost for ingesting and storing events, and the default and maximum retention period for the event data store. For more information about CloudTrail pricing, see [AWS CloudTrail Pricing](https://aws.amazon.com/cloudtrail/pricing/).
## EventBridge management events in CloudTrail
[Management events](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/logging-management-events-with-cloudtrail.html#logging-management-events) provide information about management operations that are performed on resources in your AWS account. These are also known as control plane operations. By default, CloudTrail logs management events.
All Amazon EventBridge API operations except [https://docs.aws.amazon.com/eventbridge/latest/APIReference/API_PutEvents.html](https://docs.aws.amazon.com/eventbridge/latest/APIReference/API_PutEvents.html) and [https://docs.aws.amazon.com/eventbridge/latest/APIReference/API_PutPartnerEvents.html](https://docs.aws.amazon.com/eventbridge/latest/APIReference/API_PutPartnerEvents.html) are control plane operations. For a complete list, see [Actions](https://docs.aws.amazon.com/eventbridge/latest/APIReference/API_Operations.html) in the *Amazon EventBridge API Reference*. For example management events, see [EventBridge management event examples](#cloudtrail-event-examples).
## EventBridge data events in CloudTrail
[Data events](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/logging-data-events-with-cloudtrail.html#logging-data-events) provide information about the resource operations performed on or in a resource (for example, publishing events to an event bus). These are also known as data plane operations. Data events are often high-volume activities. By default, CloudTrail doesn't log data events. The CloudTrail **Event history** doesn't record data events.
Additional charges apply for data events. For more information about CloudTrail pricing, see [AWS CloudTrail Pricing](https://aws.amazon.com/cloudtrail/pricing/).
You can log data events for the EventBridge resource types by using the CloudTrail console, AWS CLI, or CloudTrail API operations. For more information about how to log data events, see [Logging data events with the AWS Management Console](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/logging-data-events-with-cloudtrail.html#logging-data-events-console) and [Logging data events with the AWS Command Line Interface](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/logging-data-events-with-cloudtrail.html#creating-data-event-selectors-with-the-AWS-CLI) in the *AWS CloudTrail User Guide*.
The following table lists the EventBridge resource types for which you can log data events. The **Resource type (console)** column shows the value to choose from the **Resource type** list on the CloudTrail console. The **resources.type value** column shows the `resources.type` value, which you would specify when configuring advanced event selectors using the AWS CLI or CloudTrail APIs. The **Data APIs logged to CloudTrail** column shows the API calls logged to CloudTrail for the resource type.
| Resource type (console) | resources.type value | Data APIs logged to CloudTrail |
| --- | --- | --- |
| EventBridge event bus | AWS::Events::EventBus | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/eventbridge/latest/userguide/logging-using-cloudtrail.html) |
| EventBridge partner event source | AWS::Events::EventSource | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/eventbridge/latest/userguide/logging-using-cloudtrail.html) |
| EventBridge endpoint | AWS::Events::Endpoint | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/eventbridge/latest/userguide/logging-using-cloudtrail.html) |
You can configure advanced event selectors to filter on the `eventName`, `readOnly`, and `resources.ARN` fields to log only those events that are important to you. For more information about these fields, see [https://docs.aws.amazon.com/awscloudtrail/latest/APIReference/API_AdvancedFieldSelector.html](https://docs.aws.amazon.com/awscloudtrail/latest/APIReference/API_AdvancedFieldSelector.html) in the *AWS CloudTrail API Reference*.
**Note**
Data events are delivered only to the AWS account of the API caller. If you send events to a cross-account event bus, the resource owner's account does not receive a CloudTrail data event.
**Note**
The `detail` field in event entries is redacted in CloudTrail data event logs to protect sensitive data.
For examples of data events that EventBridge logs to CloudTrail, see [EventBridge data event examples](#cloudtrail-data-event-examples).
## EventBridge management event examples
An event represents a single request from any source and includes information about the requested API operation, the date and time of the operation, request parameters, and so on. CloudTrail log files aren't an ordered stack trace of the public API calls, so events don't appear in any specific order.
The following example shows a CloudTrail event that demonstrates the `PutRule` operation.
```
{
"eventVersion":"1.03",
"userIdentity":{
"type":"Root",
"principalId":"123456789012",
"arn":"arn:aws:iam::123456789012:root",
"accountId":"123456789012",
"accessKeyId":"AKIAIOSFODNN7EXAMPLE",
"sessionContext":{
"attributes":{
"mfaAuthenticated":"false",
"creationDate":"2015-11-17T23:56:15Z"
}
}
},
"eventTime":"2015-11-18T00:11:28Z",
"eventSource":"events.amazonaws.com",
"eventName":"PutRule",
"awsRegion":"us-east-1",
"sourceIPAddress":"AWS Internal",
"userAgent":"AWS CloudWatch Console",
"requestParameters":{
"description":"",
"name":"cttest2",
"state":"ENABLED",
"eventPattern":"{\"source\":[\"aws.ec2\"],\"detail-type\":[\"EC2 Instance State-change Notification\"]}",
"scheduleExpression":""
},
"responseElements":{
"ruleArn":"arn:aws:events:us-east-1:123456789012:rule/cttest2"
},
"requestID":"e9caf887-8d88-11e5-a331-3332aa445952",
"eventID":"49d14f36-6450-44a5-a501-b0fdcdfaeb98",
"eventType":"AwsApiCall",
"apiVersion":"2015-10-07",
"recipientAccountId":"123456789012"
}
```
For information about CloudTrail record contents, see [CloudTrail record contents](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-event-reference-record-contents.html) in the *AWS CloudTrail User Guide*.
## EventBridge data event examples
The following example shows a CloudTrail data event for a successful `PutEvents` call.
```
{
"eventVersion": "1.11",
"userIdentity": {
"type": "AssumedRole",
"principalId": "AROA3XFRBF23EXAMPLE:johndoe-session",
"arn": "arn:aws:sts::111122223333:assumed-role/MyRole/johndoe-session",
"accountId": "111122223333",
"accessKeyId": "AKIAIOSFODNN7EXAMPLE",
"sessionContext": {
"sessionIssuer": {
"type": "Role",
"principalId": "AROA3XFRBF23EXAMPLE",
"arn": "arn:aws:iam::111122223333:role/MyRole",
"accountId": "111122223333",
"userName": "MyRole"
},
"attributes": {
"creationDate": "2026-03-07T00:49:09Z",
"mfaAuthenticated": "false"
}
}
},
"eventTime": "2026-03-07T00:51:07Z",
"eventSource": "events.amazonaws.com",
"eventName": "PutEvents",
"awsRegion": "us-east-1",
"sourceIPAddress": "192.0.2.1",
"userAgent": "aws-cli/2.33.13",
"requestParameters": {
"entries": [
{
"source": "my-application",
"detailType": "MyDetailType",
"detail": "HIDDEN_DUE_TO_SECURITY_REASONS",
"eventBusName": "default"
}
]
},
"responseElements": {
"failedEntryCount": 0,
"entries": [
{
"eventId": "a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"
}
]
},
"requestID": "a1b2c3d4-5678-90ab-cdef-EXAMPLE22222",
"eventID": "a1b2c3d4-5678-90ab-cdef-EXAMPLE33333",
"readOnly": false,
"resources": [
{
"type": "AWS::Events::EventBus",
"ARN": "arn:aws:events:us-east-1:111122223333:event-bus/default"
}
],
"eventType": "AwsApiCall",
"apiVersion": "2015-10-07",
"managementEvent": false,
"recipientAccountId": "111122223333",
"eventCategory": "Data",
"tlsDetails": {
"tlsVersion": "TLSv1.3",
"cipherSuite": "TLS_AES_128_GCM_SHA256",
"clientProvidedHostHeader": "events.us-east-1.amazonaws.com"
}
}
```
The following example shows a CloudTrail data event for a `PutEvents` call using a [global endpoint](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-global-endpoints.html). Note the additional `AWS::Events::Endpoint` resource in the `resources` array.
```
{
"eventVersion": "1.11",
"userIdentity": {
"type": "AssumedRole",
"principalId": "AROA3XFRBF23EXAMPLE:johndoe-session",
"arn": "arn:aws:sts::111122223333:assumed-role/MyRole/johndoe-session",
"accountId": "111122223333",
"accessKeyId": "AKIAIOSFODNN7EXAMPLE",
"sessionContext": {
"sessionIssuer": {
"type": "Role",
"principalId": "AROA3XFRBF23EXAMPLE",
"arn": "arn:aws:iam::111122223333:role/MyRole",
"accountId": "111122223333",
"userName": "MyRole"
},
"attributes": {
"creationDate": "2026-03-07T00:49:09Z",
"mfaAuthenticated": "false"
}
}
},
"eventTime": "2026-03-07T00:51:06Z",
"eventSource": "events.amazonaws.com",
"eventName": "PutEvents",
"awsRegion": "us-east-1",
"sourceIPAddress": "192.0.2.1",
"userAgent": "aws-cli/2.33.13",
"requestParameters": {
"entries": [
{
"source": "my-application",
"detailType": "MyDetailType",
"detail": "HIDDEN_DUE_TO_SECURITY_REASONS",
"eventBusName": "default"
}
],
"endpointId": "abc1234567.us-east-1"
},
"responseElements": {
"failedEntryCount": 0,
"entries": [
{
"eventId": "a1b2c3d4-5678-90ab-cdef-EXAMPLE44444"
}
]
},
"requestID": "a1b2c3d4-5678-90ab-cdef-EXAMPLE55555",
"eventID": "a1b2c3d4-5678-90ab-cdef-EXAMPLE66666",
"readOnly": false,
"resources": [
{
"type": "AWS::Events::EventBus",
"ARN": "arn:aws:events:us-east-1:111122223333:event-bus/default"
},
{
"type": "AWS::Events::Endpoint",
"ARN": "arn:aws:events:us-east-1:111122223333:endpoint/MyGlobalEndpoint"
}
],
"eventType": "AwsApiCall",
"apiVersion": "2015-10-07",
"managementEvent": false,
"recipientAccountId": "111122223333",
"eventCategory": "Data",
"tlsDetails": {
"tlsVersion": "TLSv1.3",
"cipherSuite": "TLS_AES_128_GCM_SHA256",
"clientProvidedHostHeader": "abc1234567.us-east-1.endpoint.events.amazonaws.com"
}
}
```
The following example shows a CloudTrail data event for a successful `PutPartnerEvents` call.
```
{
"eventVersion": "1.11",
"userIdentity": {
"type": "AssumedRole",
"principalId": "AROA3XFRBF23EXAMPLE:partner-session",
"arn": "arn:aws:sts::111122223333:assumed-role/PartnerRole/partner-session",
"accountId": "111122223333",
"accessKeyId": "AKIAIOSFODNN7EXAMPLE",
"sessionContext": {
"sessionIssuer": {
"type": "Role",
"principalId": "AROA3XFRBF23EXAMPLE",
"arn": "arn:aws:iam::111122223333:role/PartnerRole",
"accountId": "111122223333",
"userName": "PartnerRole"
},
"attributes": {
"creationDate": "2026-03-07T00:49:09Z",
"mfaAuthenticated": "false"
}
}
},
"eventTime": "2026-03-07T00:51:07Z",
"eventSource": "events.amazonaws.com",
"eventName": "PutPartnerEvents",
"awsRegion": "us-east-1",
"sourceIPAddress": "192.0.2.1",
"userAgent": "aws-cli/2.33.13",
"requestParameters": {
"entries": [
{
"time": "Mar 7, 2026, 12:51:07 AM",
"source": "aws.partner/example.com/my-integration",
"detailType": "MyDetailType",
"detail": "HIDDEN_DUE_TO_SECURITY_REASONS"
}
]
},
"responseElements": {
"failedEntryCount": 0,
"entries": [
{
"eventId": "a1b2c3d4-5678-90ab-cdef-EXAMPLE77777"
}
]
},
"requestID": "a1b2c3d4-5678-90ab-cdef-EXAMPLE88888",
"eventID": "a1b2c3d4-5678-90ab-cdef-EXAMPLE99999",
"readOnly": false,
"resources": [
{
"type": "AWS::Events::EventSource",
"ARN": "arn:aws:events:us-east-1::event-source/aws.partner/example.com/my-integration"
}
],
"eventType": "AwsApiCall",
"apiVersion": "2015-10-07",
"managementEvent": false,
"recipientAccountId": "111122223333",
"eventCategory": "Data",
"tlsDetails": {
"tlsVersion": "TLSv1.3",
"cipherSuite": "TLS_AES_128_GCM_SHA256",
"clientProvidedHostHeader": "events.us-east-1.amazonaws.com"
}
}
```
## CloudTrail log entries for actions taken by EventBridge Pipes
EventBridge Pipes assumes the provided IAM role when reading events from sources, invoking enrichments, or invoking targets. For CloudTrail entries related to actions taken in your account on all enrichments, targets, and Amazon SQS, Kinesis, and DynamoDB sources, the `sourceIPAddress` and `invokedBy` fields will include `pipes.amazonaws.com`.
**Sample CloudTrail log entry for all enrichments, targets, and Amazon SQS, Kinesis, and DynamoDB sources**
```
{
"eventVersion": "1.08",
"userIdentity": {
"type": "AssumedRole",
"principalId": "...",
"arn": "arn:aws:sts::111222333444:assumed-role/...",
"accountId": "111222333444",
"accessKeyId": "...",
"sessionContext": {
"sessionIssuer": {
"type": "Role",
"principalId": "...",
"arn": "...",
"accountId": "111222333444",
"userName": "userName"
},
"webIdFederationData": {},
"attributes": {
"creationDate": "2022-09-22T21:41:15Z",
"mfaAuthenticated": "false"
}
},
"invokedBy": "pipes.amazonaws.com"
},
"eventTime": ",,,",
"eventName": "...",
"awsRegion": "us-west-2",
"sourceIPAddress": "pipes.amazonaws.com",
"userAgent": "pipes.amazonaws.com",
"requestParameters": {
...
},
"responseElements": null,
"requestID": "...",
"eventID": "...",
"readOnly": true,
"eventType": "AwsApiCall",
"managementEvent": true,
"recipientAccountId": "...",
"eventCategory": "Management"
}
```
For all other sources, the `sourceIPAddress` field of the CloudTrail log entries will have a dynamic IP address and shouldn't be relied upon for any integration or event categorization. In addition, these entries won't have the `invokedBy` field.
**Sample CloudTrail log entry for all other sources**
```
{
"eventVersion": "1.08",
"userIdentity": {
...
},
"eventTime": ",,,",
"eventName": "...",
"awsRegion": "us-west-2",
"sourceIPAddress": "127.0.0.1",
"userAgent": "Python-httplib2/0.8 (gzip)",
}
```
# Compliance validation in Amazon EventBridge
Third-party auditors such as SOC, PCI, FedRAMP, and HIPAA assess the security and compliance of AWS services as part of multiple AWS compliance programs.
For a list of AWS services in scope of specific compliance programs, see [AWS Services in Scope by Compliance Program](https://aws.amazon.com/compliance/services-in-scope/). For general information, see [AWS Compliance Programs](https://aws.amazon.com/compliance/programs/).
You can download third-party audit reports using AWS Artifact. For more information, see [Downloading Reports in AWS Artifact](https://docs.aws.amazon.com/artifact/latest/ug/downloading-documents.html).
Your compliance responsibility when using EventBridge is determined by the sensitivity of your data, your company's compliance objectives, and applicable laws and regulations. AWS provides the following resources to help with compliance:
+ [Security and Compliance Quick Start Guides](https://aws.amazon.com/quickstart/?awsf.quickstart-homepage-filter=categories%23security-identity-compliance) – Architectural considerations and steps for deploying security- and compliance-focused baseline environments on AWS.
+ [Architecting for HIPAA Security and Compliance Whitepaper ](https://docs.aws.amazon.com/whitepapers/latest/architecting-hipaa-security-and-compliance-on-aws/architecting-hipaa-security-and-compliance-on-aws.html) – How companies can use AWS to create HIPAA-compliant applications.
+ [AWS Compliance Resources](https://aws.amazon.com/compliance/resources/) – A collection of workbooks and guides.
+ [Evaluating Resources with Rules](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html) in the *AWS Config Developer Guide* – Information about how AWS Config assesses how well your resource configurations comply with internal practices, industry guidelines, and regulations.
+ [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html) – A comprehensive view of your security state within AWS that helps you check your compliance with security industry standards and best practices.
# Amazon EventBridge resilience
The AWS global infrastructure is built around AWS Regions and Availability Zones. AWS Regions provide multiple physically separated and isolated Availability Zones, which are connected with low-latency, high-throughput, and highly redundant networking. With Availability Zones, you can design and operate applications and databases that automatically fail over between zones without interruption. Availability Zones are more highly available, fault tolerant, and scalable than traditional single or multiple data center infrastructures.
For more information about AWS Regions and Availability Zones, see [AWS Global Infrastructure](https://aws.amazon.com/about-aws/global-infrastructure/).
# Infrastructure security in Amazon EventBridge
As a managed service, Amazon EventBridge is protected by AWS global network security. For information about AWS security services and how AWS protects infrastructure, see [AWS Cloud Security](https://aws.amazon.com/security/). To design your AWS environment using the best practices for infrastructure security, see [Infrastructure Protection](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/infrastructure-protection.html) in *Security Pillar AWS Well‐Architected Framework*.
You use AWS published API calls to access EventBridge through the network. Clients must support the following:
+ Transport Layer Security (TLS). We require TLS 1.2 and recommend TLS 1.3.
+ Cipher suites with perfect forward secrecy (PFS) such as DHE (Ephemeral Diffie-Hellman) or ECDHE (Elliptic Curve Ephemeral Diffie-Hellman). Most modern systems such as Java 7 and later support these modes.
You can call these API operations from any network location, and you can use [resource-based access policies](eb-use-resource-based.md) in EventBridge, which can include restrictions based on the source IP address. You can also use EventBridge policies to control access from specific Amazon Virtual Private Cloud (Amazon VPC) endpoints or specific VPCs. Effectively, this isolates network access to a given EventBridge resource from only the specific VPC within the AWS network.
# Configuration and vulnerability analysis in Amazon EventBridge
Configuration and IT controls are a shared responsibility between AWS and you, our customer. For more information, see the AWS [shared responsibility model](https://aws.amazon.com/compliance/shared-responsibility-model/).