AWS History and Timeline regarding Amazon EventBridge - Overview, Functions, Features, Summary of Updates, and Introduction

First Published:
Last Updated:

This is the fifth installment in the series that I started with the "AWS History and Timeline - Almost All AWS Services List, Announcements, General Availability(GA)", where I extract features from the history and timeline of AWS services (I've previously written about Amazon S3, AWS Systems Manager, Amazon Route 53).

This time, I have created a historical timeline for Amazon EventBridge (formerly Amazon CloudWatch Events), which performs event detection for AWS services, event linkage to other AWS services depending on conditions, and event generation.
Just like before, I am summarizing the main features while following the birth of Amazon EventBridge and tracking its feature additions and updates as a "Current Overview, Functions, Features of Amazon EventBridge".
I hope these will provide clues as to what has remained the same and what has changed, in addition to the features and concepts of each AWS service.

Background and Method of Creating Amazon EventBridge Historical Timeline

The reason for creating a historical timeline for Amazon EventBridge this time is that its predecessor, Amazon CloudWatch Events, which debuted in 2016, has made it easier to implement various automation triggers using AWS services, such as event-driven or schedule-driven events, and event generation, depending on conditions. Because of this, I wanted to organize the information about Amazon EventBridge with the following approach.
  • Tracking the history of Amazon EventBridge and organizing the transition of updates
  • Summarizing the feature list and characteristics of Amazon EventBridge
This timeline primarily references the following blogs and document history regarding Amazon EventBridge.
There may be slight variations in the dates on the timeline due to differences in the timing of announcements or article postings in the references used.
The content posted is limited to major features related to the current Amazon EventBridge and necessary for the feature list and overview description.
In other words, please note that the items on this timeline are not all updates to Amazon EventBridge features, but are representative updates that I have picked out.

Amazon EventBridge Historical Timeline (Updates from January 14, 2016)

Now, onto the timeline for Amazon EventBridge's features. The history of Amazon EventBridge, combined with its predecessor Amazon CloudWatch Events, spans more than ten years from January 2016.
While Amazon EventBridge supports many events and event rule targets, please note that not all are listed here, only a representative subset.

2016 | 2017 | 2018 | 2019 | 2020 | 2021 | 2022 | 2023 | 2024 | 2025 | 2026

* You can sort the table by clicking on the column name.
Date Summary
2016-01-14 Amazon CloudWatch Events, the predecessor of Amazon EventBridge, is introduced as an event notification feature of Amazon CloudWatch. It delivers a near real-time stream of system events that describe changes in AWS resources and routes them to targets such as AWS Lambda functions, Amazon Kinesis streams, and Amazon SNS topics. [Source]
2016-02-24 Amazon EC2 Auto Scaling lifecycle hook events are supported as an event source. [Source]
2016-03-30 Amazon Simple Queue Service (SQS) queues are supported as event rule targets. [Source]
2016-04-19 Scheduled events gain support for cron expressions and rate expressions with one-minute granularity. [Source]
2016-09-09 AWS CodeDeploy deployment state-change events are supported as an event source. [Source]
2016-11-14 Amazon EBS snapshot events are supported as an event source. [Source]
2016-11-18 AWS Trusted Advisor check events are supported as an event source, enabling automated actions and custom notifications. [Source]
2016-11-21 Amazon Elastic Container Service (ECS) state-change events are supported as an event source. [Source]
2016-12-01 AWS Health events are supported as an event source. This enables automation that reacts to the AWS service health notifications surfaced by the AWS Personal Health Dashboard announced at the same time. [Source]
2017-03-07 Amazon EMR cluster state-change events are supported as an event source, and Amazon EC2 instance commands (via Run Command) and AWS Step Functions state machines are supported as event rule targets. [Source] [Source] [Source]
2017-06-29 Cross-account event delivery is supported, and AWS CodePipeline and Amazon Inspector are supported as event rule targets. An event bus can now receive events sent from other AWS accounts. [Source] [Source] [Source]
2017-08-03 AWS CodeCommit and AWS CodeBuild state-change events are supported as event sources. [Source] [Source]
2017-09-08 AWS CodePipeline and AWS Glue events are supported as event sources, and AWS Batch is supported as an event rule target. [Source] [Source]
2017-12-13 AWS CodeBuild is supported as an event rule target. [Source]
2018-06-28 Interface VPC endpoints (AWS PrivateLink) are supported. It becomes possible to establish a private connection between an Amazon VPC and Amazon CloudWatch Events (now Amazon EventBridge) without traversing the public internet. [Source]
2019-03-21 Tagging of event rules is supported. [Source]
2019-07-11 Amazon EventBridge is announced as a standalone AWS service that extends Amazon CloudWatch Events, adding SaaS partner integration and reaching General Availability (GA). [Source]
2019-10-07 AWS CloudFormation supports Amazon EventBridge resources. CloudFormation adds the EventBus resource and the EventBusName parameter for the EventBusPolicy and Rule resources. [Source]
2019-11-21 Amazon Elastic Container Registry (ECR) events are supported as an event source. [Source]
2019-12-01 Schema management and code bindings are introduced with the Amazon EventBridge Schema Registry in preview. Schemas define the structure of events, and code bindings let IDEs handle events as typed objects. [Source]
2020-02-10 Content-based filtering becomes available for event patterns in event rules. Rules can now match events using operators such as prefix matching, numeric range matching, and anything-but matching, in addition to exact matching. [Source]
2020-02-24 Tagging becomes available for event buses. [Source]
2020-04-30 The Amazon EventBridge Schema Registry becomes generally available, supporting OpenAPI. [Source]
2020-09-30 The Schema Registry supports schemas in JSON Schema Draft 4 format. Schemas can also be exported using the EventBridge API. [Source]
2020-10-08 Retry policies and dead-letter queues (DLQs) for targets are supported. Events that cannot be delivered to a target can be retried according to a policy and captured in an Amazon SQS dead-letter queue. [Source]
2020-11-05 Event archiving and replay functions are supported. Events received on an event bus can be archived with an optional retention period and replayed later to the rules associated with the bus. [Source]
2020-11-24 Server-side encryption (SSE) is supported on the event bus, and default service quotas are increased. [Source]
2021-03-02 Propagation of AWS X-Ray trace context is supported, so events can be traced end to end with AWS X-Ray. [Source]
2021-03-04 API Destinations are supported, letting event rules invoke external HTTP APIs as targets. Basic, OAuth, and API key authentication methods are supported. [Source]
2021-04-15 Cross-Region event delivery is supported on the event bus. Event rules can now target event buses in other AWS Regions. [Source]
2021-05-19 Sending and receiving events between event buses in the same account and Region is supported. [Source]
2021-07-15 AWS Glue workflows are supported as targets for event rules. This enables event-driven ETL workflows that start when an EventBridge event matches a rule. [Source]
2021-08-30 EC2 Image Builder events are supported, enabling notifications and automation through Amazon EventBridge. [Source]
2021-09-03 The Schema Registry supports discovering the schemas of cross-account events on an event bus and automatically registering them. [Source]
2021-11-18 Amazon DevOps Guru insight events are supported as an event source. [Source]
2022-03-11 The Sandbox feature is added to the Amazon EventBridge console (AWS Management Console). It allows testing event patterns and input transformers without creating or modifying a rule. [Source]
2022-04-07 Global endpoints are supported, providing automatic failover of event ingestion to a secondary Region. Event replication can optionally copy events asynchronously from the primary Region to the secondary Region. [Source]
2022-08-11 Receiving events from GitHub, Stripe, and Twilio using inbound webhooks becomes possible. Quick Start CloudFormation templates create HTTP endpoints backed by AWS Lambda function URLs that are preconfigured with security best practices for these SaaS providers. [Source]
2022-11-10 Amazon EventBridge Scheduler is launched, adding a serverless scheduler to the EventBridge family. EventBridge Scheduler creates, runs, and manages one-time and recurring scheduled tasks at scale that can invoke more than 200 AWS services, using cron, rate, or one-time expressions with time zone and daylight saving time support. [Source]
2022-11-14 Enhanced content-based filtering capabilities are added to event patterns. The update introduces suffix filtering, case-insensitive matching (equals-ignore-case), and $or matching across multiple fields within a single rule, and widens the supported numeric range. [Source]
2022-12-01 Amazon EventBridge Pipes becomes generally available, adding point-to-point integrations between event producers and consumers to the EventBridge family. Pipes connects sources such as Amazon SQS, Amazon Kinesis Data Streams, Amazon DynamoDB Streams, Amazon MSK, self-managed Apache Kafka, and Amazon MQ to the same targets supported by event buses, with optional filtering and an optional enrichment step using AWS Lambda, AWS Step Functions, API Destinations, or Amazon API Gateway. [Source]
2023-03-30 Amazon EventBridge Scheduler expands to 18 additional AWS Regions. The expansion broadens Scheduler availability from its initial nine Regions to most commercial Regions. [Source]
2023-08-02 Amazon EventBridge Scheduler adds automatic deletion of schedules after completion. One-time schedules and recurring schedules with an end date can delete themselves once their last invocation completes, removing the need for custom cleanup processes. [Source]
2023-10-03 Wildcard filters are supported in rule event patterns. Rules can match any character or sequence within a string field, for example file paths ending in a given extension ("dir/*.png") or containing a keyword ("*AcmeCorp*"), eliminating many cases that previously required custom string matching in a Lambda function. [Source]
2023-11-14 Amazon EventBridge Pipes adds logging support to Amazon CloudWatch Logs, Amazon S3, and Amazon Kinesis Data Firehose. Three log levels (error, info, trace) can be selected, and event payloads, service requests, and responses can optionally be included, making it easier to pinpoint whether a failure occurs at the source, the enrichment step, or the target. [Source]
2023-11-17 Read-only AWS CloudTrail management events, such as List, Get, and Describe API calls, are supported on event buses. Previously only mutating API calls were delivered as events; rules can now opt in to receive read-only API events from services integrated with EventBridge, enabling richer security and audit automation. [Source]
2024-01-11 AWS AppSync is supported as a target for event buses. EventBridge rules can stream real-time updates directly into AWS AppSync GraphQL subscriptions so that connected clients are notified of data changes. [Source]
2024-05-14 AWS KMS customer managed keys (CMK) are supported for encrypting events on event buses. Custom and partner events on custom, partner, or default event buses can be encrypted with customer-owned KMS keys instead of AWS owned keys, with key usage auditable through AWS CloudTrail. [Source]
2024-05-22 Filtering capabilities are improved so that anything-but matching can be combined with prefix, suffix, and wildcard filters and applied to arrays of values. A single rule can now match, for example, values that do not end in specific file extensions or that do not contain a specific path pattern. [Source]
2024-08-21 Amazon EventBridge Scheduler raises its default service quotas. The default quota for the number of schedules increases from 1 million to 10 million, and the invocation throughput quota increases from 500 to 1,000 invocations per second in most Regions. [Source]
2024-09-30 An end-to-end event delivery latency metric for event buses is introduced. The new IngestionToInvocationSuccessLatency metric in Amazon CloudWatch tracks the duration between event ingestion and successful delivery to targets, helping detect delays caused by under-performing or unresponsive targets. [Source]
2024-11-12 End-to-end event bus latency is improved by up to 94%. AWS announced that average P99 latency dropped from about 2,235 ms (measured in January 2023) to about 129 ms (measured in August 2024), applied by default across all Regions, benefiting latency-sensitive use cases such as fraud detection and industrial automation. [Source]
2025-01-21 Direct delivery to cross-account targets is supported. Event rules can deliver events directly to AWS services such as Amazon SQS, AWS Lambda, Amazon Kinesis Data Streams, Amazon SNS, and Amazon API Gateway in another AWS account, without an intermediary event bus in the target account, using IAM resource-based policies. [Source]
2025-03-25 Amazon EventBridge Scheduler adds support for AWS PrivateLink. The Scheduler API can be accessed from within an Amazon VPC without traversing the public internet, removing the need for an internet gateway, NAT device, or proxy. [Source]
2025-04-07 Archive and Replay adds support for AWS KMS customer managed keys. Archived events can be encrypted with customer-owned KMS keys, extending the CMK encryption model already available for event buses. [Source]
2025-07-15 Enhanced logging is supported on event buses for improved observability. Matched-rule results, errors, and target invocations can be logged to Amazon CloudWatch Logs, Amazon S3, or Amazon Data Firehose with one of three verbosity levels (error, info, trace), optionally including event payloads. It launched in a subset of AWS Regions and expanded afterward. [Source]
2025-07-16 Amazon EventBridge Scheduler becomes available in all AWS Regions, including AWS GovCloud (US). [Source]
2025-09-17 AWS KMS customer managed key support is extended to rule filter patterns and input transformers. The content of event filter patterns and input transformers, not just event payloads, can now be encrypted with customer-owned keys. [Source]
2025-11-13 Amazon SQS fair queues are supported as targets. Fair queue targets improve message distribution across consumer groups in multi-tenant systems by mitigating the noisy-neighbor effect; rules specify a MessageGroupId as a static value or a JSON path expression. [Source]
2025-11-14 An enhanced visual rule builder is introduced in the Amazon EventBridge console. The schema-aware, drag-and-drop builder integrates the Schema Registry with an updated event catalog covering custom applications and more than 200 AWS services, so filter patterns can be constructed with fewer syntax errors. [Source]
2026-01-29 The maximum event payload size is increased from 256 KB to 1 MB. Event buses can now ingest richer payloads, such as large language model prompts, telemetry signals, and complex JSON structures for machine learning outputs, in a single event without splitting, compressing, or externalizing data; at launch the feature is available in all commercial AWS Regions where Amazon EventBridge is offered, with a small number of exceptions. [Source]
2026-05-04 Data plane API calls (PutEvents) are logged to AWS CloudTrail. CloudTrail can record event bus data-plane activity, including requester identity, source IP address, and timestamp, for security auditing and operational troubleshooting. [Source]
The roots of Amazon EventBridge lie in Amazon CloudWatch's event notification feature, Amazon CloudWatch Events.
Updates as Amazon CloudWatch Events have been primarily centered around event rules, supporting execution on event receipt and scheduling from the beginning, and supporting receipt of events and transmission as targets for many AWS services.
Since becoming independent as Amazon EventBridge, in addition to the support for AWS services in event rules, new features have also been added, such as SaaS partner collaboration, API destinations, event buses, archive and replay, global endpoints, schema registries, and sandbox.
Furthermore, since late 2022, Amazon EventBridge has grown into a service family: Amazon EventBridge Scheduler (a serverless scheduler launched on 2022-11-10) and Amazon EventBridge Pipes (point-to-point integrations, generally available on 2022-12-01) were added alongside the event bus.
Recent updates have focused on richer event pattern filtering (suffix, $or, wildcard, and anything-but combinations), encryption with AWS KMS customer managed keys across event buses, archives, and rule configurations, observability (delivery latency metrics and enhanced logging), significantly lower end-to-end latency, and direct delivery to cross-account targets.

Differences between Amazon EventBridge and Amazon CloudWatch Events

Amazon EventBridge has been created by extending the functionalities of Amazon CloudWatch Events, which was a part of Amazon CloudWatch, as described in the aforementioned timeline.
The service name for Amazon CloudWatch Events has been provided as events (CloudFormation is AWS::Events) from the beginning in AWS SDK and AWS CLI, so the description for Amazon EventBridge and Amazon CloudWatch Events' SDK, CLI, and CloudFormation is similar.
Therefore, if you have been using the service name events (CloudFormation is AWS::Events), there is no need to make any changes even if you were using the API, CLI, SDK, or CloudFormation of Amazon CloudWatch Events to migrate to Amazon EventBridge.
However, the class name in SDK has changed from CloudWatchEvents to EventBridge, so there will be no impact if you are calling the client with events, but if you are using it from the class name level, a name change will be necessary with the SDK update.
The main features that Amazon CloudWatch Events had are now part of Amazon EventBridge's Event Rule and Event Bus.
Amazon EventBridge has extended and inherited the Event Rule and Event Bus of Amazon CloudWatch Events, and in addition, new features such as SaaS partner collaboration, API Destinations, Archive and Replay, Global Endpoints, Schema Registries, and Sandbox have been added.

Current Overview, Functions, Features of Amazon EventBridge

From here, I will introduce the current feature list and overview of Amazon EventBridge.

Amazon EventBridge Use Cases

Amazon EventBridge is typically used in the following scenarios:
  • Event-driven automation: Detecting state changes in AWS resources (such as Amazon EC2 instance state changes, Amazon S3 object creation, or AWS CodePipeline stage transitions) and automatically invoking targets such as AWS Lambda functions or AWS Step Functions state machines.
  • Scheduled processing: Running periodic or one-time tasks with cron, rate, or one-time expressions using scheduled event rules or Amazon EventBridge Scheduler.
  • Decoupling microservices: Publishing custom events from applications to a custom event bus so that producers and consumers can evolve independently in event-driven architectures.
  • SaaS integration: Receiving events from integrated SaaS partners (or from webhook providers such as GitHub, Stripe, and Twilio) and routing them to AWS services.
  • Point-to-point stream and queue integration: Connecting sources such as Amazon SQS, Amazon Kinesis Data Streams, Amazon DynamoDB Streams, Amazon MSK, and Amazon MQ to targets with optional filtering and enrichment using Amazon EventBridge Pipes.
  • Security and audit automation: Reacting to AWS CloudTrail API events (including read-only API events), AWS Health events, and security service findings to trigger notifications and remediation.
  • Multi-Region and multi-account event architectures: Using global endpoints for Regional failover, cross-Region and cross-account event delivery, and direct delivery to cross-account targets.

Amazon EventBridge Key Functions and Features

The main functions and features that Amazon EventBridge currently provides are as follows. Each of them is described in detail in the sections below.
  • Events: JSON objects with a common top-level structure, generated by AWS services, SaaS partners, or user applications (custom events).
  • Event Bus: A pipeline that receives events (default, custom, and partner event buses), with tagging, server-side encryption, AWS KMS customer managed key support, enhanced logging, and support for event payloads of up to 1 MB (increased from 256 KB on 2026-01-29).
  • Event Rule: Rules that match incoming events with event patterns (including content-based filtering, suffix/$or matching, wildcard filters, and anything-but combinations) or run on a schedule, and route events to targets with optional input transformation, retry policies, and dead-letter queues.
  • API Destinations: Invoking external HTTP APIs as rule targets with basic, OAuth, or API key authentication.
  • Archives and Replays: Storing received events and replaying them later, with AWS KMS customer managed key support.
  • Global Endpoints: Automatic failover of event ingestion between two Regions with optional event replication.
  • Schemas and Schema Registries: Managing event schemas, schema discovery, and code bindings.
  • Sandbox: Testing event patterns and input transformers in the console.
  • Amazon EventBridge Scheduler: A serverless scheduler for one-time and recurring tasks that can invoke more than 200 AWS services.
  • Amazon EventBridge Pipes: Point-to-point integrations between event producers and consumers with optional filtering and enrichment.

Events

Amazon EventBridge is an AWS service that detects events generated from AWS services, coordinates events with other AWS services according to rule conditions, and creates custom events. It's designed to detect, control, and operate events.
An event in AWS shares common top-level fields and structures, which are JSON objects that notify the state by customizing some fields under the top-level fields.
Events that occur from AWS services inform about changes in the AWS environment and are generated when the state of AWS service resources changes.
On the other hand, custom events allow users to insert their own fields and data into the common field structure of the event to generate an event.
There are many AWS service events supported by Amazon EventBridge, so please refer to the following links for more details.
Events in Amazon EventBridge - Amazon EventBridge
AWS Events Reference - Amazon EventBridge

Event Patterns

Here is an example of a JSON object about the common field structure of events.
The parts that can be changed in the custom events described later are denoted as (can be customized).
{
  "version": "##Event version: As of the time of writing this article, '0'##",
  "id": "##Event ID: ID in the form '12345678-1234-1234-1234-123456789012'##",
  "detail-type": "##Event detail type: Often a string that indicates the summary of the event (can be customized)##",
  "source": "##Event source: The source of events generated by AWS services is in the form 'aws.XXXXX' (can be customized)##",
  "account": "##The AWS account ID where the event was generated: in the form '123456789012'##",
  "time": "##Time the event was generated (UTC): in the form 'YYYY-MM-DDThh:mm:ssZ' (can be customized)##",
  "region": "##The region string where the event was generated: such as 'ap-northeast-1'##",
  "resources": [##Target resources of the event: if there are target resources, they come in an array format of strings (can be customized)##],
  "detail": {
    ##Event details: Different fields in each AWS service (can be customized)##
  }
}
Next, I will show an example of an event that occurs with the PutObject action of Amazon S3.
{
  "version": "0",
  "id": "12345678-1234-1234-1234-123456789012",
  "detail-type": "Object Created",
  "source": "aws.s3",
  "account": "123456789012",
  "time": "2023-01-01T00:00:00Z",
  "region": "ap-northeast-1",
  "resources": ["arn:aws:s3:::hidekazu-konishi.com"],
  "detail": {
    "version": "0",
    "bucket": {
      "name": "hidekazu-konishi.com"
    },
    "object": {
      "key": "index.html",
      "size": 10,
      "etag": "12345678901234567890123456789012",
      "version-id": "12345678901234567890123456789012",
      "sequencer": "123456789012345678"
    },
    "request-id": "1234567890123456",
    "requester": "123456789012",
    "source-ip-address": "10.0.0.1",
    "reason": "PutObject"
  }
}

Sending Custom Events

Custom events are generated by users inserting their own fields and data into the common field structure of events.
While events that occur from AWS services mainly indicate changes in the state of AWS resources, custom events can be used for various purposes depending on the objective.
Custom events are generated via the AWS CLI, or the AWS SDK API.
Next, I will describe the format of the JSON parameters when sending custom events with the AWS CLI's put-events command.
We will talk about the event bus (Event Bus), which is specified by one of the parameters, EventBusName, later.
[
  {
    "Time": "##Timestamp in RFC3339 compliant format. If not specified, the time of sending will be used.##",
    "Source": "##Any string. If it follows the format used by AWS services, it will be in the format '[alphanumeric lower case].[alphanumeric lower case].～'.##",
    "Resources": [
      "##Resource name. Multiple can be specified in the array. If not specified, it is sent as an empty array.##",
      ...
    ],
    "DetailType": "##Any string. If it follows the DetailType used by AWS services, it becomes a string that represents the summary of the event.##",
    "Detail": "##Any JSON string. Since this parameter itself is in JSON, double quotation marks need to be escaped.##",
    "EventBusName": "##Specify the EventBusName or EventBus ARN to send the custom event. If not specified, the default event bus will be used.##",
    "TraceHeader": "##If using X-Ray, specify the Tracing header.##"
  },
  ...
]
Next, I will show an example of describing the JSON pattern of custom events in a JSON file, and generating custom events from the JSON file with the AWS CLI's put-events command.
[ho2k_com@ho2k-com ~]$ vi entries.json
[ho2k_com@ho2k-com ~]$ cat entries.json
[
  {
    "Time": "2023-01-01T00:00:00Z",
    "Source": "custom.sample",
    "Resources": [
      "sample-resource-a",
      "sample-resource-b"
    ],
    "DetailType": "Custom Sample Event",
    "Detail": "{ \"sample-parameter-key1\": \"sample-parameter-value1\", \"sample-parameter-key2\": \"sample-parameter-value2\" }",
    "EventBusName": "arn:aws:events:ap-northeast-1:123456789012:event-bus/CustomSampleEventBus"
  }
]
[ho2k_com@ho2k-com ~]$ aws events put-events --entries file://entries.json
Then, the following is an example of the JSON of a custom event that occurs when this AWS CLI is run in the ap-northeast-1 region of AWS account 123456789012.
{
  "version": "0",
  "id": "12345678-1234-1234-1234-123456789000",
  "detail-type": "Custom Sample Event",
  "source": "custom.sample",
  "account": "123456789012",
  "time": "2023-01-01T00:00:00Z",
  "region": "ap-northeast-1",
  "resources": ["sample-resource-a", "sample-resource-b"],
  "detail": {
    "sample-parameter-key1": "sample-parameter-value1", 
    "sample-parameter-key2": "sample-parameter-value2"
  }
}

Event Bus

An Event Bus is a pipeline that receives events, and the subsequent Event Rules process events sent to the associated Event Bus based on the rules.
There are two types of Event Buses: the default Event Bus that is provided initially, and the Custom Event Bus that users can create on their own.
As mentioned earlier, a Custom Event can specify which Event Bus to send to, but events without a specified Event Bus are all sent to the default Event Bus in the account/region where the event occurred.
Therefore, if you are only using the default Event Bus, you may receive unwanted events and your Event Rules may become complicated trying to manage these unwanted events.
For this reason, you create a Custom Event Bus to receive only the events that you are evaluating with Event Rules, based on your needs and functionalities.

Event Rule

There are two types of Event Rules: those that execute upon event receipt, and those that execute on a schedule.

Event rules that are executed by receiving events

This type executes when the event received from the associated Event Bus matches the defined event pattern, and sends the event to the target mentioned later.
For example, the following shows an example of an event pattern definition and a sample event to be evaluated for this type of Event Rule.
The sample event to be evaluated shown here matches the event pattern definition example.
Sample Event to Be EvaluatedExample of Event Rule's
Event Pattern Definition
 
{
  "version": "0",
  "id": "12345678-1234-1234-1234-123456789012",
  "detail-type": "Object Created",
  "source": "aws.s3",
  "account": "123456789012",
  "time": "2023-01-01T00:00:00Z",
  "region": "ap-northeast-1",
  "resources": ["arn:aws:s3:::hidekazu-konishi.com"],
  "detail": {
    "version": "0",
    "bucket": {
      "name": "hidekazu-konishi.com"
    },
    "object": {
      "key": "index.html",
      "size": 10,
      "etag": "12345678901234567890123456789012",
      "version-id": "12345678901234567890123456789012",
      "sequencer": "123456789012345678"
    },
    "request-id": "1234567890123456",
    "requester": "123456789012",
    "source-ip-address": "10.0.0.1",
    "reason": "PutObject"
  }
}

{
  "source": [
    "aws.s3"
  ],
  "detail-type": [{
    "anything-but": [
      "AWS API Call via CloudTrail"
    ]
  }],
  "detail": {
    "bucket": {
      "name": [{
        "anything-but": {
          "prefix": "www."
        }
      }]
    },
    "object": {
      "key": [{
        "prefix": "index."
      }],
      "size": [{
        "numeric": [">", 0]
      }]
    },
    "source-ip-address": [{
      "cidr": "10.0.0.0/24"
    }],
    "reason": [{
      "exists": true
    }]
  }
}
I will explain the method of content filtering used in this example.
Content Filtering by Simple Matching
First, the description that defines whether it simply matches the value of the field corresponds to the following part in the above example.
The method of describing pattern matching is to enter the condition in the form of an array in the part of the value of the field to be evaluated.
  "source": [
    "aws.s3"
  ],
Next, I will look at the evaluation methods that "prefix", "anything-but", "numeric", "cidr", and "exists" mean, referring to the above example.
Content Filtering by 'prefix'
If you use "prefix" for the value of the field, you can define that it matches the prefix of the specified string (it matches from the beginning).
In the above example, the following part applies, indicating that it matches from the beginning with "index." (index.html, index.php, index.do, etc. match).
    "object": {
      "key": [{
        "prefix": "index."
      }],
Content Filtering by 'anything-but'
If you use "anything-but" for the value of the field, you can define that it matches all values except the specified one.
In the above example, the following part applies, indicating that any value other than "AWS API Call via CloudTrail" matches (Object Created, Object Deleted, etc. match).
  "detail-type": [{
    "anything-but": [
      "AWS API Call via CloudTrail"
    ]
  }],
Content Filtering by 'prefix' and 'anything-but'
Also, you can use "prefix" and "anything-but" in combination.
In the above example, the following part applies, indicating that a string that does not start with "www." matches (those starting with en., api., etc. match).
    "bucket": {
      "name": [{
        "anything-but": {
          "prefix": "www."
        }
      }]
    },
Content Filtering by 'numeric'
If you use "numeric" for the value of the field, you can define that it matches when the comparison result by the comparison operator is true if the value is a number.
In the above example, the following part applies, indicating that it matches when the number is greater than 0 (you can use the comparison operators "=", ">", "<", ">=", "<=").
      "size": [{
        "numeric": [">", 0]
      }]
Content Filtering with "cidr"
By using the value "cidr" in the field, you can define a match for the specified IPv4 and IPv6 addresses in CIDR format.
In the example above, the relevant part indicates that it matches the CIDR range of "10.0.0.0/24" (10.0.0.0 to 10.0.0.255 are a match).
    "source-ip-address": [{
      "cidr": "10.0.0.0/24"
    }],
Content Filtering with "exists"
By using the value "exists" in the field, you can define an evaluation of the presence or absence of a value.
In the example above, the relevant part indicates that it matches when a value exists (in the case of "exists": false, it matches when it does not exist).
    "reason": [{
      "exists": true
    }]
Event rules of the type that execute upon event reception can be defined by setting an event pattern. When the received event matches the pattern, it sends the received event or a customized event to the target mentioned later.

Event rules that are executed according to a schedule

The scheduled type executes according to a schedule defined in either Cron or Rate format, sending events to the target mentioned later.
About Cron Format Description
The format of the Cron style is as follows.
cron([minute] [hour] [day] [month] [day of the week] [year])
Here are some examples of how to write in Cron format.
cron(0/15 * * * ? *) # Execute every 15 minutes.
cron(0/15 0-9 * * ? *) # Execute every 15 minutes from 0:00-9:45 (UTC+0) [from 9:00-18:45 (UTC+9, JST) in Japan time].
cron(0 0 * * ? *) # Execute at 0:00 every day (UTC+0) [at 9:00 every day (UTC+9, JST) in Japan time].
cron(0 0 1 * ? *) # Execute at 0:00 on the 1st of every month (UTC+0) [at 9:00 on the 1st of every month (UTC+9, JST) in Japan time].
cron(0 15 L * ? *) # Execute at 15:00 on the last day of each month (UTC+0) [at 0:00 on the 1st day of each month (UTC+9, JST) in Japan time].
cron(0 0 ? * MON-FRI *) # Execute at 0:00 every day from Monday to Friday (UTC+0) [at 08:00 every day from Monday to Friday (UTC+9, JST) in Japan time].
cron(0 23 ? * SUN-THU *) # Execute at 23:00 every day from Sunday to Thursday (UTC+0) [at 08:00 every day from Monday to Friday (UTC+9, JST) in Japan time].
The important thing to note is that the time dealt with in EventBridge is UTC and not Local Time(like JST).
Also, in the Cron format notation, be aware that if you specify "day of the week", "day" becomes "?", and if you specify "day", "day of the week" becomes "?".
About Rate Format Description
The format of the Rate style is as follows.
rate([value] [unit])
The available units are minute, minutes, hour, hours, day, days.
Here are some examples of how to write in Rate format.
rate(5 minutes) # Execute every 5 minutes
rate(12 hours) # Execute every 12 hours
rate(1 day) # Execute every day
rate(7 days) # Execute every 7 days
About Events Occurring When Scheduled Execution is Performed
In event rules of the type to be executed on a schedule, an event occurs when the schedule is executed.
This event can be specified as the event to be sent to the resource or endpoint set in the target mentioned later.
Here is an example of an event that occurs when scheduled execution is performed.
The resources contained in "resources" are the ARN of the event rule that performed the scheduled execution.
{
  "version": "0",
  "id": "12345678-1234-1234-1234-123456789012",
  "detail-type": "Scheduled Event",
  "source": "aws.events",
  "account": "123456789012",
  "time": "2023-01-01T00:00:00Z",
  "region": "ap-northeast-1",
  "resources": [
    "arn:aws:events:ap-northeast-1:123456789012:rule/SampleEventRule"
  ],
  "detail": {}
}
Event rules of the type to be executed on a schedule can define a schedule in either Cron or Rate format, and can send either a scheduled execution event or a custom event to the target mentioned later.

Targets

A target is a resource or endpoint that sends events from the event rule.
The conditions under which an event is sent to a target are as follows:
  • The event pattern defined in the event rule of the type to be executed when an event is received matches the event received from the event bus
  • The schedule defined in the event rule of the type to be executed on a schedule matches the date and time
The event sent to the target can be customized as follows:
  • For event rules of the type to be executed when an event is received, the event can be the entire event that matched the event pattern definition, a part of it, a constant (JSON text), or an event defined by an input transformer
  • For event rules of the type to be executed on a schedule, the event can be the entire scheduled execution event, a part of it, a constant (JSON text), or an event defined by an input transformer
Among these, examples of the entire event or a part of it have been introduced for both event rules of the type to be executed when an event is received and event rules of the type to be executed on a schedule, so examples are omitted.
A constant (JSON text) is a method of sending fixed JSON text for a field as an event to a target.
The input transformer is explained in the next section.
Input Transformer
The Input Transformer is a function to convert the JSON structure and the contents of fields before sending an event that matches an event pattern in an event rule, or a constant (JSON text), to a target.
In the input transformer, the Input Path is used to change the variable name, and a template is used to define the output JSON structure.
Here is an example of converting an event using the input path and template in the input transformer and outputting it.
Event Before ConversionInput Transformer
 
{
  "version": "0",
  "id": "12345678-1234-1234-1234-123456789012",
  "detail-type": "Object Created",
  "source": "aws.s3",
  "account": "123456789012",
  "time": "2023-01-01T00:00:00Z",
  "region": "ap-northeast-1",
  "resources": ["arn:aws:s3:::hidekazu-konishi.com"],
  "detail": {
    "version": "0",
    "bucket": {
      "name": "hidekazu-konishi.com"
    },
    "object": {
      "key": "index.html",
      "size": 10,
      "etag": "12345678901234567890123456789012",
      "version-id": "12345678901234567890123456789012",
      "sequencer": "123456789012345678"
    },
    "request-id": "1234567890123456",
    "requester": "123456789012",
    "source-ip-address": "10.0.0.1",
    "reason": "PutObject"
  }
}
* Input Path
{
  "bucket_name" : "$.detail.bucket.name", 
  "object_key": "$.detail.object.key", 
  "action" : "$.detail.reason", 
  "datetime" : "$.time"
}

* Input Transformer Template
{
  "bucket_name" : "<bucket_name>",
  "object_key": "<object_key>",
  "action" : "<action>",
  "datetime" : "<datetime>"
}

* Output Result
{
  "bucket_name" : "hidekazu-konishi.com",
  "object_key": "index.html",
  "action" : "PutObject",
  "datetime" : "2023-01-01T00:00:00Z"
}
Available AWS Services and API Destinations as Targets
Since there are numerous AWS services supported as targets by Amazon EventBridge, please refer to the following link.
Amazon EventBridge targets - Amazon EventBridge
Among them, as of the writing of this article, the main available AWS services and API destinations as targets are as follows.
Service Name Cross-Region Sending Cross-Account Sending
Event Bus Yes Yes
API Destinations (including API sending partners) Yes Yes
API Gateway Yes No
Batch Job Queue No No
CloudWatch Log Group No No
CodeBuild Project No No
CodePipeline No No
EC2 CreateSnapshot API Call No No
EC2 Image Builder No No
EC2 RebootInstances API Call No No
EC2 StopInstances API Call No No
EC2 TerminateInstances API Call No No
ECS Task No No
Firehose Delivery Stream No No
Glue Workflow No No
Incident Manager Response Plan No No
Inspector Assessment Template No No
Kinesis Stream No No
Lambda Function No No
Redshift Cluster No No
SageMaker Pipeline No No
SNS Topic No No
SQS Queue No No
Step Functions state machine No No
Systems Manager Automation No No
Systems Manager OpsItem No No
Systems Manager Run Command No No
With EventBus, it's possible to send and receive events across regions and accounts.
In order to send and receive events across regions and accounts, it's necessary to configure policies on both the sending and receiving sides.
First, in the resource-based policy of the EventBus of the account/region receiving the events, you allow the events:PutEvents from the event rules of the account/region sending the events.
Then, in the permission policy of the IAM role associated with the event rules of the account/region sending the events, you allow the events:PutEvents to the ARN of the EventBus of the account/region receiving the events.
By having the events:PutEvents action allowed in the policies of both the receiving and sending sides, you can send and receive events across regions and accounts.
API Destinations is a feature that allows you to register APIs with EventBridge and specify them as targets, and you can register and use APIs provided by API Destination partners, or APIs you have developed yourself.
EventBridge's API Destinations supports basic, OAuth, and API key authentication methods.
As the API Destinations target is an API, there are no cross-region or cross-account transmission restrictions.
API Gateway does not allow you to specify cross-account transmission, but you can specify cross-region API Gateways as targets using AWS CLI or AWS SDK (cannot be specified from the EventBridge console).
However, you can also register Amazon API Gateway as an API in API Destinations and specify it as a target for EventBridge, enabling cross-account transmission in addition to cross-region.

Sandbox

The Sandbox is a feature of the EventBridge console (AWS Management Console) that allows you to test event patterns and input transformers used in EventBridge rules.
The Sandbox allows you to mainly test the following:
  • Test whether event patterns defined in EventBridge rules match sample events or custom input events.
  • Test the JSON input path, template, and output defined in the Input Transformer using sample events or custom input events.

Archives and Replays

Archives is a feature that allows you to store events received on a specified EventBus.
You can choose to archive only events that match the event pattern you define (or all events), and you can specify the storage period (or unlimited).
Archived events can be replayed.
When replaying archived events, you can specify the destination of the replay from the event rules associated with the event bus (or specify all rules), and you can partially replay by specifying the time frame of the start and end times of the replay, which determines the range of event occurrence times of the archived events.

Global Endpoints

Global Endpoints in EventBridge configures your event bus for fault tolerance across two regions.
To configure global endpoints, you need to set the following:
  • The event buses in your primary and secondary regions.
    The event bus names need to be the same in both regions.
  • Amazon Route 53 health checks to determine failover.
    Although you can set your own Amazon Route 53 health checks, a CloudFormation template is available that uses AWS/Events Namespace's IngestionToInvocationStartLatency metric to determine using Amazon CloudWatch metrics.
  • Enable or disable event replication.
    Event replication asynchronously replicates events from the primary region to the secondary region, so the order of event transmission is not guaranteed.
Please note that there are no additional charges for EventBridge global endpoints, and you will be billed according to the charges for the events sent to the global endpoints.

Schemas and Schema Registries

Schemas define the structure of events handled in EventBridge.
While there are schemas already available, generated by AWS services, users can also create and register custom schemas.
Schema Registries are logical groups for classifying and organizing schemas registered in EventBridge.
From the outset, EventBridge comes with AWS Event Schema Registries, Discovered Schema Registries, and Custom Schema Registries.
Schema Registries can also be newly created for registering user's custom schemas.
Among these, newly discovered schemas are automatically registered in the Discovered Schema Registry by enabling Schema Discovery on the event bus.

Code Bindings

Code Bindings can be downloaded from the registered schemas in the Schema Registry.
Using Code Bindings, when developing with programming languages such as Golang, Java, Python, TypeScript in IDEs etc., events can be handled as objects within the code, and features like validation and autocomplete can be used.
Code Bindings can be downloaded from the EventBridge console, as well as from IDE plugins like AWS Toolkit for Visual Studio Code.

Receiving Events from SaaS Partners

If SaaS partners are integrated with Amazon EventBridge, you can receive events from the services or applications provided by the SaaS partners using event patterns prepared for each SaaS partner.
To receive events from SaaS partners, create a partner event source on each SaaS partner's website, etc., and associate it with the event bus created for the SaaS partner.
EventBridge's console for creating event rules also provides event patterns for each SaaS partner that you can select and customize.

Amazon EventBridge Scheduler

Amazon EventBridge Scheduler is a serverless scheduler, launched on 2022-11-10, that creates, runs, and manages one-time and recurring scheduled tasks as a dedicated capability of the Amazon EventBridge family.
While scheduled event rules on an event bus remain available, EventBridge Scheduler is positioned as the successor for schedule-driven invocation: it supports cron expressions, rate expressions, and one-time schedules, together with time zone awareness (including daylight saving time), flexible time windows, and start and end dates for recurring schedules.
EventBridge Scheduler can directly invoke more than 200 AWS services as targets using universal targets, without requiring an event bus or an event rule.
It also provides operational features for large-scale scheduling, such as automatic deletion of schedules after completion (added on 2023-08-02), access via AWS PrivateLink (added on 2025-03-25), and availability in all AWS Regions (since 2025-07-16).
What is Amazon EventBridge Scheduler? - Amazon EventBridge Scheduler

Amazon EventBridge Pipes

Amazon EventBridge Pipes, generally available since 2022-12-01, provides point-to-point integrations that connect a single event source to a single target, with optional filtering and enrichment steps in between.
Pipes supports sources such as Amazon SQS queues, Amazon Kinesis Data Streams, Amazon DynamoDB Streams, Amazon MSK topics, self-managed Apache Kafka, and Amazon MQ brokers, and delivers events to the same types of targets that event rules support.
The optional enrichment step can transform or augment events with AWS Lambda functions, AWS Step Functions state machines, API Destinations, or Amazon API Gateway before delivery to the target.
Whereas an event bus is suited to fan-out routing of events from many sources to many targets, Pipes is suited to one-to-one integrations that previously required custom polling or glue code; logging to Amazon CloudWatch Logs, Amazon S3, and Amazon Kinesis Data Firehose (added on 2023-11-14) makes it easier to diagnose where a failure occurs in a pipe.
For practical design patterns using EventBridge Pipes, please also refer to the following article on this site.
EventBridge Pipes Event-Driven Architecture Implementation Patterns

Overview Diagram of Amazon EventBridge Features

The relationship of the core event bus functions of Amazon EventBridge can be summarized in the following overview diagram.
(This diagram focuses on the event bus centered features; Amazon EventBridge Scheduler and Amazon EventBridge Pipes described above are provided as separate capabilities within the Amazon EventBridge family.)

Overview Diagram of Amazon EventBridge Features
Overview Diagram of Amazon EventBridge Features


References:
Tech Blog with curated related content
AWS Documentation(Amazon EventBridge)
AWS Documentation(Amazon CloudWatch Events is now Amazon EventBridge)
AWS Documentation(Amazon EventBridge Scheduler)
AWS Documentation(Amazon EventBridge Pipes)
Amazon EventBridge
What's New with AWS?
AWS News Blog

Frequently Asked Questions about Amazon EventBridge History

When did Amazon EventBridge launch?
Amazon EventBridge was announced and became generally available on July 11, 2019, as a standalone AWS service that extends Amazon CloudWatch Events with SaaS partner integration. Its predecessor, Amazon CloudWatch Events, was introduced as an event notification feature of Amazon CloudWatch on January 14, 2016.
What is the difference between Amazon EventBridge and Amazon CloudWatch Events?
Amazon EventBridge extends and inherits the Event Rule and Event Bus capabilities of Amazon CloudWatch Events, using the same underlying service name (events) in the API, AWS CLI, and AWS CloudFormation (AWS::Events). EventBridge adds capabilities that CloudWatch Events did not have, such as SaaS partner event sources, API Destinations, Archives and Replays, Global Endpoints, Schema Registries, and the Sandbox, and has since grown into a family that also includes Amazon EventBridge Scheduler and Amazon EventBridge Pipes.
When did Amazon EventBridge Scheduler launch?
Amazon EventBridge Scheduler launched on November 10, 2022, as a serverless scheduler for one-time and recurring tasks that can invoke more than 200 AWS services. It later added automatic deletion of schedules after completion on August 2, 2023, AWS PrivateLink support on March 25, 2025, and became available in all AWS Regions on July 16, 2025.
When did Amazon EventBridge Pipes become generally available?
Amazon EventBridge Pipes became generally available on December 1, 2022. Pipes provides point-to-point integrations that connect sources such as Amazon SQS, Amazon Kinesis Data Streams, Amazon DynamoDB Streams, Amazon MSK, self-managed Apache Kafka, and Amazon MQ to targets, with optional filtering and enrichment steps.
How has event pattern filtering evolved in Amazon EventBridge?
Content-based filtering for event patterns became available on February 10, 2020. Enhanced filtering with suffix matching, case-insensitive matching, and $or conditions was added on November 14, 2022, wildcard filters were added on October 3, 2023, and combinations of anything-but matching with prefix, suffix, and wildcard filters followed on May 22, 2024.
When did Amazon EventBridge add support for AWS KMS customer managed keys?
AWS KMS customer managed key (CMK) support was added to event buses on May 14, 2024, to Archive and Replay on April 7, 2025, and to rule filter patterns and input transformers on September 17, 2025.
When did global endpoints become available in Amazon EventBridge?
Global endpoints became available on April 7, 2022. They configure an event bus for fault tolerance across two AWS Regions, automatically failing over event ingestion to the secondary Region based on Amazon Route 53 health checks, with optional asynchronous event replication.
How has Amazon EventBridge event delivery latency improved?
Amazon EventBridge introduced the IngestionToInvocationSuccessLatency metric for end-to-end delivery visibility on September 30, 2024, and announced on November 12, 2024, an improvement of up to 94% in end-to-end event bus latency, with average P99 latency dropping from about 2,235 ms to about 129 ms between January 2023 and August 2024.
All dates above follow the primary AWS sources referenced in this article (AWS What's New, AWS News Blog, and the service document history). This article is reviewed regularly to incorporate new Amazon EventBridge launches.

Summary

In this post, I have created a timeline for Amazon EventBridge and looked at the list and overview of its features.

Amazon EventBridge emerged as an expansion of the Amazon CloudWatch's event notification feature, the Amazon CloudWatch Events.
Building on the Event Rule function that Amazon CloudWatch Events had, Amazon EventBridge added features such as customizable Event Rules, Event Bus, and SaaS partner integration, enabling more flexible event control and wider event collaboration.
Since late 2022, it has further grown into a service family with Amazon EventBridge Scheduler and Amazon EventBridge Pipes, while the event bus itself has continued to evolve with richer filtering, AWS KMS customer managed key encryption, improved observability, lower latency, and cross-account delivery.
Covering both event-driven triggers for automation and scheduled executions, Amazon EventBridge is a service you'll inevitably encounter when designing and developing with AWS services.
Therefore, updates to Amazon EventBridge will undoubtedly have some impact on services leveraging AWS in the future.
I would like to continue watching how Amazon EventBridge will provide features in the future.

Furthermore, there is also a timeline of the entire history of AWS services, including services other than Amazon EventBridge, so please take a look if you're interested.

AWS History and Timeline - Almost All AWS Services List, Announcements, General Availability(GA)
I have also written related historical timelines for the services that Amazon EventBridge works most closely with:
This timeline will be updated as Amazon EventBridge continues to evolve.

Written by Hidekazu Konishi