CloudTrail Logs

What are CloudTrail logs?

CloudTrail records nearly every API call in an AWS account — console clicks, CLI commands, SDK calls, service-to-service actions — as structured events: identity, source IP, timestamp, request parameters, response. It answers the question that defines incident response: who did what, when? Without it, “how did this security group open to the world?” has no answer; with it, the answer takes one query.

Configuration that separates real coverage from a checkbox

The 90-day default event history is a demo, not an audit trail. Production posture: an organization trail covering all accounts, delivered to a dedicated, locked-down S3 bucket in a separate log-archive account (the Control Tower pattern), with log file validation enabled so tampering is detectable. Data events (S3 object reads, Lambda invokes) are the fine-grained tier — off by default, potentially voluminous and billable, and precisely what you’ll wish you had when investigating data exfiltration; enable selectively on sensitive buckets. Management events alone won’t tell you which objects an attacker read.

From logs to detection

Storage without queries is theater. Athena over the CloudTrail bucket answers ad-hoc forensics; EventBridge rules on high-risk events (DeleteTrail, StopLogging, root login, IAM policy changes) turn the trail into an alarm system; GuardDuty consumes it continuously for anomaly detection. The meta-alert every account needs: alert on CloudTrail being disabled — attackers reliably try to turn off the cameras first.

What people get wrong

• Same-account log storage — an attacker with account admin deletes the evidence; archive cross-account.
• Ignoring event latency: delivery lags ~5–15 minutes; CloudTrail is forensics and detection, not a synchronous control.
• Never testing queries — the first Athena query written during an incident wastes the hour you least have.

Primary source: AWS CloudTrail documentation