CloudTrail

AWS CloudTrail records API calls made in your AWS account: every action taken through the console, CLI, SDK, or by AWS services. Each event includes who made the call, what action they performed, which resources were affected, when it happened, and from what IP address.

Event Types

• Management events: control plane operations (CreateBucket, RunInstances, PutBucketPolicy). Logged by default in event history (90 days free).
• Data events: data plane operations (GetObject, PutObject, Invoke). Must be explicitly enabled on a trail. Higher volume and cost.
• Insights events: CloudTrail detects unusual API activity patterns automatically

Security Use Cases

• Incident investigation: who deleted that resource?
• Compliance auditing: prove who accessed what
• Real-time alerting via CloudWatch or EventBridge
• Integration with Athena for SQL queries over historical logs

How It Goes Wrong in Practice

CloudTrail is the first thing competent attackers look at and the first thing they try to break. Disabling or degrading the victim's logging is a standard defense-evasion step: an intruder with sufficient permissions calls StopLogging on the trail, deletes the trail entirely, or edits its event selectors so their subsequent activity is never recorded, then proceeds to the actual objective knowing the investigation will start half-blind. The defensive counterweights are all configuration decisions made before the incident. A multi-region trail, ideally an organization trail, means an attacker operating from an unused region is still recorded; the CIS AWS Foundations Benchmark requires exactly this, a multi-region trail capturing read and write management events. Log file validation adds digest files that make after-the-fact tampering with delivered logs detectable, another explicit CIS requirement. Delivering logs to an S3 bucket in a separate log-archive account keeps a compromised workload admin from deleting history. And alarming on CloudTrail configuration changes turns the attacker's very first move into your first alert. The quieter failure mode is scoping: teams enable management events and stop there, then discover mid-investigation that they can prove a role listed a bucket but not which objects it downloaded, because S3 data events were never enabled on the trail. Decide which data planes matter (S3 buckets holding sensitive data, critical Lambda functions) and pay for those data events deliberately, before you need them.

Practical Check: Status and Tamper Hunting

First, confirm the trail is alive and delivering:

aws cloudtrail get-trail-status --name my-org-trail

Look for IsLogging true, a recent LatestDeliveryTime, and an empty LatestDeliveryError; a delivery error usually means a broken bucket policy or KMS key and represents silent history loss. Then hunt for tampering in the event history:

aws cloudtrail lookup-events --lookup-attributes AttributeKey=EventName,AttributeValue=StopLogging

Repeat the lookup for DeleteTrail and UpdateTrail. The supported lookup attribute keys also include Username, EventSource, ResourceName, and AccessKeyId, which makes the same command family the fastest triage tool when investigating a specific identity or leaked key.

Frequently Asked Questions

Is CloudTrail enabled by default?
Event history is: you get 90 days of management events per region without configuring anything. But event history is not a durable audit trail. For retention beyond 90 days, multi-region coverage in one place, data events, log file validation, and Athena queries, you need an actual trail delivering to S3.

What is the difference between management and data events in cost terms?
Management events on a trail cover control-plane calls and are the baseline every account should have. Data events (object-level S3 access, Lambda invocations) are far higher volume, are off by default, and are billed per event recorded, so they are enabled selectively per resource. The mistake is treating that as a reason to skip them everywhere; for buckets holding sensitive data, object-level logging is often the only way to answer "what exactly was taken".

Can an attacker erase what CloudTrail already recorded?
Events already delivered to S3 can be deleted only by someone with delete access to that bucket, which is why logs belong in a separate, tightly controlled account. Log file validation makes deletions and modifications of delivered files detectable through digest verification. Event history within its 90-day window cannot be edited by API callers, making it a useful cross-check if trail files were tampered with.

How do I get alerted on suspicious API activity?
Route CloudTrail into CloudWatch Logs and build metric filters and alarms for the patterns you care about (root usage, IAM changes, CloudTrail changes), or match events in EventBridge for real-time response automation. CloudTrail Insights adds ML-based detection of unusual API call volumes on top.