CloudTrail Log File Validation

CloudTrail log file validation lets you prove that log files delivered to S3 were not modified, deleted, or forged after CloudTrail wrote them. It is the feature that turns "we hope the logs are intact" into "we can cryptographically demonstrate they are." Enabling it is a one-click best practice on any trail.

When enabled, CloudTrail creates a digest file every hour that references the log files delivered in that period and contains a hash of each. The digest files are themselves signed. Together they form a chain that lets you verify both that each log file is unchanged and that none are missing.

Each log file is hashed with SHA-256, and the digest file is signed using SHA-256 with RSA. Because any change to a log file changes its hash, and the digest is cryptographically signed, an attacker cannot alter a log without breaking the math. This is what makes the logs tamper-evident.

Each digest file also references the previous digest file, forming a chained sequence hour after hour. This chaining means you can detect not only a modified log file but a missing or deleted digest, since a gap breaks the chain. The continuous chain is what proves completeness over time.

You verify integrity using the validate-logs CLI command, which checks the digest signatures and the hashes of the referenced log files for a time range. It reports any file that was modified, deleted, or whose digest is missing. This gives investigators an authoritative integrity check on demand.

An important nuance: validation is detective, not preventive. It does not stop someone from deleting a log file; it lets you prove that they did. To prevent deletion you combine validation with bucket protections like Object Lock. Validation tells you the truth; other controls enforce it.

Digest files live in the same S3 bucket as the logs and must be protected just as carefully. If an attacker could regenerate or delete digests freely, the proof would be undermined. Storing digests in a locked-down, ideally immutable, bucket preserves the integrity guarantee end to end.

Validation is the integrity pillar of log protection. It works hand in hand with immutable storage for availability and encryption for confidentiality. On the exam, when a scenario asks how to prove logs were not tampered with after delivery, CloudTrail log file validation is the precise answer.

You turn on validation when creating or updating a trail, with a single setting. There is no extra charge for the validation feature itself beyond the normal S3 storage of digest files. Given the strong benefit and negligible cost, it should be enabled on every trail without exception.

Run validation routinely, not just during incidents, so you would notice tampering quickly. Some teams automate validate-logs on a schedule and alert on any failure. Regular validation turns the feature from a forensic afterthought into an active integrity monitor for your audit trail.

During an audit, log file validation provides the cryptographic proof that your audit trail is complete and unaltered, satisfying requirements in frameworks like PCI DSS and SOC 2. Being able to run validate-logs and show a clean result is concrete evidence that your monitoring data can be trusted as the record of events.

Test your validation knowledge.

CloudTrail log file validation proves logs were not tampered with after delivery. Hourly digest files hold SHA-256 hashes of logs, are signed, and chain to the previous digest so missing files are detectable. Verify with validate-logs. It is detective, so pair it with immutable storage to prevent deletion. Enable it on every trail and validate routinely.