Securing Amazon EventBridge means controlling three separate paths: who can publish events, who can configure their routing, and what EventBridge may invoke. Encryption protects stored and transmitted data, but an authorized subscriber or target can still receive the payload. Start with those access boundaries, then protect every copy of the event in targets, dead-letter queues, archives, and logs.

Check your bus type first. AWS introduced an enhanced Custom event bus in September 2026. It uses subscribers, built-in retention, and optional ordered delivery. The default bus and Custom event bus – Classic use rules and targets. Both remain available, but their resource ARNs, delivery permissions, encryption configuration, and monitoring differ. This guide identifies the relevant model where that distinction affects security.

Separate publishing, routing, and administration permissions

A producer usually needs permission to publish to one bus. It should not also be able to redirect events, attach arbitrary targets, share the bus, or delete it. Give routing changes to a deployment role and key administration to an appropriate separate role. Review permissions on the destination as well as on EventBridge.

Limit the producer to its event contract

The following illustrative identity policy lets an application publish only OrderCreated events from com.example.orders to a named Classic bus. Replace the example Region, account, bus name, and event values. The EventBridge condition-key reference explains the supported constraints.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": "events:PutEvents",
    "Resource": "arn:aws:events:us-east-1:111122223333:event-bus/orders",
    "Condition": {
      "StringEquals": {
        "events:source": "com.example.orders",
        "events:detail-type": "OrderCreated"
      }
    }
  }]
}

For the new Custom bus, use the full event-busv2/… ARN returned by the service. Its CLI command is aws eventsv2, but its IAM actions still use events:, including events:PutEvents and events:PutRawEvents. Grant only the publishing API the producer uses. See Custom bus names, endpoints, and IAM permissions.

These fields constrain publishing; they do not validate every property inside the payload or prove that an order really exists. Consumers must validate the event schema and authorize sensitive business operations using trusted application data.

Treat routing access as data access

A principal that can create routing to a destination it controls may be able to read matching events. For Classic buses, scope rule and target management and any iam:PassRole permission. When using a target execution role, allow it to invoke only the intended resources. Where a target uses a resource policy, restrict the service principal to the intended rule with supported conditions. Current target-permission guidance distinguishes roles from resource policies; do not assume every target uses the same mechanism.

On the new Custom bus, each subscriber has a delivery role. Scope that role's target permissions and its permission to write failure records, and restrict who may pass it. Cross-account bus sharing uses AWS RAM or bus resource policies. Choose the sharing permission that grants only publishing, subscribing, or the required combination, and constrain subscriber access to the data that account is entitled to receive. Review both the share and the consumer's IAM permissions. See Custom bus access control. Tags are useful policy inputs, but a tag by itself grants no permissions.

Protect payloads and manage encryption deliberately

EventBridge encrypts data in transit with TLS and uses AWS owned keys for encryption at rest by default. AWS owned keys are different from AWS managed keys such as alias/aws/sqs. Use a customer managed KMS key when you need control over its policy and lifecycle or an audit trail of key use. Follow the data-protection guidance for the specific EventBridge resource.

Use the key policy for your bus model

For Classic buses, the service needs the documented KMS permissions, including kms:DescribeKey, kms:GenerateDataKey, and kms:Decrypt. Scope cryptographic use to the intended bus with the supported source or encryption-context conditions. An IAM policy with no service principal is not a complete KMS key policy. Use the Classic bus key-policy instructions while retaining your key-administration permissions.

The new Custom bus has a different encryption policy and context, including checks under caller credentials and asynchronous use by the EventBridge service. Do not copy a Classic key policy unchanged. Protect permissions to disable or delete the key: losing key access can stop publishing and delivery, and deleting the key can make retained events unreadable.

Encrypt destinations independently. A bus's KMS setting does not configure an SQS queue, archive, log group, or application database. Keep secrets and unnecessary personal data out of events, names, tags, and identifiers. For a sensitive record, consider publishing an identifier and letting authorized consumers retrieve the required fields. Our serverless security guide covers the corresponding Lambda and data-storage boundaries.

Use private connectivity for the correct traffic path

Connect VPC clients to the EventBridge API

An interface VPC endpoint lets workloads in your VPC call EventBridge privately through AWS PrivateLink. Select the service for your bus: com.amazonaws.REGION.events for Classic or com.amazonaws.REGION.eventsv2 for the new Custom bus. Enable private DNS where appropriate and allow inbound HTTPS on the endpoint's security group from the client security group. The client also needs an allowed outbound path. Follow EventBridge's VPC endpoint instructions.

Interface endpoints use private network interfaces and DNS; they do not require the gateway-endpoint route-table configuration used by S3 or DynamoDB. An endpoint policy can restrict calls made through that endpoint, but it does not grant IAM permissions or automatically block access through a public service endpoint.

A producer's interface endpoint does not put EventBridge inside that producer's VPC or determine every target-delivery path. For private HTTPS API destinations, EventBridge supports connections using VPC Lattice resource configurations. Configure that path explicitly using the private API connection guide. Keep API credentials in the connection's supported authorization configuration, rather than embedding them in event bodies or URLs.

Secure failed events as carefully as successful ones

Configure retries and a failure destination before sending production traffic. A dead-letter queue holds event data, so restrict who can send, read, purge, or redrive it; set suitable retention and encryption; and assign an owner to investigate failures.

  • Classic rule targets: use a standard SQS DLQ in the rule's Region. Grant EventBridge sqs:SendMessage with the intended rule ARN condition. Retryable failures default to up to 185 retries over 24 hours; some permanent errors go directly to the DLQ. See Classic DLQ permissions and retry behavior.
  • New Custom bus subscribers: set RetryPolicy and OnFailureConfiguration. The subscriber's delivery role needs permission to send failure records to the selected queue. The defaults are five attempts within 300 seconds, rather than Classic's retry window. The queue holds failure records, not the original payloads; recover the events by replaying from the bus before retention expires. A FIFO subscriber can use a FIFO failure queue. See subscriber retries and recovery and delivery-role permissions.

If the queue uses SSE-KMS, give the actual producer and consumers the required KMS access. For service-principal delivery from Classic EventBridge, use SSE-SQS or a customer managed key with the appropriate policy; do not assume the unmodifiable alias/aws/sqs policy authorizes that integration. The SQS access-denied guide covers queue and key permissions.

A delivery DLQ captures failure to hand an event to a target. It does not capture every failure inside an application after the target accepted it. Configure the target's own processing retries and failure handling, and make redrives safe to repeat. Our EventBridge and SQS comparison explains these two failure boundaries.

Audit configuration changes and verify delivery

Choose the audit events you need

Use CloudTrail to investigate bus, routing, sharing, and permission changes. Event publishing is a data-plane operation: Classic PutEvents data events require explicit configuration, incur charges, and do not appear in Event history. Cross-account publishing records are delivered to the caller's account, so the bus owner's trail alone is not a complete publishing audit. Check CloudTrail coverage for your API and account boundary.

Monitor failures without exposing unnecessary payloads

For Classic rules, monitor failed and throttled invocations, InvocationsSentToDLQ, and InvocationsFailedToBeSentToDLQ. New Custom subscribers use the AWS/EventsV2 namespace, including EventsDelivered, EventsDropped, OnFailureDestinationDelivered, and OnFailureDestinationFailed. Enable subscriber logging and its log delivery destination when you need diagnostic records; it is not enabled automatically. See Custom bus observability.

Restrict log access and retention. Payload logging can create another readable copy of sensitive data; even error-only logs can contain a failed event. Use non-sensitive correlation identifiers to trace publishing, delivery, and the consumer's final outcome.

Verify each boundary before production

Test an allowed publisher and a publisher that should be denied. Publish matching and nonmatching events, confirm exactly which destinations receive them, and deliberately exercise a target permission failure in a test environment. Verify the DLQ write, its alarm, and a safe recovery path. Inspect the effective bus, role, target, key, and endpoint policies together. A successful publish response proves neither that routing matched nor that the application's work completed.