CloudTrail

AWS CloudTrail records the API activity in an AWS account: who called what, when, from where, with which parameters, and what the service returned. It is an audit record rather than a monitoring signal — it tells you what was asked of AWS, not how the resulting system behaved.

CloudTrail is enabled by default and every account has access to event history without configuring anything.

What a CloudTrail event contains

Each record carries the metadata around one API call:

the identity of the caller — IAM user or role, an AWS service acting on your behalf, or the root user;
the timestamp;
the source IP address;
the request parameters and the response elements;
an invokedBy field when an AWS service made the call on your behalf, which is how you tell an operator’s action from a service’s follow-on calls.

A single CreateStack call in CloudFormation legitimately produces a burst of further EC2, RDS and EBS events. That is expected, not evidence of anything.

Three places the data lives

Event history is the free, always-on view: the past 90 days of management events in a Region, viewable, searchable and downloadable from the console or via LookupEvents. It has real limits. It holds management events only — no data events, no Insights events, no network activity events. It is single-account, single-Region, and you can filter on one attribute plus a time range, nothing more. Treat it as the tool for a quick “who deleted that”, never as the compliance record.

Trails deliver events to an S3 bucket you own, for as long as you want to keep them, and optionally on to CloudWatch Logs and EventBridge. A trail can be single-Region or multi-Region; every trail created in the console is multi-Region, which is the right default because it captures activity in Regions nobody is supposed to be using. An organization trail, created from the management or delegated administrator account, covers every account in the organization automatically and cannot be modified or deleted by member accounts.

CloudTrail Lake event data stores hold events in a queryable store you address with SQL, rather than as files in S3. Lake can hold CloudTrail events, Insights events, AWS Config configuration items, Audit Manager evidence, and — through channels — activity events from outside AWS entirely. It also provides dashboards: managed ones covering common questions, custom ones you build from your own queries, and a Highlights dashboard that surfaces anomalies such as unusual cross-account access. Event data stores and the queries against them are charged; the pricing option chosen at creation sets both the ingestion cost and the retention.

Event types

Management events are control-plane operations: CreateBucket, RunInstances, CreateUser, AttachRolePolicy, PutBucketPolicy. These are logged by default, and one copy of management events delivered to S3 by a trail is free.

Data events are data-plane operations on the contents of resources: S3 GetObject, PutObject and DeleteObject, Lambda Invoke, DynamoDB GetItem and PutItem. They are disabled by default because the volume is enormous — a busy S3 bucket generates orders of magnitude more data events than the account generates management events. Enable them selectively with advanced event selectors, filtering on fields such as eventName, so that you log the operations you actually need to audit and not the rest.

Network activity events record VPC endpoint activity. On a trail they are filtered with advanced event selectors on eventName, errorCode, vpcEndpointId and userIdentity.arn; on an event data store, on the first three of those.

Insights events are generated by CloudTrail itself when the rate of management API calls, or the rate of errors on them, departs from the baseline it has learned. They are off by default and charged separately. After first enabling Insights, allow up to 36 hours on a trail (or up to 7 days on an event data store) before events begin to appear.

Timing

CloudTrail publishes log files multiple times an hour, roughly every 5 minutes, and typically delivers logs within an average of about 5 minutes of the API call — though this is explicitly not guaranteed. Design alerting around that: CloudTrail supports near-real-time detection, not real-time prevention. If a control must block an action rather than report it, it belongs in an IAM policy, a service control policy or a resource policy, not in a CloudTrail alarm.

If a trail is misconfigured — an unreachable S3 bucket, say — CloudTrail retries delivery for 30 days, and those attempts are still charged. Delete a broken trail rather than leaving it failing.

Making the trail defensible

Use a multi-Region trail, or an organization trail across the estate. Activity in an unused Region is exactly what you want to catch.
Enable log file integrity validation. CloudTrail writes hash-chained digest files so you can prove logs have not been altered since delivery. Without it, “the logs show nothing” is not an argument you can make.
Encrypt with a KMS key. Trail log files and digest files, and Lake event data stores, can use a customer managed key. Note that once an event data store is associated with a KMS key, the key cannot be changed or removed.
Restrict and monitor access to the log destination. The S3 bucket holding the trail is a target: lock it down with a bucket policy and IAM, consider MFA delete, and keep it in a separate account from the workloads it audits.
Send to CloudWatch Logs and set metric filters and alarms on the events that matter — root account usage, IAM policy changes, security group changes, trail configuration changes.
Route through EventBridge for automated response rather than human notification.
Set retention deliberately, with S3 lifecycle rules on trail data, and keep it long enough to satisfy whatever obligation you are under.
Monitor that logging is still on. A trail someone disabled is silent in exactly the same way as an account where nothing happened. AWS Config rules and Security Hub controls both check for this.

Analysing the data

CloudWatch Logs for near-real-time filtering and alarms.
CloudTrail Lake for SQL over events, with dashboards, and the option to federate an event data store into the AWS Glue Data Catalog so Athena can query it too.
Athena directly over trail files in S3.
Security Hub and Amazon Detective for security findings and investigation.