AWS CloudTrail
CloudTrail records every AWS API call in your account: who made it (user, role, or service), what action, what parameters, what AWS returned, and the source IP and user agent. It is the foundation of audit, compliance, and security investigation on AWS.
A free 90-day Event History is on by default in every account; beyond that you create trails that deliver the full record to S3 (and optionally CloudWatch Logs) for as long as you want. Most organizations keep a multi-account trail running for years.
Event Types
Management events are control-plane calls (RunInstances, AttachRolePolicy) recorded by default. Data events are data-plane operations (S3 GetObject, Lambda invocations), not recorded by default because the volume is large — you opt in per resource. Insights events are detected anomalies in API rates or error patterns (paid opt-in).
The distinction drives cost: management events are essentially free, while data events at scale can cost real money. Turn data events on only where you need them.
Event History vs Trails
Event History is a free 90-day view of management events in every account, fine for casual investigation. Trails ship events to S3 for long-term retention and can cover all Regions and every account in an Organization.
A typical production setup runs one multi-Region, organization-wide management-events trail shipping to an S3 bucket in a separate security account, plus narrower trails for data events on critical buckets or functions. CloudTrail Lake keeps events up to ten years with SQL query access.
Working with the Data
Once events land in S3 or CloudWatch Logs, Athena queries years of history with SQL, EventBridge rules fire automation on specific calls (alert when CloudTrail is disabled, when a security group opens to 0.0.0.0/0, when the root user logs in), and Security Hub and GuardDuty consume the events directly.
CloudTrail — the audit record of API calls — who did what, when, from where.
CloudWatch — metrics, logs, and alarms for health and performance — not an API audit log.
AWS Config — what resources looked like before and after a change, evaluated against rules.
- Turning on S3 or Lambda data events account-wide instead of only on resources that need them, running up a large bill.
- Leaving log-file integrity validation off, so an attacker who reaches the trail bucket can alter history undetected.
- Keeping the trail bucket in the same account with broad write access instead of a locked-down separate security account.
- Not alerting on tampering — a
StopLoggingorDeleteTrailevent should page someone immediately. - Expecting CloudTrail to capture application-internal events — it records AWS API calls only.
- Relying on the 90-day Event History for long-term compliance instead of a durable trail or CloudTrail Lake.
- Run one organization-wide, multi-Region management-events trail to a dedicated security-account bucket.
- Turn on log-file integrity validation.
- Send a copy to CloudWatch Logs for real-time metric-filter alerting.
- Enable data events only on the specific sensitive buckets or critical functions that need them.
- Alert on StopLogging and DeleteTrail events immediately.
- Use CloudTrail Lake for regulated workloads needing long retention with SQL.
Knowledge Check
Which CloudTrail event type is recorded by default and is essentially free?
- Management events — control-plane API calls
- Data events — S3 object and Lambda invocation activity
- Insights events — anomaly detection
- All event types are recorded by default
Why are CloudTrail data events not enabled by default?
- Their volume is large, so AWS makes you opt in per resource to control cost
- They contain no information useful for security investigations or compliance audits
- They are only available when you query CloudTrail Lake
- They require an Enterprise Support subscription
What is the recommended production CloudTrail architecture?
- An org-wide, multi-Region management-events trail shipping to a separate security account's bucket
- A separate single-Region trail in each workload account, with logs kept locally and no central bucket
- Only the free 90-day Event History console view, with no trail at all
- Data events on every resource, with management events turned off
Why enable log-file integrity validation on a trail?
- So tampering with the trail's history can be detected if someone reaches the bucket
- To reduce S3 storage cost by compressing the delivered log files automatically in place
- To enable S3 and Lambda data events automatically
- To extend the console Event History beyond 90 days
You got correct