Centralized Log Archive Accounts

The strongest log protection puts logs in a separate AWS account dedicated to archival, isolated from the accounts that run workloads. If an attacker compromises a production account, they still cannot reach or delete the logs stored in an account they do not control. This isolation is a cornerstone of mature security architecture.

In a multi-account organization, a dedicated Log Archive account receives logs from every other account. AWS Control Tower creates exactly this account by default in its landing zone, reflecting how strongly AWS recommends the pattern. Centralizing logs here gives one protected home for all audit evidence.

An organization trail in CloudTrail captures events from all accounts in the organization and delivers them to a single bucket, typically in the Log Archive account. Member accounts cannot disable or modify the organization trail, so even a fully compromised member account cannot stop its events from being recorded centrally.

Logs are delivered cross-account by granting the logging services write access to the central bucket through a bucket policy. The workload accounts can write logs but cannot read or delete them, because read and delete permissions live only with security roles in the archive account. This cleanly enforces separation of duties.

Very few principals should access the Log Archive account, and ideally none of them are the same people who administer workloads. Access is limited to a small security or audit team, often through tightly scoped cross-account roles. Minimizing who can touch the archive shrinks the chance the evidence is compromised.

Service Control Policies (SCPs) at the organization level can deny actions like cloudtrail:StopLogging, cloudtrail:DeleteTrail, and deletion of the log bucket across all member accounts. Because SCPs cap permissions even for account admins, they prevent anyone in a member account from disabling logging, no matter their IAM permissions.

The central bucket should combine everything from the previous lesson: Object Lock in Compliance mode, versioning, KMS encryption, and a deny-delete policy. Concentrating all logs in one place is only safe if that place is immutable and tightly controlled, so the archive account applies the strongest bucket hardening available.

Beyond CloudTrail, you can centralize Config, VPC Flow Logs, and application logs into the archive account too, often via cross-account delivery or replication. A single, protected archive for all log types simplifies retention, monitoring, and investigation while keeping every source out of an attacker's reach.

Security teams query the centralized logs with Athena from the archive account or a dedicated security tooling account. Because all accounts' logs sit together, one query can hunt across the entire organization, making org-wide investigation and threat hunting far more powerful than checking each account separately.

Centralization also aids resilience and retention: lifecycle rules move aging logs to cheaper storage like Glacier while Object Lock preserves immutability, and cross-region replication can guard against regional loss. The archive becomes a durable, long-lived, tamper-proof record that satisfies even strict compliance retention requirements.

A centralized, immutable Log Archive account, fed by an organization trail, protected by SCPs, and locked with Object Lock, is the gold standard for log integrity. It ensures that no matter what an attacker does in a workload account, the truth of their actions survives in a place they can never reach.

Test your centralized-logging knowledge.

A dedicated Log Archive account isolates evidence from workload accounts. An organization trail centralizes CloudTrail to its bucket, which member accounts cannot disable. Cross-account bucket policies let accounts write but not delete, SCPs deny StopLogging/DeleteTrail org-wide, and Object Lock plus encryption make storage immutable. The result is tamper-proof, query-ready, compliant log retention.