AWS Security ChangesHomeSearch

AWS eventbridge: Rewrite EventBridge custom bus encryption-at-rest and KMS key policy docs

Service: eventbridge · 2026-09-29 · Documentation high

File: eventbridge/latest/userguide/eb-custom-bus-encryption.md · Type: encryption

Summary

Restructures the Custom Event Bus encryption page: documents default AWS owned key encryption, customer managed KMS key configuration, branch-key/Hierarchical Keyring mechanics, the three required key-policy statements, encryption-context scoping, confused-deputy protection via aws:SourceArn/aws:SourceAccount, key rotation, key unavailability/deletion behavior, and CloudTrail monitoring of KMS usage.

Security assessment

The change is a documentation rewrite that adds security guidance rather than fixing a specific vulnerability: it explains encryption at rest with AWS owned vs customer managed KMS keys, scopes key-policy statements to a single bus via the aws:events:event-busv2:arn encryption context, and documents confused-deputy protection using aws:SourceArn/aws:SourceAccount conditions on the service-principal statement. These are encryption and IAM permission-boundary topics with direct data-protection impact, but no CVE or incident is referenced.

Evidence

+  * **Confused deputy protection.** Requests EventBridge makes as the service principal include the `aws:SourceArn` context (the bus ARN) and the `aws:SourceAccount` context. So you can add these conditions to the `AllowEventBridgeServicePrincipal` statement. They ensure EventBridge uses your key only on behalf of your own resources:

Diff

diff --git a/eventbridge/latest/userguide/eb-custom-bus-encryption.md b/eventbridge/latest/userguide/eb-custom-bus-encryption.md
index d676840c6..4f314c2f9 100644
--- a//eventbridge/latest/userguide/eb-custom-bus-encryption.md
+++ b//eventbridge/latest/userguide/eb-custom-bus-encryption.md
@@ -7 +7 @@
-Choosing the key that encrypts a busHow the bus uses your keyWriting the key policyScoping the key policy to one busChanging or removing the key on a busWhen the key becomes unusableMonitoring key use in CloudTrailEncryption in transit
+Options for Encryption at RestEncrypting Data at Rest using Customer Managed KMS Keys for Custom Event BusMonitoring EventBridge Custom Event Bus interaction with AWS KMS
@@ -9 +9 @@ Choosing the key that encrypts a busHow the bus uses your keyWriting the key pol
-# Encrypting events on a Custom Event Bus
+# Encryption at Rest for Amazon EventBridge Custom Event Bus
@@ -11 +11 @@ Choosing the key that encrypts a busHow the bus uses your keyWriting the key pol
-A bus encrypts everything it stores: event payloads, event metadata, subscriber filters, and subscriber target configuration. By default it uses a key that AWS owns, and you configure nothing. To encrypt a bus with your own AWS KMS key instead, set `EncryptionConfiguration.KmsKeyIdentifier` when you create or update the bus, for example `aws eventsv2 create-event-bus --name orders --encryption-configuration KmsKeyIdentifier=arn:aws:kms:us-east-1:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab`, and add the three statements in Writing the key policy to the key policy.
+## Options for Encryption at Rest
@@ -13 +13 @@ A bus encrypts everything it stores: event payloads, event metadata, subscriber
-## Choosing the key that encrypts a bus
+Amazon EventBridge Custom Event Bus encrypts all of your data at rest by default, server side, before it is written to storage: event payloads, event metadata, subscriber filter patterns, and subscriber target configurations. You do not need to configure anything, create any keys, or grant any permissions to get encryption at rest, and there is no additional cost for this default encryption.
@@ -15 +15 @@ A bus encrypts everything it stores: event payloads, event metadata, subscriber
-Omit `EncryptionConfiguration` and EventBridge encrypts the bus with 256-bit AES under an AWS owned key. You cannot view or manage that key, its use does not appear in your CloudTrail logs, it costs nothing, it does not count against your AWS KMS quotas, and AWS rotates it monthly. `DescribeEventBus` returns no `EncryptionConfiguration` for such a bus. For more information, see [AWS owned keys](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-owned-cmk) in the _AWS KMS Developer Guide_.
+By default, your data is encrypted using 256-bit Advanced Encryption Standard (AES-256) under an **AWS owned key** , a KMS key that EventBridge owns and manages for you. You cannot view, manage, or use this key, and its use does not appear in your AWS CloudTrail logs. AWS owned keys are free of charge and do not count against the AWS KMS quotas in your account. AWS owned keys are automatically rotated monthly.
@@ -17 +17 @@ Omit `EncryptionConfiguration` and EventBridge encrypts the bus with 256-bit AES
-Set `EncryptionConfiguration.KmsKeyIdentifier` and EventBridge encrypts the bus with your customer managed key. You then control the key policy, rotation, disabling, and deletion, and you see every use of the key in CloudTrail. The key incurs the AWS KMS monthly key fee and request charges. Because EventBridge encrypts and decrypts events locally under a cached branch key (see How the bus uses your key), it makes a few AWS KMS requests per bus per cache window plus rotation; the request count does not grow with your event volume. For more information, see [AWS KMS pricing](https://aws.amazon.com/kms/pricing/).
+For more information, see [AWS owned keys](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html) in the _AWS Key Management Service Developer Guide_.
@@ -19 +19 @@ Set `EncryptionConfiguration.KmsKeyIdentifier` and EventBridge encrypts the bus
-`KmsKeyIdentifier` accepts a key ID, a key ARN, an alias name such as `alias/orders`, or an alias ARN. EventBridge qualifies a bare key ID or alias name in your account and Region, so a key in another account must be named by its full key ARN. An alias is resolved to its key when you create or update the bus, and the create and describe responses return that key ARN. Re-pointing the alias later does not change the key a bus uses. The key must be a symmetric encryption key (`SYMMETRIC_DEFAULT`, key usage `ENCRYPT_DECRYPT`); EventBridge rejects asymmetric and HMAC keys. A multi-Region key works as an ordinary key: name the replica in the bus's Region, because EventBridge replicates neither your data nor your key material across Regions. Keys with imported key material and keys in an external key store are supported.
+Optionally, you can choose to encrypt an event bus with a symmetric **customer managed KMS key** that you create, own, and manage. A customer managed key gives you:
@@ -20,0 +21 @@ Set `EncryptionConfiguration.KmsKeyIdentifier` and EventBridge encrypts the bus
+  * Full control over the key lifecycle: key policy, rotation, disabling, deletion.
@@ -22,3 +23 @@ Set `EncryptionConfiguration.KmsKeyIdentifier` and EventBridge encrypts the bus
-    aws eventsv2 create-event-bus \
-        --name orders \
-        --encryption-configuration KmsKeyIdentifier=arn:aws:kms:us-east-1:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab
+  * CloudTrail visibility into how EventBridge uses your key.
@@ -26 +25 @@ Set `EncryptionConfiguration.KmsKeyIdentifier` and EventBridge encrypts the bus
-Your key encrypts the event payloads and metadata that the bus retains, the copies held for each subscriber during delivery, and the subscriber filters and target configuration. Four things are not encrypted with your key, because EventBridge needs them to route and look up events: the bus name, ARN, and account ID; the event group ID that orders FIFO delivery, so do not put sensitive data in it; the deduplication ID, which EventBridge stores as a one-way hash; and internal match results and sequence numbers. The storage services encrypt those at rest with their own keys.
+  * The ability to scope access with KMS key policy conditions, per event bus.
@@ -28 +26,0 @@ Your key encrypts the event payloads and metadata that the bus retains, the copi
-## How the bus uses your key
@@ -30 +27,0 @@ Your key encrypts the event payloads and metadata that the bus retains, the copi
-When you configure a customer managed key, EventBridge creates a _branch key_ for the bus: an intermediate key, stored in a service-managed table and wrapped by your AWS KMS key, following the AWS Encryption SDK [Hierarchical Keyring](https://docs.aws.amazon.com/encryption-sdk/latest/developer-guide/use-hierarchical-keyring.html). EventBridge derives a data key from the branch key for each event, so it encrypts and decrypts events locally without a AWS KMS call per event.
@@ -32 +28,0 @@ When you configure a customer managed key, EventBridge creates a _branch key_ fo
-  * When you publish an event, EventBridge encrypts it under the bus's branch key before writing it to storage.
@@ -34 +30 @@ When you configure a customer managed key, EventBridge creates a _branch key_ fo
-  * When EventBridge delivers an event, it decrypts the event to evaluate filters and to deliver it. The target receives the decrypted event; encryption at the target is the target service's responsibility.
+Customer managed keys incur AWS KMS charges: a monthly fee for the key, and charges for the KMS API requests made to it. These requests also count against the AWS KMS request quotas in your account. Because EventBridge encrypts and decrypts events locally under a cached branch key (see How Custom Event Bus uses a Customer Managed KMS Key for encryption at rest), its KMS request volume is a few calls per event bus per cache window plus key rotation — it does not grow with your event volume. For details, see [AWS Key Management Service Pricing](https://aws.amazon.com/kms/pricing/).
@@ -36 +32 @@ When you configure a customer managed key, EventBridge creates a _branch key_ fo
-  * EventBridge caches the branch key in memory for up to 15 minutes. When the cache expires, it calls `kms:Decrypt` on your key to unwrap the branch key again.
+## Encrypting Data at Rest using Customer Managed KMS Keys for Custom Event Bus
@@ -38 +34 @@ When you configure a customer managed key, EventBridge creates a _branch key_ fo
-  * EventBridge creates a new branch key version about every 30 days and keeps the older versions, so events written earlier stay readable for the bus's retention period.
+### How Custom Event Bus uses a Customer Managed KMS Key for encryption at rest
@@ -39,0 +36 @@ When you configure a customer managed key, EventBridge creates a _branch key_ fo
+**What is encrypted with your key** (per event bus):
@@ -40,0 +38 @@ When you configure a customer managed key, EventBridge creates a _branch key_ fo
+  * Event payloads and event metadata, stored for the bus's retention period (1-365 days) in the bus's event storage and in per-subscriber delivery storage.
@@ -41,0 +40 @@ When you configure a customer managed key, EventBridge creates a _branch key_ fo
+  * Subscriber filter patterns and target configurations, stored with the bus's configuration.
@@ -43 +41,0 @@ When you configure a customer managed key, EventBridge creates a _branch key_ fo
-EventBridge reaches your key on two paths, and the key policy must allow both. For the checks it runs while your API call is in progress, it uses your credentials, forwarded from the call. For the work it does after the call returns, such as delivering events and managing the branch key, it acts as the `events.amazonaws.com` service principal, because your credentials are no longer available.
@@ -45 +42,0 @@ EventBridge reaches your key on two paths, and the key policy must allow both. F
-## Writing the key policy
@@ -47 +44,53 @@ EventBridge reaches your key on two paths, and the key policy must allow both. F
-Add three statements to the key policy: one that lets your principals validate the key, one that lets them pass the access checks EventBridge runs with their credentials, and one for the `events.amazonaws.com` service principal. Every AWS KMS request EventBridge makes for a bus carries the encryption context key `aws:events:event-busv2:arn` with the bus ARN, on both access paths, so the second and third statements are scoped to one bus. A bus ARN ends in a suffix that EventBridge generates at creation, so match it with `StringLike` and a trailing `/*`. Keep your own key administration statements in the policy as well. Replace the account, Region, role, and bus name in the following example.
+
+**What is not encrypted with your key:**
+
+  * Resource identifiers that EventBridge needs for routing and lookup: bus name, bus ARN, account ID.
+
+  * The message group ID, which orders FIFO delivery. Avoid placing sensitive data in this field.
+
+  * The message deduplication ID. EventBridge stores it as a one-way hash.
+
+  * Internal service metadata: subscription match results, sequence numbers.
+
+
+
+
+These items are still encrypted at rest by the underlying storage services, not by your key.
+
+**How encryption works.** When you configure a customer managed key on an event bus, EventBridge creates a **branch key** for that bus. The branch key is an intermediate key. It is stored in a service-managed table, wrapped by your KMS key, following the AWS Encryption SDK [Hierarchical Keyring](https://docs.aws.amazon.com/encryption-sdk/latest/developer-guide/use-hierarchical-keyring.html). EventBridge uses the branch key to derive per-event data encryption keys. So events are encrypted and decrypted locally, without a KMS call per event:
+
+  * When you publish an event, EventBridge encrypts it under the bus's branch key before any write to storage.
+
+  * When EventBridge delivers an event, it decrypts the event for filter evaluation and delivery.
+
+  * **EventBridge sends the decrypted event to your target.** Encryption at rest at the destination is the destination service's responsibility.
+
+  * The branch key is cached in service memory for up to **15 minutes**. On cache expiry, EventBridge calls `kms:Decrypt` against your key to unwrap the branch key again.
+
+  * EventBridge rotates the branch key by creating a new version approximately every **30 days**. Older versions are retained so previously written events remain readable for the bus's retention period.
+
+
+
+
+**Two access paths.** EventBridge accesses your key in exactly two ways. For synchronous operations and authorization checks, it uses **your credentials** , forwarded from your API call. For asynchronous work (event delivery, the branch-key lifecycle) it acts as the **`events.amazonaws.com` service principal**, because your API call has completed and your credentials are no longer available. Your key policy governs both paths, as described below.
+
+### Configuring a Customer Managed KMS Key on an event bus
+
+Supported key types:
+
+  * **Symmetric encryption keys only** (`SYMMETRIC_DEFAULT`, key usage `ENCRYPT_DECRYPT`). Asymmetric keys and HMAC keys are rejected.
+
+  * Multi-Region keys are supported as ordinary keys: use the replica in the event bus's Region. EventBridge does not replicate your data or your key material across Regions.
+
+  * Keys with imported key material and keys in an external key store (XKS) are supported.
+
+
+
+
+**Key identifier.** Specify the key by its **key ARN**.
+
+#### Configuring permissions to use a Customer Managed KMS Key
+
+Your key policy needs three statements for EventBridge Custom Event Bus. Replace the example account, Region, role, and bus name.
+
+An [encryption context](https://docs.aws.amazon.com/kms/latest/developerguide/encrypt_context.html) is a set of non-secret key-value pairs that AWS KMS cryptographically binds to a request, and that you can use as a condition for authorization in key policies. Every KMS request EventBridge makes for an event bus includes an **encryption context** that binds the request to that bus's ARN, so each statement below can be scoped to a single bus. The context key is `aws:events:event-busv2:arn` and its value is the bus ARN, on every request EventBridge makes — whether with your credentials or as the service principal. Scoping down access to the Customer Managed KMS Key covers scoping in more detail. The trailing `/*` in the encryption-context values matches the bus ARN's suffix, which EventBridge generates at creation (`arn:aws:events:`region`:`account`:event-busv2/`name`/`suffix``).
@@ -52 +101 @@ Add three statements to the key policy: one that lets your principals validate t
-        "Id": "eventbridge-custom-event-bus-key-policy",
+      "Id": "eventbridge-eventbus-v2-cmk-policy",
@@ -79 +128 @@ Add three statements to the key policy: one that lets your principals validate t
-                        "kms:EncryptionContext:aws:events:event-busv2:arn": "arn:aws:events:us-east-1:111122223333:event-busv2/orders/*"
+              "kms:EncryptionContext:aws:events:event-busv2:arn": "arn:aws:events:us-east-1:111122223333:event-busv2/my-bus/*"
@@ -97 +146 @@ Add three statements to the key policy: one that lets your principals validate t
-                        "kms:EncryptionContext:aws:events:event-busv2:arn": "arn:aws:events:us-east-1:111122223333:event-busv2/orders/*"
+              "kms:EncryptionContext:aws:events:event-busv2:arn": "arn:aws:events:us-east-1:111122223333:event-busv2/my-bus/*"
@@ -104 +153 @@ Add three statements to the key policy: one that lets your principals validate t
-`AllowKeyValidationThroughEventBridge` lets your principals validate the key when they create or update a bus. EventBridge calls `kms:DescribeKey` with your credentials to confirm that the key exists, is symmetric, and is enabled. `DescribeKey` takes no encryption context, so this statement has none; `kms:ViaService` limits it to requests that come through EventBridge.
+**Purpose of each statement:**
@@ -106 +155 @@ Add three statements to the key policy: one that lets your principals validate t
-`AllowKeyUseThroughEventBridge` authorizes the access checks that EventBridge runs with your credentials before it accepts a key configuration and before it writes or reads encrypted data for you, so that you cannot configure a key that the service's later, asynchronous work cannot use. The checks are AWS KMS dry runs: they authorize but encrypt and decrypt nothing. They are billed as standard AWS KMS requests and count against your AWS KMS request quotas; see [Testing your permissions](https://docs.aws.amazon.com/kms/latest/developerguide/testing-permissions.html) in the _AWS KMS Developer Guide_. Each operation checks the actions that its later work performs:
+  * **`AllowKeyValidationThroughEventBridge`** lets your principals validate the key when creating or updating an event bus. EventBridge calls `kms:DescribeKey` with your credentials to confirm the key exists, is symmetric, and is enabled. The `DescribeKey` API has no encryption-context parameter. So this statement has no encryption-context condition. The `kms:ViaService` condition limits this statement's grant to requests that come through EventBridge.
@@ -108 +157 @@ Add three statements to the key policy: one that lets your principals validate t
-  * `CreateEventBus` with a customer managed key checks `kms:GenerateDataKeyWithoutPlaintext`, `kms:ReEncryptFrom`, `kms:ReEncryptTo`, and `kms:Decrypt`, the actions that branch key creation and later reads perform.
+  * **`AllowKeyUseThroughEventBridge`** authorizes the access checks EventBridge runs **with your credentials**. EventBridge runs these checks before it accepts a key configuration and before it writes or reads encrypted data on your behalf. So you cannot configure a key that EventBridge's later, asynchronous processing cannot use. The checks are KMS _dry runs_ : they authorize but do not encrypt or decrypt anything. Dry-run requests are billed as standard KMS API requests and count against your KMS request quotas; see [Testing your permissions](https://docs.aws.amazon.com/kms/latest/developerguide/testing-permissions.html) in the _AWS Key Management Service Developer Guide_. Per operation:
@@ -110 +159 @@ Add three statements to the key policy: one that lets your principals validate t
-  * `UpdateEventBus` that changes the key checks `kms:Decrypt` on the current key, and `kms:Encrypt` and `kms:Decrypt` on the new key.
+    * `CreateEventBus` with a customer managed key checks `kms:GenerateDataKeyWithoutPlaintext`, `kms:ReEncryptFrom`/`kms:ReEncryptTo`, and `kms:Decrypt`. These are the actions that branch-key creation and later reads perform.
@@ -112 +161 @@ Add three statements to the key policy: one that lets your principals validate t
-  * `PutEvents` and `PutRawEvents` on a bus with a customer managed key check `kms:Decrypt`. A producer that cannot read the bus's events back cannot write them either. Without it, the publish call fails with `AccessDeniedException` naming `KMS_ACCESS_DENIED`.
+    * An `UpdateEventBus` key change checks `kms:Decrypt` on the current key, plus `kms:Encrypt` and `kms:Decrypt` on the new key. These are the actions the key transition performs.
@@ -114 +163 @@ Add three statements to the key policy: one that lets your principals validate t
-  * `CreateSubscriber` and `UpdateSubscriber` check `kms:Decrypt`, because subscriber configuration is encrypted under the bus key.
+    * `PutEvents` / `PutRawEvents` on a bus with a customer managed key checks `kms:Decrypt`. A caller who cannot read the bus's events back may not write them either.
@@ -115,0 +165 @@ Add three statements to the key policy: one that lets your principals validate t
+    * `CreateSubscriber` / `UpdateSubscriber` checks `kms:Decrypt`, because subscriber configuration is encrypted under the bus key.
@@ -116,0 +167 @@ Add three statements to the key policy: one that lets your principals validate t
+**Choosing principals for this statement.** You can list individual role or user ARNs in the `Principal`, or use the account root principal to delegate this access to IAM policies in your account.
@@ -117,0 +169 @@ Add three statements to the key policy: one that lets your principals validate t
+  * **`AllowEventBridgeServicePrincipal`** authorizes the work EventBridge performs **as the service** after your API call completes, when your credentials are no longer available:
@@ -119 +171 @@ Add three statements to the key policy: one that lets your principals validate t
-So the `Principal` of this statement must cover every role that creates or updates the bus, publishes to it, or creates subscribers on it. List the role ARNs, or name the account root principal to delegate the decision to the IAM policies in your account.
+    * `kms:GenerateDataKeyWithoutPlaintext` and `kms:ReEncryptFrom`/`kms:ReEncryptTo`: EventBridge creates the bus's branch key, and creates new branch-key versions on rotation.
@@ -121 +173 @@ So the `Principal` of this statement must cover every role that creates or updat
-`AllowEventBridgeServicePrincipal` authorizes the work EventBridge performs as the service after your call completes. `kms:GenerateDataKeyWithoutPlaintext`, `kms:ReEncryptFrom`, and `kms:ReEncryptTo` create the bus's branch key and its new versions on rotation. `kms:Decrypt` unwraps the branch key to deliver events, to load subscriber configuration, and to return decrypted configuration on describe calls. `kms:Decrypt` with `kms:Encrypt` re-wraps the branch key when you change the bus's key.
+    * `kms:Decrypt`: EventBridge unwraps the branch key to deliver events, to load subscriber configuration, and to return decrypted configuration on describe calls.
@@ -123 +175 @@ So the `Principal` of this statement must cover every role that creates or updat
-The key can live in another account, for example a central security account. Put all three statements in that key's policy, with the bus account's roles as the principals of the first two and the bus account's bus ARN in the encryption context values. The bus account's roles also need IAM identity policies that allow the same AWS KMS actions on the key ARN, because cross-account AWS KMS access requires permission on both sides. Name the key by its full key ARN.
+    * `kms:Decrypt` and `kms:Encrypt`: EventBridge re-wraps the branch key when you change the bus's KMS key.
@@ -125 +177 @@ The key can live in another account, for example a central security account. Put
-## Scoping the key policy to one bus
+This statement uses the same encryption-context condition as `AllowKeyUseThroughEventBridge`. Every request EventBridge makes for a bus, on either access path, carries `aws:events:event-busv2:arn` with the bus ARN, so both statements bind key use to the specific event bus.
@@ -127 +178,0 @@ The key can live in another account, for example a central security account. Put
-To limit a statement to one bus, condition it on `kms:EncryptionContext:aws:events:event-busv2:arn`. Before the bus exists, use `StringLike` with a trailing `/*`, as in the preceding policy. For an existing bus, you can match the exact ARN that `DescribeEventBus` returns with `StringEquals`. Every request made with your credentials also populates `kms:ViaService` with `events.`region`.amazonaws.com`, so you can restrict your principals to using the key through EventBridge only.
@@ -129 +179,0 @@ To limit a statement to one bus, condition it on `kms:EncryptionContext:aws:even
-Requests that EventBridge makes as the service principal carry `aws:SourceArn` with the bus ARN and `aws:SourceAccount` with the bus account. Add them to `AllowEventBridgeServicePrincipal` so that EventBridge can use your key only for your own buses.
@@ -132,3 +182,12 @@ Requests that EventBridge makes as the service principal carry `aws:SourceArn` w
-    "Condition": {
-        "StringEquals": { "aws:SourceAccount": "111122223333" },
-        "ArnLike": { "aws:SourceArn": "arn:aws:events:us-east-1:111122223333:event-busv2/orders/*" }
+**Cross-account keys:** the key can be in a different account than the event bus (for example, a central security account). In that case, put all three statements in that key's policy. The first two statements' `Principal` entries name the bus account's roles. The encryption-context values name the bus account's bus ARN. Cross-account KMS access requires permission on both sides: in addition to the key policy statements above, the bus account's roles need IAM identity policies that allow the same KMS actions on the key's ARN. Access the key by its full key ARN.
+
+#### Creating a new event bus with a Customer Managed KMS Key
+
+Specify the key ARN in the `EncryptionConfiguration` parameter of [`CreateEventBus`](https://docs.aws.amazon.com/eventbridgev2/latest/APIReference/API_CreateEventBus.html):
+    
+    
+    {
+      "Name": "my-bus",
+      "EncryptionConfiguration": {
+        "KmsKeyIdentifier": "arn:aws:kms:us-east-1:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab"
+      }
@@ -137 +196,26 @@ Requests that EventBridge makes as the service principal carry `aws:SourceArn` w
-Individual publish and delivery operations use the cached branch key and do not re-check the key policy per event. A key policy change, including one that removes EventBridge's access, takes effect on a bus's data handling when the cached branch key expires, within 15 minutes.
+At creation time, EventBridge validates the key and your access with your credentials (the `DescribeKey` and dry-run checks above). EventBridge then provisions the bus's branch key asynchronously, as the service principal. If the service principal statement is missing from your key policy, the bus transitions to `CREATE_FAILED`, and `DescribeEventBus` returns a `StateReason` naming the KMS access failure.
+
+`DescribeEventBus` on a bus with a customer managed key returns its `EncryptionConfiguration`. A bus using the default AWS owned key returns no `EncryptionConfiguration`: EventBridge never returns the AWS owned key.
+
+#### Changing the encryption configuration on an existing event bus
+
+All transitions are supported, via [`UpdateEventBus`](https://docs.aws.amazon.com/eventbridgev2/latest/APIReference/API_UpdateEventBus.html):
+
+  * AWS owned key → customer managed key
+
+  * Customer managed key → different customer managed key
+
+  * Customer managed key → AWS owned key: send `EncryptionConfiguration` **present and empty** (`"EncryptionConfiguration": {}`). Omitting the member entirely means "leave the encryption configuration unchanged".
+
+
+
+
+When you change the key, the bus enters `UPDATING`. EventBridge re-wraps the branch key under the new key. The bus then returns to `ACTIVE`. The branch key itself does not change, so the material protecting your data does not change. Only the wrapping key changes. Consequences: