Skip to main content
Welcome. This lesson explains AWS CloudTrail—AWS’s account-level API audit logger—and how to use it for security monitoring, incident investigation, and compliance. At a high level, CloudTrail records AWS API calls and related events: who called the API, what API was called, when it occurred, and where the request originated. Note that CloudTrail captures API-level activity only; it does not record operating system actions or native database client connections unless those logs are forwarded into AWS logging services.
CloudTrail captures API-level activity (management and data plane events). It does not capture OS-level logs or native database client connections unless those actions go through AWS APIs or you forward those logs to CloudWatch Logs or another logging pipeline.
A presentation slide titled "What CloudTrail Actually Logs" with four colored info cards listing WHO made the call, WHAT action was performed, WHEN it occurred, and WHERE it came from. Each card briefly explains details like IAM identity, API actions (e.g., CreateBucket), timestamps, and source IP/user agent.

​
What CloudTrail provides

CloudTrail records a standardized set of metadata for each API event. Use the table below to quickly see the core fields investigators rely on:

​
Management events vs Data events

CloudTrail distinguishes control-plane (management) events from data-plane events. Understanding this difference helps you configure trails and control costs. Note: native database connections (for example, direct MySQL client connections to RDS) do not go through AWS APIs and therefore are not recorded in CloudTrail unless you forward database logs into CloudWatch Logs or another logging pipeline.
A presentation slide titled "Management Events vs Data Events" showing a side-by-side comparison of characteristics and examples for each. The left column lists management events (control plane actions, logged by default, low volume, no extra cost — e.g., EC2 start/stop, IAM changes, S3 bucket actions) and the right column lists data events (data plane actions, must be enabled, additional cost, high volume — e.g., S3 object access, Lambda invokes, DynamoDB reads/writes).

​
Trails and delivery

A CloudTrail “trail” defines how events are delivered and where they are stored for analysis.
  • Trail types:
    • Single-Region trail: records events in one region.
    • Multi-Region trail: records events across all regions (recommended where full visibility is required).
    • Organization trail: centralizes logs for every account in an AWS Organization into a single S3 bucket (typical for centralized logging or security accounts).
  • Trails deliver events to:
    • An S3 bucket (for long-term storage and audit/archive workflows).
    • Optionally to CloudWatch Logs (near real-time analysis).
    • Optionally to EventBridge (for routing to other services).
CloudTrail also exposes an Event history view in the console for recent management events (short-term retention, typically around 90 days) even if you don’t create a trail. For durable, centralized retention and processing, create a trail that delivers events to S3 (and optionally CloudWatch Logs).
A presentation slide titled "CloudTrail Trail Configuration" showing three numbered panels: Single-Region Trail, Multi-Region Trail, and Organization Trail with brief bullets about logging scope and visibility. The slide has a clean white layout and a © Copyright KodeKloud mark.

​
Log validation and integrity

Preserving the integrity of audit logs is crucial for investigations and compliance.
  • Log file integrity validation: CloudTrail can compute SHA-256 hashes of delivered log files and periodically generate digest files.
  • Digest files (hourly) allow you to verify that S3 objects haven’t been altered since delivery. Store digests in a separate location or account for stronger protection.
  • Use digests and signatures as part of a repeatable verification workflow during audits or forensic investigation.
An infographic titled "Log File Validation and Integrity" that illustrates CloudTrail's log validation process. It shows four colored circular steps explaining SHA-256 hash creation, hourly digest files, delivery to a separate S3 location, and digital signatures to ensure log integrity.

​
Integration with CloudWatch Logs and EventBridge

For near real-time detection and automated response, forward CloudTrail events to CloudWatch Logs and EventBridge.
  • Configure a trail to deliver events to a CloudWatch Logs log group.
  • Use CloudWatch Logs metric filters (pattern matching) to create metrics from event patterns.
  • Attach CloudWatch Alarms to metrics to trigger SNS notifications, Lambda functions, or other responders.
  • Use EventBridge rules to route specific CloudTrail events to workflows, step functions, or third-party systems for incident response.
Workflow example:
  1. Trail delivers events → CloudWatch Logs.
  2. Metric filters detect suspicious patterns → CloudWatch Metric.
  3. Alarm triggers → SNS / Lambda to notify or remediate.
  4. EventBridge rules route events to other services for enrichment or automation.
Slide titled "Integration With CloudWatch Logs" showing four labeled boxes — CloudTrail Events, CloudWatch Logs Stream, Metric Filters, and CloudWatch Alarms — with brief descriptions of each step (API capture, real-time delivery, pattern matching, and automated alerting).

​
Common security monitoring patterns

Use CloudTrail to detect and alert on high-risk or suspicious activity. Examples include:
  • Root account usage (ConsoleLogin events tied to the root principal).
  • Console login without MFA (ConsoleLogin events where MFA was not used).
  • IAM policy, role, and key changes (CreatePolicy, PutRolePolicy, CreateAccessKey).
  • Security group or NACL changes that widen ingress (AuthorizeSecurityGroupIngress, UpdateNetworkAclEntry).
  • S3 bucket policy or ACL changes that expose data (PutBucketPolicy, PutBucketAcl, PutPublicAccessBlock).
  • CloudTrail configuration changes (DeleteTrail, StopLogging).
  • Repeated failed authorization attempts (AccessDenied patterns, failed AssumeRole attempts).
Slide titled "Common Security Monitoring Patterns" showing eight numbered alerts. Items include root account usage detection, console login without MFA, IAM policy changes, security group and network ACL modifications, S3 bucket policy changes, CloudTrail configuration changes, and failed API authorization attempts.

​
Global services and us-east-1 behavior

Some AWS services are global (for example, IAM, STS, AWS Organizations, Route 53, CloudFront). API activity for many global services is typically recorded in the us-east-1 region.
  • When using a multi-Region trail, there is an explicit option to “Include global services” to capture these global service events in the trail.
  • If you enable global service event capture on more than one trail, you will receive duplicate entries for those events.
Exam/troubleshooting trap: enabling a multi-Region trail does not automatically include global service events. You must enable the “Include global services” option on the trail you intend to use, and avoid enabling it on multiple trails to prevent duplicate logs and extra costs.
Slide titled "Global Service Events and Edge Locations" listing global AWS services (IAM, STS, CloudFront, Route 53, AWS Organizations). A configuration note advises enabling "Include global services" to capture these events and recommends enabling it on only one trail to avoid duplicate logs and extra storage costs.

​
Exam-style scenarios and practical examples

When performing audits or troubleshooting, search CloudTrail for these patterns:
  • Unauthorized EC2 termination: filter for TerminateInstances with the instance ID and inspect the userIdentity field.
  • Real-time root account usage detection: search for ConsoleLogin events where userIdentity.type is Root.
  • Security group changes opening 0.0.0.0/0: search AuthorizeSecurityGroupIngress events with CIDR 0.0.0.0/0.
  • S3 public access changes: monitor PutBucketPolicy, PutBucketAcl, or PutPublicAccessBlock.
  • Cross-account role assumption: detect AssumeRole and verify the principal that performed the assume.
CloudTrail is the authoritative API-level record for these activities and is central to post-incident analysis.
A presentation slide titled "Common Exam Scenarios and Patterns" featuring a semicircular, multi‑colored infographic that highlights security scenarios like Root Account Usage, Security Group Changes, S3 Public Access Changes, Cross‑Account Access, and Unauthorized EC2 Termination. Each colored segment includes an icon and brief notes on what to monitor or filter (e.g., AuthorizeSecurityGroupIngress, PutBucketPolicy, AssumedRole).

​
CloudTrail Insights (anomaly detection)

CloudTrail Insights is an optional feature that analyzes normal API activity patterns and flags unusual behavior (for example, a sudden spike in CreateBucket events). Insights generates Insight events you can route to CloudWatch or EventBridge for alerting and automation.
  • Useful for detecting behavior that static rules might miss (spikes, sudden drops, or anomalous API usage).
  • Insights is feature-billed—evaluate cost vs. visibility benefits.
A presentation slide titled "CloudTrail Insights – Anomaly Detection" that explains CloudTrail Insights is an optional paid feature using machine learning to detect unusual API activity. Below a heading, a timeline with three colored pin icons illustrates: learning normal patterns, monitoring for deviations, and generating insight events for anomalies.

​
Costs and cost-management guidance

CloudTrail pricing and features can change; always consult the AWS pricing page. Key considerations:
  • Enabling trails is inexpensive, but enabling data events (S3 object-level, Lambda invokes, DynamoDB operations) and Insights increases cost.
  • Broadly enabling data events can produce very high volumes and storage/processing charges.
  • Duplicate trails or enabling global events on multiple trails causes duplicate log delivery and higher costs.
Cost-optimization tips:
  • Use a single multi-Region trail where practical.
  • Enable data events only for specific resources you need to monitor.
  • Use S3 lifecycle policies to transition older logs to cheaper classes (e.g., Glacier) or use Intelligent-Tiering.
  • Monitor CloudTrail-related spend in AWS Cost Explorer and set budgets/alerts.

​
Security best practices for CloudTrail

  • Encrypt delivered logs with AWS KMS.
  • Restrict access to the S3 bucket that stores logs—consider a dedicated security/logging account to centralize and isolate logs.
  • Enable S3 bucket versioning and consider MFA Delete if stronger protection against deletion is required.
  • Harden KMS key policies and separate duties for key administration.
  • Enable integrity validation for critical compliance scenarios.
A presentation slide titled "CloudTrail – Security Best Practices." It lists four recommendations with icons: encrypt log files with KMS, enable S3 bucket versioning, restrict S3 bucket access, and use a separate security account.

​
Key takeaways

  • AWS CloudTrail is the primary source for auditing API activity; it logs who did what, when, and where.
  • Distinguish management (control plane) events from data (data plane) events—data events must be enabled and can be high-volume.
  • Use multi-Region and organization trails for broad coverage; explicitly enable global service capture if you need IAM/STS/CloudFront events.
  • Integrate CloudTrail with CloudWatch Logs and EventBridge for near real-time detection and automated responses.
  • Use log integrity validation, KMS encryption, restricted S3 access, and lifecycle policies to secure and manage logs.
  • Balance visibility and cost: enable only the data events and Insights needed for your security posture.
This material is essential for security, compliance, and many AWS certification exam objectives—review configuration options carefully and be aware of common traps and optimizations.

Watch Video