AWS CloudTrail & Amazon EventBridge Integration | Overview.

AWS CloudTrail & Amazon EventBridge Integration - Overview.

Scope:

• Intro,
• Key Integration Concepts,
• Core Requirements,
• Implementation Steps,
• CloudTrail Overview,
• EventBridge Overview,
• CloudTrail → EventBridge Flow,
• Architectures,

• Key Benefits,

• Common Use Cases,
• Best Practices,
• key-Takeaway,
• Links to official documentation.

Intro:

• Integrating Amazon EventBridge with AWS CloudTrail allows twtech to automate responses to nearly any API activity in its AWS account in real-time. 

Key Integration Concepts

• API Visibility: EventBridge can trigger actions based on both mutating API calls (e.g., StopInstances, CreateBucket) and non-mutating/read-only calls (e.g., ListBuckets, DescribeInstances).
• Management vs. Data Events: By default, management events (control plane operations) are the primary source. 
• To react to data events like S3 PutObject or Lambda Invoke, twtech must explicitly enable data event logging in its CloudTrail trail.
• Global Service Handling: Events for global services such as IAM, AWS STS, and CloudFront are typically only available in the US East (N. Virginia) region. 

Core Requirements

• t have at least one trail created and logging in the same region where you want to trigger EventBridge rules.
• Default Event Bus: AWS service events delivered via CloudTrail are always sent to twtech account's default event bus.
• Event Pattern Structure: Rules must use the detail-type of AWS API Call via CloudTrail.

# json

{
  "source": ["aws.ec2"],
  "detail-type": ["AWS API Call via CloudTrail"],
  "detail": {
    "eventSource": ["ec2.amazonaws.com"],
    "eventName": ["StopInstances"]
  }
}

Implementation Steps

1. Configure CloudTrail: Create a trail and ensure it is in the "Logging" state.
2. Create EventBridge Rule: Use the EventBridge Console to define a rule with an "Event Pattern" matching the specific AWS service and API call.
3. Define Target: Select a target for the event, such as an AWS Lambda function, SNS topic, or SQS queue.
4. Verify Permissions: twtech Ensures the EventBridge rule has resource-based permissions to invoke twtech chosen target.

 CloudTrail Overview

        Purpose: CloudTrail records all API calls made in twtech AWS account (management and data events).

        Event Types:

o   Management events (e.g., CreateUser, RunInstances).

o   Data events (e.g., GetObject on S3).

        Delivery:

o   Logs are delivered to S3 (for auditing/archival).

o   Events can also be pushed to EventBridge in real time.

 EventBridge Overview

•  Purpose: Serverless event bus for routing events between AWS services and SaaS apps.
•  Rules: twtech defines event patterns (JSON-based filtering) that match incoming events.
•  Targets: Events can trigger Lambda, SNS, SQS, Step Functions, Kinesis Streams, API destinations, etc.
•  Latency: Typically sub-second between CloudTrail and EventBridge.

 CloudTrail → EventBridge Flow

1.     API Call Happens

o   A user or AWS service makes an API call (via CLI, SDK, or Console).

2.     CloudTrail Captures Event

o   CloudTrail logs the request and response metadata.

o   Instead of waiting for batch delivery to S3, CloudTrail can publish matching events directly to EventBridge.

3.     EventBridge Receives CloudTrail Event

o   CloudTrail events arrive in JSON format on the EventBridge default event bus.

 Sample snippet:

{

  "version": "0",

  "id": "abcd-1234-vxxx-xxxxxx",

  "detail-type": " AWS API Call via CloudTrail",

  "source": "aws.ec2",

  "account": "accountID",

  "time": "2025-09-28T12:34:56Z",

  "region": "us-east-2",

  "detail": {

    "eventSource": "ec2.amazonaws.com",

    "eventName": "StartInstances",

    "userIdentity": { ... },

    "requestParameters": { ... }

  }

}

4.     EventBridge Rule Matches Pattern

o  Sample: Match EC2 instance starts:

{

  "source": ["aws.ec2"],

  "detail-type": ["AWS API Call via CloudTrail"],

  "detail": { "eventName": ["StartInstances"] }

}

5.     Targets Consume Event

•    Lambda → Run automation logic.
•    SNS → Notify via email/SMS.
•    SQS → Queue for later processing.
•    Step Functions → Start orchestrated workflows.

Architectures

 Key Benefits

• Near real-time auditing of API activity.
• Fine-grained filtering (only process what twtech needs).
• Serverless automation → Auto-remediation, security controls, operational workflows.
• Centralized event-driven architecture across AWS and SaaS.

 Common Use Cases

             Security

o   Detect PutBucketPolicy with public access → trigger Lambda to revert.

o   Monitor CreateUser → auto-enforce MFA.

       Operations

o   On StartInstances → tag with owner info.

o   On DeleteDBInstance → alert via SNS.

        Compliance

o   Auto-generate audit reports when sensitive API calls happen.

        Integration

o   Trigger external systems (e.g., ServiceNow, Jira) via API destinations.

 Best Practices

•  Use least privilege for EventBridge targets (e.g., Lambda execution role).
•  Apply filtering in EventBridge rules instead of dumping all events downstream.
•  If volume is high, use SQS or Kinesis as a buffer for reliability.
•  Enable multi-region trails to centralize governance.
•  Monitor CloudWatch metrics for EventBridge invocations & failures.

twtech-key-Takeaway:

• CloudTrail provides the raw event data (who did what, where, and when).
• EventBridge makes it actionable in near real time by routing it to workflows and automation.

Links to official documentation

https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-log-api-call.html

https://aws.amazon.com/blogs/compute/introducing-support-for-read-only-management-events-in-amazon-eventbridge/

https://docs.aws.amazon.com/awscloudtrail/latest/userguide/logging-data-events-with-cloudtrail.html

https://repost.aws/questions/QUSZ6lhfAkQXW3XQ2UR_WHpQ/event-bridge-not-triggering-for-cloudtrail

https://repost.aws/knowledge-center/automate-eventbridge-rule-cloudtrail-api