Audit Trail

An Audit Trail is a chronological record of activities that provides evidence of who did what, when, and from where. In AWS, CloudTrail is the primary audit trail: it records every API call across all services.

Components of an AWS Audit Trail

• CloudTrail: API call history (management + data events)
• S3 access logs: object-level access records
• VPC Flow Logs: network traffic metadata
• CloudWatch Logs: application and system logs
• Config: configuration change history for every resource

Each of these answers a different question. CloudTrail tells you which principal called which API; Config tells you what the resource looked like before and after; VPC Flow Logs tell you which network conversations actually happened; application logs tell you what the workload itself did with the request. During an investigation you almost always need at least two of them, correlated by timestamp and identity, which is why the trail is only useful if all the sources were enabled before the incident.

How It Goes Wrong in Practice

The recurring failure with audit trails is that they get attacked or neglected exactly where they matter most. On the attack side, disabling or degrading logging is a standard defense-evasion move: an intruder with sufficient permissions calls StopLogging on the trail, deletes it outright, or narrows its event selectors so their activity falls outside what is recorded, then proceeds with the actual objective. If the trail's S3 bucket lives in the same account the attacker owns, they can also delete the historical log files, destroying the evidence retroactively. On the neglect side, teams run a single-region trail while an attacker operates in a region the company never uses, or they enable management events but never turn on data events, so the investigation can prove a role listed a bucket but not which objects were read. The countermeasures are well established: use a multi-region organization trail so coverage does not depend on per-account discipline, deliver logs to a dedicated log-archive account that workload administrators cannot write to, enable log file validation so any tampering with delivered files becomes detectable, and alarm on CloudTrail configuration changes (a control that appears in the CIS AWS Foundations Benchmark precisely because trail tampering is so common). An audit trail you cannot trust after a compromise is not an audit trail; it is a suggestion.

Practical Check: Verify the Trail Is Actually Logging

A trail that exists is not the same as a trail that works. Check the live status:

aws cloudtrail get-trail-status --name my-org-trail

Confirm that IsLogging is true, that LatestDeliveryTime is recent, and that LatestDeliveryError is empty; a delivery error usually means a broken bucket policy or a deleted KMS key, and it means your trail has been silently dropping history. To hunt for tampering attempts, query the event history directly:

aws cloudtrail lookup-events --lookup-attributes AttributeKey=EventName,AttributeValue=StopLogging

Run the same lookup for DeleteTrail and UpdateTrail. Any unexpected hit deserves an immediate investigation of the calling identity.

Frequently Asked Questions

How long is the audit trail retained?
CloudTrail event history gives you 90 days of management events by default. Anything longer requires a trail delivering to S3, where retention is whatever your lifecycle policy says. Compliance frameworks commonly require a year or more, so configure S3 lifecycle rules deliberately rather than relying on defaults.

How do I know my logs have not been modified?
Enable CloudTrail log file validation on the trail. CloudTrail then delivers digest files that let you cryptographically verify whether delivered log files were changed or deleted after the fact. Combine that with a log-archive account and restrictive bucket policies so modification is hard in the first place, not just detectable.

Who should be able to read the audit trail?
Fewer people than can write to production, and through a different door. Investigators and auditors need read access; workload administrators generally do not, and the identities being audited certainly should not control the logs that audit them. Separating those permissions is the entire point of a dedicated log-archive account.

Is CloudTrail alone a complete audit trail?
No. CloudTrail covers the AWS control plane and, if you enable data events, some data-plane operations. It does not see inside your application: database queries, application logins, and business transactions need their own logging into CloudWatch Logs or your log platform. A complete audit trail is the union of CloudTrail, Config history, network logs, and application logs, with clocks and identities you can correlate.