We already have an organization with many accounts (subchapter 30.1), created and governed with Control Tower (subchapter 30.2). But this multi-account structure creates a new challenge: if you have security and logs spread across dozens of accounts, how do you monitor and manage them together? Reviewing account by account would be impossible. The solution is to centralize security and logs: bring everything together in a common place to view and control it globally. In this subchapter, we’ll see why and how.

Remember all the security and observability we covered (Chapters 23 and 24): activity logs, threat findings, audit records... If each of your 50 accounts generates its own security and logs separately, monitoring everything becomes unfeasible:

You need a central view and management of the security and logs of the entire organization, not fragmented account by account.

The recommended practice is to centralize security and logs in dedicated accounts. It’s very common to have:

• A log account (log archive): where logs from all accounts are gathered, stored securely.
• A security account (security/audit): from where the security team monitors and manages the security of the entire organization.

Remember that Control Tower (subchapter 30.2) usually creates these specialized accounts automatically as part of the landing zone.

Analogy: centralizing security and logs is like having a security headquarters and a central archive for an entire chain of stores. Instead of each store keeping its own camera recordings and having its own isolated guard (with no one seeing the whole picture), all cameras send their feed to a single security center, and all recordings are stored in a protected central archive. This way, a central team monitors all stores at once, detects patterns that span several, and the recordings are safe even if someone tampers with a specific store.

Gathering logs from all accounts in a dedicated log account provides:

You have all records in one place, allowing you to analyze the activity of the entire organization together (for example, with the observability tools from Chapter 24, or a log data lake—see Chapter 29).

If the logs from each account are stored outside that account (in the central log account, which regular teams can’t delete from), no one can tamper with or delete the records from their own account to hide something. This is key for auditing and security: the logs are reliable and intact.

Having all records centralized and protected makes it much easier to demonstrate compliance to auditors and regulators (see Chapter 23): there’s a single, secure place with the entire trail.

Managing security from a central security account allows:

The security team sees and manages the security of all accounts from one place. Remember Security Hub (subchapter 23.4) and GuardDuty (subchapter 23.3): they can be configured to aggregate findings from the entire organization in the security account, providing that central view we saw as so valuable.

Some attacks touch multiple accounts. Only by seeing them together (from the central account) can you detect those patterns that, account by account, would go unnoticed.

In the event of an incident, the central security team can coordinate the response across affected accounts, instead of acting blindly in each one.

The resulting model is very powerful: each team operates autonomously in its account (freedom to work), but security and logs are governed centrally (control and global visibility). The best of both worlds: autonomy for teams and control for the organization.

Real-world example: a company with 40 accounts centralizes its security and logs. All records from the 40 accounts are sent to a protected log account, which product teams cannot delete from. All threat detection (GuardDuty, Security Hub) from the 40 accounts is aggregated in the security account, where the security team monitors everything. One day, an attacker compromises a team’s credentials and tries to move to other accounts. Because security is centralized, the team detects the pattern (suspicious activity crossing accounts) that would have gone unnoticed in isolated accounts, and responds in a coordinated way. Also, the attacker cannot delete the logs from the compromised account (they’re in the central account), so the entire trail remains for investigation. Centralization was decisive.

• With many accounts, having security and logs scattered in each one makes it impossible to monitor them together, detect attacks that cross accounts, or demonstrate global compliance.
• The solution is to centralize in dedicated accounts: a log account (gathers logs from all accounts) and a security account (from which the whole organization is monitored). Control Tower creates them (subchapter 30.2). Like a security headquarters and central archive for a chain of stores.
• Centralizing logs provides: complete visibility, tamper-proof protection (no one deletes logs from their own account, they remain safe as evidence), and easier compliance.
• Centralizing security provides: global monitoring (GuardDuty/Security Hub aggregated, Ch. 23), detection of threats that cross accounts, and coordinated response.
• The resulting model: central governance (security and logs) + distributed operation (autonomous teams in their accounts) = freedom and control at the same time.

In the last subchapter of the chapter, we’ll see how to manage this entire multi-account structure with Terraform, that is, Terraform at multi-account scale.