CloudTrail Trails and Event History

AWS CloudTrail is a service that records every API call made in your AWS account — whether from the console, CLI, SDK, or another AWS service. Each record is called a CloudTrail event and contains the API action, the requester's identity, the source IP, the request parameters, and the response. CloudTrail is the foundation of AWS security auditing, compliance, and operational investigation. For the SAA-C03 exam, it is the answer whenever a question asks 'who made this change?'

By default, every AWS account has access to CloudTrail Event History — a 90-day rolling record of management events viewable in the console or queryable via the CLI. You can filter by resource name, resource type, event name, or username. Event History is free, requires no configuration, and is available immediately. It is the quickest way to investigate recent changes, but for longer retention or more powerful queries you must create a Trail.

A Trail is a CloudTrail configuration that delivers events continuously to an S3 bucket (and optionally to CloudWatch Logs). You pay for S3 storage and data transfer. A Trail can be scoped to a single Region or configured as a multi-region trail that captures events from every current and future Region in your account. For the SAA-C03 exam, always recommend a multi-region trail — single-region trails miss activity in other Regions and are considered a security gap.

CloudTrail records two categories of events: Management events (also called control-plane events) record operations on resources — creating an EC2 instance, modifying a security group, attaching an IAM policy. These are enabled by default in every trail at no extra per-event charge. Data events record object-level operations — S3 GetObject, PutObject, DeleteObject, or Lambda Invoke. Data events can be very high volume and incur additional charges, so they must be explicitly enabled per resource or resource type.

Delivering CloudTrail events to CloudWatch Logs enables real-time alerting on API activity. You can create metric filters on the CloudTrail log group to count specific events — for example, count DeleteBucket or CreateUser calls — and then set CloudWatch alarms to alert your security team within minutes of a suspicious action. This is a core pattern in the CIS AWS Foundations Benchmark, which the SAA-C03 exam frequently references.

Some AWS services — notably IAM, STS, Route 53, and CloudFront — are global and log their API calls as global service events. These events are always recorded in the us-east-1 Region regardless of where the operation was initiated. When creating a trail, enable --include-global-service-events so IAM user creation, policy changes, and STS role assumptions are captured. If you have multiple Region-specific trails, enable global service events in only one to avoid duplicate log records.

CloudTrail requires a specific S3 bucket policy that grants the CloudTrail service principal (cloudtrail.amazonaws.com) permission to call GetBucketAcl and PutObject on the bucket. AWS enforces that the bucket is not publicly accessible and that Object Ownership is set to Bucket Owner Enforced. Never store CloudTrail logs in the same bucket your application uses — this creates a circular dependency where access to audit logs is disrupted if the application bucket is locked down.

In an AWS Organisation, you can create an organisation trail from the management account that automatically applies to all member accounts — current and future. Member accounts cannot modify or delete the organisation trail, ensuring audit coverage cannot be evaded. Organisation trails deliver logs to a centralised S3 bucket with per-account prefixes, enabling a security team to query all accounts' audit logs in one place using Athena or a SIEM tool.

CloudTrail logs delivered to S3 are in JSON format. You can use the Amazon Athena integration in the CloudTrail console to create a Glue table automatically partitioned by account, Region, and date. This lets you query months of API history using standard SQL without loading data into a database. Partition by date in your queries (WHERE year='2024' AND month='01') to avoid full-table scans and control Athena costs.

There are two ways to search CloudTrail records: Event History in the console (last 90 days, management events only, limited filters) and Trail logs in S3/Athena (unlimited retention, data events too, full SQL power). For exam scenarios: if the question asks to investigate an event older than 90 days, or to query data-plane events (S3 GetObject, Lambda Invoke), always recommend querying Trail logs via Athena. If the question asks for the simplest approach to investigate a recent management event, Event History is sufficient.

Memorise these for the SAA-C03 exam: CloudTrail is not real-time — it can take up to 15 minutes to deliver events to S3 (use CloudWatch Logs for near-real-time alerting). Event History is 90 days for management events only. Data events must be explicitly enabled and cost extra. Log file validation uses SHA-256 hashes to detect tampering. Global service events (IAM, STS, Route 53) only appear in us-east-1. Organisation trails cannot be disabled by member accounts.

Test your understanding of AWS Solutions Architect (SAA-C03) concepts from this lesson.

In this lesson you learned: Event History gives free 90-day management event access, Trails provide continuous delivery to S3 with configurable retention and optional data events, and organisation trails apply to all member accounts and cannot be disabled by them. Next up we explore CloudTrail Insights and log file integrity verification.