CloudTrail, end to end
Lesson 1 of 4 in The Logging Architecture.
CloudTrail records three different classes of thing, charged three different ways, and defaulted three different ways. Confusing them costs marks on every form of this exam.
Management events are the control plane: CreateBucket, AssumeRole, AuthorizeSecurityGroupIngress, PutKeyPolicy — operations performed on resources. They are recorded whether or not you ever create a trail: every account has 90 days of Event history in the console at no charge. A trail’s first copy of management events carries no CloudTrail charge either, which is why one organization trail is almost always the right answer, and a second trail duplicating the same events is almost always the distractor that costs money for nothing.
Data events are the data plane: GetObject, PutObject, Invoke, DynamoDB item operations — things done inside a resource. They are off by default on every trail, they are charged per event, and at scale they dominate a logging bill. Two consequences the exam leans on hard. “We cannot tell who downloaded that object” means data events were never enabled, and the 90-day Event history will not rescue you because it never held them. And GuardDuty S3 Protection reading S3 data events from its own stream is not evidence that you have them.
Insights events are CloudTrail’s own anomaly detection over your API usage: a learned baseline of call volume and error rates, and an event when activity deviates. Enabled per trail, charged separately, and useful precisely where threat intelligence has nothing to say — a burst of DeleteBucket, an AccessDenied wave that signals enumeration.
| Event class | Records | Default | Cost model | The exam tell |
|---|---|---|---|---|
Management | control-plane API calls — operations on resources | on; 90 days in Event history with no trail at all | first trail copy free; additional copies charged | “who changed the configuration” / “who assumed the role” |
Data | data-plane operations — S3 object access, Lambda invocations, DynamoDB items | off — on every trail, always | charged per event delivered; use selectors to scope | “which object was read” / “who downloaded the file” |
Insights | anomalies in your own call rate and error rate, against a learned baseline | off, per trail | charged per analysed event | “unusual volume of API activity” with no threat-intelligence match |
Proving the record is intact is a separate feature, and auditors ask for it by name. Log file integrity validation hashes every delivered log file with SHA-256 and, every hour, writes a signed digest file listing that hour’s files and their hashes. Each digest also carries the signature of the previous one, so the digests form a chain and removing one is visible rather than quiet. Digests are written to a separate prefix in the same bucket, which is deliberate: you can apply tighter permissions to the digests than to the logs. aws cloudtrail validate-logs does the verification.
Be precise about what that buys you. Validation detects tampering after the fact. It does not prevent it — preventing deletion is S3 Object Lock, versioning, MFA delete, and a bucket policy that denies s3:DeleteObject to everyone. An exam option offering validation as the answer to “make the logs undeletable” is answering a different question.
Nothing is arriving in the bucket at all
Work the chain in order. Is the trail logging? It can be stopped without being deleted. Does the bucket policy admit CloudTrail? It needs s3:GetBucketAcl on the bucket and s3:PutObject on the expected prefixes for cloudtrail.amazonaws.com, and an organization trail’s prefix includes the organization id. Does the KMS key policy allow the CloudTrail service principal to generate a data key? If not, delivery fails silently from the reader’s point of view. Is the bucket in a Region the trail can write to, and does it still exist? Deleting or renaming a destination bucket breaks delivery with no change to the trail.
The trail is delivering but data events are missing
They were never enabled. Data events are off on every trail by default, and advanced event selectors scope them narrowly — by resource ARN, by prefix, by read-only or write-only. A selector that covers arn:aws:s3:::reports/* records nothing about arn:aws:s3:::finance/*. Note too that enabling them now does not create history: the 90-day Event history never contained data events either.
Analysts can list the objects but cannot read them
Classic SSE-KMS split. Reading an encrypted object needs s3:GetObject and kms:Decrypt on the key, and the key policy is the authority on the second one — an IAM policy alone cannot grant access to a KMS key whose policy does not allow the account. The error surfaces as an S3 AccessDenied, which sends people to the bucket policy for an hour.
A member account’s own trail covers less than the organization trail
Expected, and worth recognising in exam wording. Member accounts can create their own trails for their own operational use, but those trails are configured locally and can be stopped locally. The organization trail is the one that cannot be tampered with from inside a member account — which is exactly why central audit logging is an organization trail plus a bucket in a different account, not a convention everyone agrees to follow.
Key terms: Management event (control plane), Data event (data plane), CloudTrail Insights event, Organization trail, AWS CloudTrail Lake, Log file integrity validation
Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.