Events from AWS services - Amazon EventBridge

Events from AWS services

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

Event delivery from AWS services

Each AWS service that generates events sends them to EventBridge as either best effort or durable delivery attempts.

  • Best effort delivery means that the service attempts to send all events to EventBridge, but in some rare cases an event might not be delivered.

  • Durable delivery means the service will successfully attempt to deliver events to EventBridge at least once.

    EventBridge will accept all valid events under normal conditions. In cases where events cannot be delivered because of an EventBridge service disruption, they will be retried again later by the AWS service for up to 24 hours.

Once an event is delivered to EventBridge, EventBridge matches it against rules and then follows the retry policy and any dead-letter queue specified for the event target(s).

For a list of AWS services that generate events, see AWS services that generate events.

Accessing AWS service events via AWS CloudTrail

AWS CloudTrail is a service that automatically records events such as AWS API calls. You can create EventBridge rules that use the information from CloudTrail. For more information about CloudTrail, see What is AWS CloudTrail?.

All events that are delivered by CloudTrail have AWS API Call via CloudTrail as the value for detail-type.

To record events with a detail-type value of AWS API Call via CloudTrail, a CloudTrail trail with logging enabled is required.

When using CloudTrail with Amazon S3, you need to configure CloudTrail to log data events. For more information, see Enabling CloudTrail event logging for S3 buckets and objects .

Some occurrences in AWS services can be reported to EventBridge both by the service itself and by CloudTrail. For example, an Amazon EC2 API call that starts or stops an instance generates EventBridge events as well as events through CloudTrail.

CloudTrail supports both API callers and resource owners to receive events in their Amazon S3 buckets by creating trails, and delivers events to API callers through EventBridge. Resource owners in addition to API callers can monitor cross-account API calls through EventBridge. CloudTrail’s integration with EventBridge provides a convenient way to set automated rules-based workflows in response to events.

You can't use AWS Put*Events API call events that are larger than 256 KB in size as event patterns because the maximum size of any Put*Events requests is 256 KB. For more information about the API calls that you can use, see CloudTrail supported services and integrations.

Receiving read-only management events from AWS services

You can set up rules on your default or custom event bus to receive read-only management events from AWS services via CloudTrail. Management events provide visibility into management operations that are performed on resources in your AWS account. These are also known as control plane operations. For more information, see Logging management events in the CloudTrail User Guide.

For each rule on the default or custom event buses, you can set the rule state to control the types of events to receive:

  • Disable the rule so that EventBridge does not match events against the rule.

  • Enable the rule so that EventBridge matches events against the rule, except for read-only AWS management events delivered through CloudTrail.

  • Enable the rule so that EventBridge matches all events against the rule, including read-only management events delivered through CloudTrail.

Partner event buses do not receive AWS events.

Some things to consider when deciding whether to receive read-only management events:

  • Certain read-only management events, such as AWS Key Management Service GetKeyPolicy and DescribeKey, or IAM GetPolicy and GetRole events, occur at a much higher volume than typical change events.

  • You may already be receiving read-only management events, if those events don't start with Describe, Get, or List. For example, events from the following AWS STS APIs are change events, even thought they start with the verb Get:

    • GetFederationToken

    • GetSessionToken

    For a list of read-only management events that do not adhere to the Describe, Get, or List naming convention, by AWS services, see Management events generated by AWS services.

To create a rule that receives read-only management events using the AWS CLI
  • Use the put-rule command to create or update the rule, using parameters to:

    • Specify that the rule belongs on the default event bus, or a specific custom event bus


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


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

The following example illustrates how to match against specific events. Best practice is to define a dedicated rule for matching specific events, for clarity and ease of editing.

In this case, the dedicated rule matches the AssumeRole management event from AWS Security Token Service.

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