CloudTrail and Auditability

Event types and trails, centralizing and protecting logs, and reading a record as evidence

Management events: on by defaultdata events (S3, Lambda) are opt-in and billed
Event history: 90 days, no setupa trail is what gives durable retention
Centralize into a log archive accountordinary workload roles get no access
Who/what/when/where/as-whomall five answers live in one event record

1.CloudTrail Event Types and Trails

CloudTrail records every API call made in your account. Management events cover control-plane actions like creating a role or a subnet; data events cover high-volume resource-level actions like reading an S3 object. Event history keeps 90 days of management events automatically, no setup needed. A trail is what you create to keep events longer, choose which event types to log, and deliver them to an S3 bucket you control.

Key features

Management events (control-plane operations, e.g. CreateSubnet, AttachRolePolicy) are logged by default; data events (e.g. S3 GetObject, Lambda Invoke) are off by default and cost extra
Event history shows only the past 90 days of management events per Region, with no setup required — it exists even if you never create a trail
A trail delivers events to an S3 bucket you specify, optionally also to CloudWatch Logs and EventBridge, and is what gives you retention past 90 days
A multi-Region trail (the console default) captures every enabled Region plus global-service events (IAM, STS); a single-Region trail (CLI-only) covers one Region
Read events (Describe*, Get*) and write events (Put*, Delete*, Create*) can be logged separately or together — a trail's event selector controls which
CloudTrail Lake stores events in a queryable event data store with configurable retention (up to ~7 years), separate from the S3-bucket trail model

Event history vs a trail

Event history

On by default, no setup
Management events only, 90 days per Region
Viewed in the console or via lookup-events

Trail

You create it and choose an S3 bucket
Any event type, retained as long as you keep the logs
Can also stream to CloudWatch Logs / EventBridge

Signature

Management events (default) vs data events (opt-in, billed) · Event history (90 days) vs trail (durable)

Management events (control plane) are logged by default; data events (S3 object-level, Lambda Invoke) are off by default and billed extra. Event history is a free 90-day management-events view with no setup. A trail is what you create for durable retention, data-event coverage, and delivery to S3/CloudWatch Logs/EventBridge.

2.Centralizing and Protecting Audit Logs

Audit logs prove what happened, including during an incident where the attacker has some level of access. If a compromised workload role can edit or delete the very logs meant to catch it, the logs prove nothing. The fix is two-fold: send every account's logs to one dedicated logging account nobody develops in, and lock the destination S3 bucket down so ordinary workload roles cannot touch it, only trusted administrators can.

Key features

An AWS Organizations trail (an organization trail) automatically logs every member account's events into one S3 bucket owned by the management or a delegated administrator account
Best practice: a dedicated log archive account, separate from every workload account, holding the trail's destination S3 bucket
Least-privilege bucket policy: only the CloudTrail service and a small set of trusted administrators can read or write the bucket — ordinary workload IAM roles get no access to it at all
Log file integrity validation (SHA-256 hashing + RSA digital signing of hourly digest files) lets you cryptographically prove a delivered log file was not modified or deleted after the fact
S3 MFA Delete on the log bucket requires a hardware/virtual MFA device to change bucket versioning or permanently delete an object version — a stolen IAM password alone cannot erase logs
The AWSCloudTrail_FullAccess policy can disable or reconfigure trails entirely — AWS's own guidance is to limit it to as few administrators as possible

Workload account vs dedicated log archive account

Logs stay in the workload account

Same IAM roles that run the workload can reach the log bucket
A compromised or over-permissioned role can edit or delete evidence
No structural separation between "doing the thing" and "recording the thing"

Centralized log archive account

Organization trail ships every account's events to one bucket
Bucket policy grants access to CloudTrail and a few trusted admins only
A compromised workload role has no path to the audit record at all

Signature

Organization trail → dedicated log archive account → least-privilege bucket policy + log file integrity validation

A compromised workload role should never be able to reach the bucket holding the evidence of the compromise. Centralize logs into a dedicated log archive account (an organization trail does this automatically), lock the bucket to CloudTrail plus a few trusted admins, and enable log file integrity validation so tampering is provable, not just assumed prevented.

3.Answering "Who Changed What" with CloudTrail

Every CloudTrail event record carries the same five answers in fixed fields: who (userIdentity), what (eventName + eventSource), when (eventTime), from where (sourceIPAddress), and under which identity a role was assumed through (userIdentity.sessionContext.sessionIssuer, or sourceIdentity if configured). Reading these five fields together is how you turn a raw log entry into an answer to "who did this."

Key features

who: userIdentity.arn (and userIdentity.type) — IAMUser, AssumedRole, Root, FederatedUser, AWSService, or IdentityCenterUser
what: eventName (the API call, e.g. DeleteBucket) plus eventSource (the service, e.g. s3.amazonaws.com) and requestParameters (what was passed in)
when: eventTime, an ISO 8601 UTC timestamp on every event record
from where: sourceIPAddress — the caller's IP, or the AWS service name if the call originated from a service rather than a human or script
under which identity: for an assumed role, userIdentity.sessionContext.sessionIssuer.arn shows the role; sourceIdentity (if an admin configured AWS STS to require it) shows the original human behind a role chain
errorCode and errorMessage are also on the record — CloudTrail logs both successful and denied/failed API calls, so a rejected attempt is visible too

The five fields, one record

who

userIdentity.arn

what

eventName + eventSource

when

eventTime

from where

sourceIPAddress

under which identity

sessionIssuer / sourceIdentity

Signature

who: userIdentity.arn · what: eventSource+eventName · when: eventTime · where: sourceIPAddress · as-whom: sessionIssuer/sourceIdentity

Every CloudTrail event carries who (userIdentity.arn), what (eventSource + eventName), when (eventTime), from where (sourceIPAddress), and under which identity (sessionIssuer / sourceIdentity) in one record — no cross-system correlation needed to get the first five answers of an investigation.

Spotted a mistake on this page? Tell us.

Read Sheet