Monitor AWS API Activity by Routing CloudTrail Events to EventBridge (2026)

CloudTrail events are sent to EventBridge, allowing for real-time monitoring and automated responses to AWS API activity.

Imagine you’re trying to keep tabs on everything happening in your AWS account. Not just what you’re doing, but what every service is doing, every user, every instance launch, every security group change. Manually sifting through logs is a nightmare. This integration lets you turn that firehose of API calls into something actionable.

Let’s see it in action. We’ll set up a rule in EventBridge that triggers whenever a specific API call happens, and then have it send a notification to Slack.

First, ensure you have CloudTrail enabled. It’s usually on by default, but it’s good to check. You’ll need at least one trail configured to log management events.

aws cloudtrail describe-trails --query "Trails[?IsMultiRegionTrail].Name"
aws cloudtrail describe-trails --query "Trails[?HomeRegion=='us-east-1'].Name" # Replace us-east-1 with your home region

If you don’t have one, create a trail:

aws cloudtrail create-trail --name my-api-activity-trail --s3-bucket-name my-cloudtrail-log-bucket --is-multi-region-trail --enable-log-file-validation

Now, we need to get these CloudTrail events into EventBridge. This is done via an Event Bus. By default, AWS creates a default event bus. CloudTrail automatically integrates with this default bus for management events. If you’re using a custom event bus, you’ll need to configure CloudTrail to send events there.

Let’s create an EventBridge rule. This rule will match specific CloudTrail events. We’ll filter for RunInstances events, meaning every time a new EC2 instance is launched.

First, create an SNS topic to send notifications to. This will be the target for our EventBridge rule.

aws sns create-topic --name ec2-instance-launch-notifications

Note the ARN of the SNS topic. It will look something like arn:aws:sns:us-east-1:123456789012:ec2-instance-launch-notifications.

Now, create the EventBridge rule. We’ll use a sample event pattern that matches CloudTrail’s RunInstances event.

aws events put-rule \
    --name "EC2InstanceLaunchMonitor" \
    --event-bus-name "default" \
    --event-pattern '{"source": ["aws.ec2"], "detail-type": ["AWS API Call via CloudTrail"], "detail": {"eventSource": ["ec2.amazonaws.com"], "eventName": ["RunInstances"]}}' \
    --state "ENABLED"

This event-pattern is key.

• "source": ["aws.ec2"]: Filters events originating from the EC2 service.
• "detail-type": ["AWS API Call via CloudTrail"]: Specifies that these are CloudTrail API calls.
• "detail": {"eventSource": ["ec2.amazonaws.com"], "eventName": ["RunInstances"]}: Narrows it down to the RunInstances API call within EC2.

Next, we need to add a target to this rule, pointing to our SNS topic.

aws events put-targets \
    --rule "EC2InstanceLaunchMonitor" \
    --event-bus-name "default" \
    --targets "Id"="1","Arn"="arn:aws:sns:us-east-1:123456789012:ec2-instance-launch-notifications" # Replace ARN with your SNS topic ARN

Finally, you need to allow EventBridge to publish to your SNS topic. You do this by adding a permission to the SNS topic policy.

aws sns add-permission \
    --topic-arn "arn:aws:sns:us-east-1:123456789012:ec2-instance-launch-notifications" \ # Replace ARN
    --aws-account-id "123456789012" \ # Replace with your AWS Account ID
    --label "EventBridgeInvoke" \
    --action-name "sns:Publish"

Now, if you launch an EC2 instance in your account, you’ll receive a notification on the SNS topic. You can then subscribe an email address, a Lambda function, or an SQS queue to this SNS topic to take further action.

The real power here is the event-pattern. You can craft incredibly specific rules to catch anything from unauthorized IAM role assumptions to changes in critical security groups. The detail object within the CloudTrail event is a JSON document containing all the information about the API call, including user, parameters, and response. You can inspect these events in CloudTrail logs to build your patterns. For instance, to monitor changes to Lambda function configurations, your pattern might look like:

{
  "source": ["aws.lambda"],
  "detail-type": ["AWS API Call via CloudTrail"],
  "detail": {
    "eventSource": ["lambda.amazonaws.com"],
    "eventName": ["UpdateFunctionConfiguration", "CreateFunction", "DeleteFunction"]
  }
}

The most surprising thing about this integration is how granular you can get with filtering. It’s not just about "something happened," but "this specific thing happened, by this user, with these parameters." You can filter on specific values within the API call parameters. For example, to only trigger on RunInstances calls that request a specific instance type like t2.micro:

{
  "source": ["aws.ec2"],
  "detail-type": ["AWS API Call via CloudTrail"],
  "detail": {
    "eventSource": ["ec2.amazonaws.com"],
    "eventName": ["RunInstances"],
    "requestParameters": {
      "instancesSet": {
        "items": [
          {
            "instanceType": ["t2.micro"]
          }
        ]
      }
    }
  }
}

This allows for highly targeted alerting and automation, reducing noise and focusing on what truly matters for your security and compliance posture.

Once you’ve mastered routing basic API calls, the next logical step is to explore how to transform these events before they reach their targets using EventBridge Pipes or Lambda.