CloudWatch Events: What It Is and When to Use It
Definition
Amazon CloudWatch Events was a service that delivered a near real-time stream of system events describing changes in AWS resources, which has now been evolved and rebranded into Amazon EventBridge. [7, 29] It enables developers to build event-driven architectures by creating rules to match incoming events and route them to targets like AWS Lambda functions, Amazon SQS queues, or Amazon SNS topics for processing. [21, 24] While the name "CloudWatch Events" is considered legacy, its core functionality and API are preserved within EventBridge as the default event bus. [6, 7]
How It Works
CloudWatch Events, now part of Amazon EventBridge, operates on the concept of an event bus, which acts as a router for events. [12, 14] The architecture is designed to decouple event producers from event consumers, a core principle of event-driven design.
-
Event Sources: An event source is an AWS service, a custom application, or a third-party Software-as-a-Service (SaaS) application that generates an event. [2] An event is a JSON object that represents a change in an environment, such as an Amazon EC2 instance changing its state from
pendingtorunning, or a new object being created in an Amazon S3 bucket. [12, 24] -
Event Bus: When an event occurs, the source sends it to an event bus. Every AWS account has a default event bus which automatically receives events from over 200 AWS services. [13, 14] This is the direct successor to the original CloudWatch Events functionality. [6] With the evolution to EventBridge, you can also create custom event buses to handle events from your own applications and partner event buses to receive events from SaaS partners like Zendesk or Shopify. [2, 7]
-
Rules: You define rules on an event bus to filter and process incoming events. A rule contains an event pattern that specifies the criteria for matching an event. [12, 24] For example, a rule could be configured to match only events from the
aws.ec2source where the instance state isterminated. Rules can also be set to trigger on a schedule, using cron or rate expressions, a feature that was central to CloudWatch Events for automation. [19, 27] -
Targets: When a rule's event pattern matches an incoming event, the event is sent to one or more specified targets. [21] A target is a resource or endpoint that processes the event. EventBridge supports over 20 AWS services as targets, including AWS Lambda, Amazon SQS, Amazon SNS, and AWS Step Functions. [20, 22] A single rule can invoke up to five targets. [2, 12]
This flow allows for building highly scalable and resilient systems. For instance, when an EC2 instance stops, an event is sent to the default event bus. A rule can match this event and trigger a Lambda function to perform a cleanup task, all without the components having direct knowledge of each other. [2]
Key Features and Limits
As of 2026, the features historically associated with CloudWatch Events are now part of the broader Amazon EventBridge service. [6]
- Default Event Bus: Automatically receives events from over 250 AWS services (management events) at no ingestion cost. [3, 8, 17] This is the core legacy feature of CloudWatch Events.
- Scheduled Events: Trigger actions at regular intervals using cron or rate expressions, similar to a traditional cron job. [19] This is now managed by the more powerful Amazon EventBridge Scheduler. [1, 8]
- Broad Target Integration: Route events to a wide array of AWS services, including Lambda, SQS, SNS, Step Functions, and Kinesis. [22]
- Input Transformation: Customize the JSON payload of an event before it is sent to a target, allowing for cleaner integration between services. [6, 10]
- Cross-Account & Cross-Region: Events can be routed to event buses in other AWS accounts and regions, enabling enterprise-scale architectures. [10, 14]
Service Quotas (Limits):
- Rules per Event Bus: 300 (default, can be increased). [12]
- Targets per Rule: 5. [2, 12]
- Event Payload Size: 1MB (increased from 256KB). [15]
PutEventsAPI Throughput: 400 requests per second (can be increased). [2]- Scheduler Quotas: The EventBridge Scheduler supports up to 10 million schedules per region by default (adjustable to billions) and has high TPS limits for creating and invoking schedules. [18, 23]
Common Use Cases
-
Infrastructure Automation: Automatically respond to changes in your AWS environment. For example, you can trigger an AWS Lambda function to add specific tags to a new EC2 instance as soon as it enters the
runningstate. [19, 24] -
Scheduled Operations (Cron Jobs): Run tasks on a recurring schedule. This is useful for routine maintenance like creating backups of Amazon EBS volumes, stopping development instances overnight to save costs, or generating hourly reports. [19, 21]
-
Security and Compliance Monitoring: React to security-sensitive events in near real-time. A rule can be configured to match an AWS CloudTrail event for a specific API call (e.g.,
DeleteBucketin S3) and send an immediate notification to an Amazon SNS topic for security alerting. [24, 31] -
Decoupling Microservices: In a microservices architecture, instead of services calling each other directly via APIs, they can emit events to an event bus. For example, an
Orderservice can publish anorder.createdevent, which is then consumed independently byNotification,Inventory, andShippingservices, improving resilience and scalability. [4, 22] -
SaaS Application Integration: (An EventBridge enhancement beyond original CloudWatch Events) Ingest events from third-party SaaS applications like Shopify or Datadog and trigger workflows within your AWS environment, without writing custom integration code. [1, 7]
Pricing Model
Amazon EventBridge uses a pay-as-you-go pricing model with several components. [8, 20]
- Events from AWS Services: Events published by AWS services to the default event bus (formerly CloudWatch Events) are free to ingest. [4, 17]
- Custom and Partner Events: You are charged per million events published to a custom or partner event bus. As of early 2026, this is typically $1.00 per million events. [1, 4]
- Cross-Account Delivery: Sending events to an event bus in another AWS account incurs a charge per million events. [8]
- Additional Features: Advanced EventBridge features like Event Replay, Schema Discovery, API Destinations, and Pipes have their own pricing dimensions based on usage (e.g., per million events ingested or per million requests). [4, 8]
The Amazon EventBridge Scheduler has a generous free tier of 14 million invocations per month, after which it is billed per million invocations. [8, 17]
There are no upfront costs or minimum fees. For detailed and current pricing, always refer to the official AWS Pricing page.
Pros and Cons
Pros:
- Serverless and Fully Managed: No infrastructure to manage, patch, or scale. EventBridge scales automatically with your event volume. [1, 22]
- Decoupling and Scalability: Promotes loosely coupled architectures, allowing components to be developed, deployed, and scaled independently. [2, 4]
- Rich Integration Ecosystem: Natively integrates with over 200 AWS services as event sources and dozens as targets, plus third-party SaaS partners. [20, 22]
- Powerful Filtering and Routing: Rules provide a flexible mechanism to filter events based on their content and route them precisely where they need to go. [1]
- Cost-Effective: The free tier for AWS management events and the pay-per-use model make it very inexpensive for many common automation and monitoring tasks. [8, 17]
Cons:
- At-Least-Once Delivery: EventBridge provides at-least-once delivery to targets, meaning a target could occasionally receive the same event more than once. Consumers must be designed to be idempotent (i.e., processing the same event multiple times has no additional effect).
- No Guaranteed Ordering: The order of events is not guaranteed. If strict event ordering is required, a service like Amazon SQS FIFO (First-In, First-Out) queues should be used as a target.
- Throughput Limits: While high, the
PutEventsAPI has default quotas that may require an increase for extremely high-volume custom event workloads. [2]
Comparison with Alternatives
CloudWatch Events vs. Amazon EventBridge This is not a comparison of alternatives but an evolution. Amazon EventBridge is the successor to CloudWatch Events. [6, 7] It includes all the functionality of CloudWatch Events (which now operates as the default event bus within EventBridge) and adds significant new features: [29]
- Custom & Partner Event Buses: Allows ingestion of events from non-AWS sources. [2]
- Schema Registry & Discovery: Infers the structure (schema) of events and allows you to download code bindings for them, accelerating development. [6, 29]
- Event Replay: Archive events and replay them later, useful for testing or recovering from errors. [4]
- API Destinations: Send events to any HTTP endpoint for integration with third-party services that use webhooks. [22]
Amazon EventBridge vs. Amazon SNS (Simple Notification Service)
- Filtering: EventBridge offers complex, content-based filtering on the event body using rules. SNS filtering is simpler and based on message attributes, not the message body itself. [2]
- Integration: EventBridge is designed as a central event bus with deep integration into the AWS fabric and SaaS partners. SNS is a pub/sub messaging service primarily for fanning out notifications to a large number of subscribers (like SQS, Lambda, email, SMS, mobile push). [9]
- Structure: EventBridge uses a structured JSON format for all events. SNS messages can be of any format.
Exam Relevance
CloudWatch Events, now framed as Amazon EventBridge, is a critical topic for several AWS certifications, particularly those focused on architecture, development, and operations.
- AWS Certified Solutions Architect - Associate (SAA-C03): Expect questions on using EventBridge to build decoupled, event-driven architectures, automate infrastructure tasks, and react to changes in AWS resources. [27]
- AWS Certified Developer - Associate (DVA-C02): Focuses on how to use EventBridge to trigger Lambda functions and Step Functions workflows, and how to publish custom events from an application.
- AWS Certified SysOps Administrator - Associate (SOA-C02): Questions will likely cover using EventBridge for automated remediation of issues, scheduling operational tasks, and monitoring for specific CloudTrail events. [28]
- AWS Certified Solutions Architect - Professional (SAP-C02): Advanced scenarios involving cross-account and cross-region event routing, complex event patterns, and designing resilient, enterprise-wide event-driven systems.
Examinees should know the difference between the default bus, custom buses, and partner buses, understand the basic structure of a rule, and be able to identify common use cases for EventBridge versus other services like SQS and SNS. [27]
Frequently Asked Questions
Q: Is CloudWatch Events deprecated?
A: While Amazon EventBridge is the successor and the recommended service for all new development, CloudWatch Events is not strictly deprecated in the sense of being turned off. [7] Its functionality and API are preserved and fully backward-compatible within the EventBridge service, specifically as the default event bus. [6, 29] However, all new features are being added only to EventBridge, so it's best practice to use the EventBridge console and API for all work. [29]
Q: Can I trigger a Lambda function every 10 minutes using CloudWatch Events?
A: Yes. You can create a rule in Amazon EventBridge (which uses the same underlying scheduling mechanism as CloudWatch Events) that triggers on a fixed schedule. [19] You would choose a "Schedule" type rule and specify a rate expression like rate(10 minutes) or a cron expression. The target for this rule would be your AWS Lambda function. [27]
Q: What is the difference between a CloudWatch Alarm and a CloudWatch Event?
A: A CloudWatch Alarm watches a single metric over a specified time period (e.g., average CPU utilization over 5 minutes) and performs an action when the metric's value breaches a threshold. [11, 21] A CloudWatch Event (now an EventBridge rule) triggers in response to a change in state or a specific occurrence (e.g., an EC2 instance terminating, a file uploaded to S3, or a scheduled time). [21] In short, Alarms are for metric thresholds, while Events are for state changes and schedules. [11]
This article reflects AWS features and pricing as of 2026. AWS services evolve rapidly — always verify against the official AWS documentation before making production decisions.