CloudWatch Events (EventBridge) in AWS - Commands & Configuration

Introduction

CloudWatch Events, now called EventBridge, helps you watch for changes or actions in your AWS environment and respond automatically. It solves the problem of manually checking or reacting to events by letting you set rules that trigger actions when something happens.

When you want to automatically start a backup every day at a specific time.

When you need to trigger a Lambda function whenever a new file is uploaded to an S3 bucket.

When you want to send a notification if an EC2 instance changes its state, like stopping or starting.

When you want to route events from your own applications to AWS services without polling.

When you want to connect different AWS services to work together based on events.

Config File - eventbridge-rule.json

eventbridge-rule.json

{
  "Name": "daily-backup-rule",
  "ScheduleExpression": "rate(1 day)",
  "State": "ENABLED",
  "Targets": [
    {
      "Id": "backupLambda",
      "Arn": "arn:aws:lambda:us-east-1:123456789012:function:dailyBackup"
    }
  ]
}

This JSON file defines a CloudWatch Events rule named daily-backup-rule. It triggers every day using the rate(1 day) schedule. The rule is enabled and targets a Lambda function with the specified ARN. When the rule triggers, it runs the Lambda function to perform the backup.

Commands

This command creates or updates a CloudWatch Events rule named 'daily-backup-rule' that triggers once every day. It enables the rule so it can start working immediately.

Terminal

aws events put-rule --name daily-backup-rule --schedule-expression "rate(1 day)" --state ENABLED

Expected Output

{"RuleArn":"arn:aws:events:us-east-1:123456789012:rule/daily-backup-rule"}

→

--name - Sets the name of the event rule.

→

--schedule-expression - Defines how often the rule triggers using a rate or cron expression.

→

--state - Enables or disables the rule.

This command attaches a target to the rule. The target is a Lambda function that will run when the rule triggers.

Terminal

aws events put-targets --rule daily-backup-rule --targets Id=backupLambda,Arn=arn:aws:lambda:us-east-1:123456789012:function:dailyBackup

Expected Output

{"FailedEntryCount":0,"FailedEntries":[]}

→

--rule - Specifies which rule to attach the target to.

→

--targets - Defines the target(s) that will be triggered by the rule.

This command lists all the CloudWatch Events rules in your account so you can verify that your rule was created.

Terminal

aws events list-rules

Expected Output

Name               State    ScheduleExpression

-----------------------------------------------

daily-backup-rule   ENABLED  rate(1 day)

This command shows the targets attached to the 'daily-backup-rule' so you can confirm your Lambda function is set as a target.

Terminal

aws events list-targets-by-rule --rule daily-backup-rule

Expected Output

Targets:

- Id: backupLambda

  Arn: arn:aws:lambda:us-east-1:123456789012:function:dailyBackup

→

--rule - Specifies the rule to list targets for.

Key Concept

If you remember nothing else from this pattern, remember: CloudWatch Events (EventBridge) lets you automatically react to changes or schedules by connecting events to actions.

Common Mistakes

Creating a rule but forgetting to add targets.

The rule triggers but nothing happens because no action is connected.

Always attach at least one target to your rule using 'put-targets' after creating the rule.

Using an incorrect ARN for the target resource.

The event triggers but fails to invoke the target because the ARN is invalid.

Double-check the ARN format and region for your target resource before attaching it.

Setting the rule state to DISABLED.

The rule will not trigger any events until enabled.

Make sure to set the rule state to ENABLED to activate it.

Summary

Create a CloudWatch Events rule with a schedule or event pattern using 'put-rule'.

Attach targets like Lambda functions to the rule using 'put-targets' to define what happens when the rule triggers.

Verify your rule and targets with 'list-rules' and 'list-targets-by-rule' commands.

Practice

1. What is the primary purpose of AWS CloudWatch Events (EventBridge)?

easy

A. To create virtual servers in the cloud

B. To store large amounts of data for analysis

C. To manage user permissions and access

D. To automatically respond to events by triggering actions

Solution

1. Step 1: Understand EventBridge role

   EventBridge watches for events happening in AWS or custom apps and triggers actions automatically.

2. Step 2: Compare options

   Virtual servers relate to EC2, data storage to S3, user permissions to IAM; only responding to events matches EventBridge.

3. Final Answer:

   To automatically respond to events by triggering actions -> Option D

4. Quick Check:

   EventBridge triggers actions on events = C [OK]

Hint: EventBridge links events to actions automatically [OK]

Common Mistakes:

• Confusing EventBridge with storage or compute services
• Thinking it manages user permissions
• Assuming it creates servers

2. Which of the following is the correct JSON snippet to create a CloudWatch Events rule that triggers every 5 minutes?

easy

A. {"ScheduleExpression": "rate(5 minute)"}

B. {"ScheduleExpression": "cron(0/5 * * * ? *)"}

C. {"ScheduleExpression": "rate(5 min)"}

D. {"ScheduleExpression": "cron(5 * * * ? *)"}

Solution

1. Step 1: Understand schedule syntax

   EventBridge supports rate and cron expressions. For 5-minute intervals, cron syntax is cron(0/5 * * * ? *).

2. Step 2: Check each option

   {"ScheduleExpression": "rate(5 minute)"} uses rate(5 minute) which is invalid syntax (must use 'minutes' plural). {"ScheduleExpression": "cron(0/5 * * * ? *)"} uses correct cron syntax for every 5 minutes. {"ScheduleExpression": "rate(5 min)"} uses 'min' which is invalid. {"ScheduleExpression": "cron(5 * * * ? *)"} triggers at minute 5 every hour, not every 5 minutes.

3. Final Answer:

   {"ScheduleExpression": "cron(0/5 * * * ? *)"} -> Option B

4. Quick Check:

   Cron for every 5 minutes = D [OK]

Hint: Use cron(0/5 * * * ? *) for every 5 minutes [OK]

Common Mistakes:

• Using 'min' instead of 'minutes' in rate expressions
• Confusing cron syntax for intervals
• Using rate with incorrect pluralization

3. Given this EventBridge rule JSON snippet, what will happen when an EC2 instance state changes to 'stopped'?

{
  "Source": ["aws.ec2"],
  "DetailType": ["EC2 Instance State-change Notification"],
  "Detail": {"state": ["stopped"]}
}

medium

A. The rule triggers only when an EC2 instance stops

B. The rule triggers for any EC2 state change

C. The rule triggers only when an EC2 instance starts

D. The rule never triggers

Solution

1. Step 1: Analyze event pattern

   The pattern filters events from source 'aws.ec2' with detail type 'EC2 Instance State-change Notification' and detail state 'stopped'.

2. Step 2: Understand filtering effect

   Only events where the instance state changes to 'stopped' match this pattern, so the rule triggers only then.

3. Final Answer:

   The rule triggers only when an EC2 instance stops -> Option A

4. Quick Check:

   Detail state filter 'stopped' triggers only on stop = A [OK]

Hint: Detail filters limit triggers to specific event states [OK]

Common Mistakes:

• Assuming all EC2 state changes trigger the rule
• Confusing 'stopped' with 'started' state
• Ignoring the detail filter in the event pattern

4. You created an EventBridge rule to trigger a Lambda function on S3 object creation, but the Lambda never runs. What is the most likely cause?

medium

A. The rule's event pattern does not match S3 object creation events

B. The Lambda function has no code

C. S3 does not support EventBridge integration

D. The Lambda function is in a different AWS region

Solution

1. Step 1: Check EventBridge and S3 integration

   S3 supports EventBridge events for object creation, so integration is possible.

2. Step 2: Verify event pattern correctness

   If the event pattern does not correctly specify S3 object creation events, the rule won't trigger the Lambda.

3. Step 3: Consider Lambda region

   EventBridge and Lambda must be in the same region; cross-region triggers do not work.

4. Final Answer:

   The rule's event pattern does not match S3 object creation events -> Option A

5. Quick Check:

   Incorrect event pattern blocks trigger = B [OK]

Hint: Check event pattern matches actual event source and type [OK]

Common Mistakes:

• Assuming Lambda runs without correct event pattern
• Ignoring region mismatch issues
• Believing S3 can't send events to EventBridge

5. You want to create an EventBridge rule that triggers a Lambda function only when an EC2 instance is launched in a specific VPC. Which approach correctly achieves this?

hard

A. Use an event pattern filtering on 'source' as 'aws.ec2' and 'detail-type' as 'EC2 Instance State-change Notification' with 'detail.vpc-id' matching the VPC ID

B. Use a scheduled rule to check EC2 instances every minute and invoke Lambda if any are in the VPC

C. Use an event pattern filtering on 'source' as 'aws.ec2' and 'detail-type' as 'EC2 Instance Launch Successful' with 'detail.vpc-id' matching the VPC ID

D. Use an event pattern filtering on 'source' as 'aws.ec2' and 'detail-type' as 'EC2 Instance State-change Notification' with 'detail.state' as 'running'

Solution

1. Step 1: Identify correct event type for instance launch

   The event 'EC2 Instance Launch Successful' signals a new instance launch, not state changes.

2. Step 2: Filter by VPC ID in event detail

   Filtering on 'detail.vpc-id' ensures only instances in the specific VPC trigger the rule.

3. Step 3: Evaluate other options

   State-change notification with VPC ID does not indicate launch specifically. Scheduled polling is inefficient. State-change to running filters state but not launch event.

4. Final Answer:

   Use an event pattern filtering on 'source' as 'aws.ec2' and 'detail-type' as 'EC2 Instance Launch Successful' with 'detail.vpc-id' matching the VPC ID -> Option C

5. Quick Check:

   Launch event + VPC filter = A [OK]

Hint: Filter on launch event and VPC ID in event detail [OK]

Common Mistakes:

• Using state-change events instead of launch events
• Trying scheduled polling instead of event-driven
• Ignoring VPC ID filter in event pattern