The default view of AWS activity most engineers reach for — CloudTrail Event History — retains only 90 days of management events per Region, with no setup required and no durable copy anywhere else. That's fine for "who deleted this security group yesterday," and useless for a breach investigation that starts six months after the intrusion, or a SOC 2 auditor asking for a year of evidence. AWS's own fix is the organization trail: created once from the management account, it automatically applies to every existing and future member account, streaming all of their events into a single, centrally owned S3 bucket. The harder problem isn't turning it on — it's making the resulting log archive something an attacker with IAM access can't quietly edit or delete, and something an auditor can verify wasn't edited or deleted. AWS builds that guarantee in with SHA-256 log file hashing and hourly signed digest files, but only if you wire the surrounding S3 bucket policy, KMS key policy, and account boundary correctly. Get any one of those wrong and you have a log bucket, not audit evidence. This post walks through the architecture: org trails, the log-archive account pattern, log file validation mechanics, retention tiers via CloudTrail Lake, and the alerting you need on the handful of API calls that turn logging off.
Why does a single-account trail fail for a multi-account org?
A single-account trail fails because it only sees what happens inside that one account, while a real AWS estate is a multi-account organization where workloads, data, and blast radius are deliberately spread across accounts for isolation. If an attacker compromises credentials in a spoke account that has no trail of its own — or one whose trail delivers to a bucket the same account controls — they can call StopLogging or delete the trail before doing anything else, and there is no independent record. AWS Organizations' organization trail closes this gap structurally: it is created and owned from the management account, applies to every member account automatically as accounts are added, and member accounts cannot see, modify, or disable it in their own console or CLI — only the management account can. That single control converts "each account might have logging" into "every account is logged, by policy, with no local opt-out."
What does tamper-evidence in CloudTrail actually rely on?
Tamper-evidence in CloudTrail relies on log file integrity validation, a feature that has to be explicitly enabled on the trail and is not on by default. When enabled, CloudTrail computes a SHA-256 hash of every log file it delivers to S3, then once per hour produces a separate signed digest file — signed with SHA-256-with-RSA — that records the hashes of all log files delivered in that period. Digest files are written to a distinct S3 prefix from the log files themselves, which matters: an investigator (or the AWS CLI's built-in aws cloudtrail validate-logs check) can recompute a log file's hash and compare it against the value the signed digest recorded. Any difference — a modified event, a deleted file, a file swapped after the fact — is detectable, because tampering with the log file no longer matches the hash a cryptographic signature already vouched for. This is the actual "tamper-evident" mechanism; enabling a trail alone gives you delivery, not proof of integrity, per AWS's own documentation on log file validation.
How should the log-archive account be locked down?
The log-archive account should be locked down using S3, IAM, and KMS controls layered together, following the pattern AWS's security best practices guidance describes for a dedicated log-archive account inside the organization. The org trail delivers to an S3 bucket that lives in an account with no workloads and minimal human access — not the management account and not a production account. The bucket policy explicitly denies s3:DeleteObject, s3:DeleteBucket, and s3:PutBucketPolicy to every principal except a break-glass role gated behind a separate approval process, and S3 Object Lock (or, at minimum, versioning with MFA Delete) is enabled so that even an authorized delete becomes a soft-delete an investigator can recover. Server-side encryption uses SSE-KMS with a customer-managed key whose key policy restricts kms:Decrypt to a short list of security-tooling roles — so even someone with S3 read access to the bucket can't read log contents without a second, separately governed permission. Log file validation is enabled on the trail itself, and the account has no other purpose that would justify broad IAM access to it.
What retention should the org actually keep, and where?
Retention should be tiered because S3-delivered CloudTrail files and CloudTrail Lake serve different jobs: S3 is the durable, cryptographically validated archive, while CloudTrail Lake is the queryable layer investigators and auditors actually search. Lake offers two retention options on ingested event data: a one-year default that's extendable in increments up to a total of 3,653 days (roughly ten years), or a fixed seven-year option capped at 2,557 days — priced separately from ingestion, with extended retention billed at $0.023 per GB per month on top of a $0.75 per GB ingestion charge for native CloudTrail events. Most compliance regimes that reference AWS activity logs — SOC 2 evidence requests commonly cover a 12-month look-back — are satisfied well within Lake's one-year tier, but organizations under longer statutory retention (some financial and government contexts) should size against the seven-year option explicitly rather than assuming the default. The S3 bucket, meanwhile, should simply never expire log objects inside the retention window your compliance program commits to — lifecycle rules that transition to Glacier are fine; lifecycle rules that delete are not.
What should page someone at 2am?
A small set of API calls should page someone immediately, because disabling logging is a well-documented first move once an attacker has IAM access in an AWS account. StopLogging, DeleteTrail, UpdateTrail (particularly changes that narrow event selectors or redirect the destination bucket), and any PutBucketPolicy or PutBucketAcl call against the log-archive bucket itself are the calls that matter most — routed through EventBridge rules matching those event names, with an SNS topic fanning out to on-call and, ideally, a channel outside the AWS account being altered. Because the organization trail's control plane lives in the management account, member-account attempts to touch it will simply fail with an authorization error rather than succeed quietly — but management-account compromise is exactly the scenario cross-account replication of the log bucket into a fourth, isolated account is meant to survive, since an attacker would need to compromise two separately governed accounts, not one, to erase the trail.
How Safeguard Helps
Safeguard doesn't ingest or manage AWS CloudTrail data directly — CloudTrail architecture is infrastructure you own and configure in your AWS accounts. But the underlying pattern this post describes — an immutable, independently governed audit trail that stands up as compliance evidence — is exactly what Safeguard Portal builds for your software supply chain activity: every SBOM import, finding triage decision, policy override, and admin action is logged with actor, action, resource, and result fields, exported to Splunk, Elastic, Datadog, or Sumo Logic via the same kind of SIEM integration a mature CloudTrail pipeline feeds into, and packaged into SOC 2 and FedRAMP-ready evidence exports on demand. If your compliance story already leans on a validated, tamper-evident CloudTrail architecture for infrastructure activity, Safeguard's audit trail is the equivalent control for the vulnerability and dependency decisions your security team makes on top of it — two independently verifiable records instead of one gap where "we trust the console" used to be.