Central security and logging
Collecting audit logs, findings and compliance data from every account and Region into dedicated security accounts, and making the logs tamper-proof.
Exam tasks: 1.2 (prescribe security controls, centralized logging and auditing), 1.4 (design a multi-account environment)
The decision: where do logs and findings from hundreds of accounts land, who administers the security services, and how do you prove nobody changed the evidence?
The target architecture
Two accounts in a Security OU do the work. Neither runs workloads.
- Log archive account: owns the S3 buckets that receive CloudTrail, Config and other logs. Almost nobody can sign in, and nothing can delete.
- Security tooling (audit) account: the delegated administrator for GuardDuty, Security Hub, Config, Inspector, Access Analyzer, Macie and Security Lake. The security team works here, not in the management account.
Which service answers which question
| Question | Service | Organization-wide setup |
|---|---|---|
| Who called which API, when, from where? | CloudTrail | Organization trail from the management account or a CloudTrail delegated admin |
| Is anything behaving maliciously right now? | GuardDuty | Delegated admin, auto-enable for new accounts, per Region |
| What did this resource look like last Tuesday, and is it compliant? | AWS Config | Organization rules and conformance packs, plus an aggregator |
| Are we following FSBP, CIS or PCI DSS? | Security Hub CSPM | Delegated admin with central configuration policies |
| Which workloads have known CVEs? | Amazon Inspector | Delegated admin, auto-enable EC2, ECR and Lambda scanning |
| Who outside the organization can reach this resource? | IAM Access Analyzer | Analyzer with the organization as the zone of trust |
| Where's the sensitive data in S3? | Amazon Macie | Delegated admin, automated discovery |
| Can we query years of security logs in one place? | Security Lake | Delegated admin, rollup Region, OCSF in S3 |
Detective vs compliance vs threat
Config records state and compliance ("is encryption on?"). GuardDuty detects threats ("an instance is talking to a crypto-mining pool"). CloudTrail records actions ("who turned encryption off?"). Match the verb in the question to the service.
CloudTrail organization trail
- Create it once in the management account, or in a delegated administrator account for CloudTrail. It applies to every current and future member account.
- Member accounts can see the trail but can't stop, modify or delete it.
- Make it a multi-Region trail so a new Region or an attacker's favourite unused Region is still logged.
- Deliver to a bucket in the log archive account. The bucket policy lets
cloudtrail.amazonaws.comwrite, scoped withaws:SourceArnto the trail. Encrypt with a KMS key whose policy allows CloudTrail to use it. - Turn on log file integrity validation. CloudTrail writes signed digest files every hour so you can prove a log file wasn't changed or deleted after delivery.
- Management events are logged by default. Data events (S3 object reads, Lambda invokes, DynamoDB items) must be selected explicitly and cost extra.
- CloudTrail Lake stores events in an organization event data store you query with SQL, as an alternative to building Athena tables over the bucket.
Integrity validation isn't immutability
Digest files detect tampering. They don't prevent someone with bucket permissions from deleting logs. To prevent deletion, you need S3 Object Lock, a restrictive bucket policy and an SCP that stops anyone from changing either.
Making logs immutable
| Control | What it stops |
|---|---|
| S3 Object Lock, compliance mode | Any delete or overwrite of a locked object version before the retention date, by anyone, root included |
| S3 Object Lock, governance mode | Deletes by most users. Principals with s3:BypassGovernanceRetention can still remove objects |
| Legal hold | Deletion with no expiry date, until the hold is removed |
Bucket policy denying s3:DeleteObject and policy changes | Accidental or casual deletes by admins in the log archive account |
| SCP on the Security OU | Anyone disabling CloudTrail, GuardDuty or Config, or editing the log bucket's policy |
| Separate account | A compromised workload account reaching its own audit trail |
- Object Lock needs versioning. You can enable it on new buckets and on existing ones.
- Pair it with lifecycle rules that move old logs to S3 Glacier storage classes. Retention still applies after the transition.
Security Hub and GuardDuty at scale
- Delegated administrator. Designate the security tooling account from the management account. It then enables the service for members and sees all their findings.
- Auto-enable new accounts that join the organization, so coverage doesn't depend on someone remembering.
- Cross-Region aggregation. Security Hub links Regions to one home Region, so analysts see every Region's findings in one console and one EventBridge stream.
- Central configuration policies in Security Hub CSPM decide which standards and controls are on for each OU.
- Security Hub CSPM controls depend on AWS Config recording in each account and Region.
- GuardDuty reads CloudTrail, VPC Flow Logs and DNS query logs directly. You don't need to turn those logs on for GuardDuty. Add protection plans (S3, EKS, Runtime Monitoring, Malware Protection, RDS, Lambda) as needed.
Security Hub naming in 2026
The original posture-checking service is now called AWS Security Hub CSPM and uses ASFF findings. The newer AWS Security Hub correlates signals from Security Hub CSPM, GuardDuty, Inspector and Macie into prioritized exposures, using OCSF. Exam questions mostly describe the aggregation behaviour, which both share.
AWS Config across the organization
- Organization Config rules and organization conformance packs are deployed from the management account or a delegated admin, and members can't delete them.
- A conformance pack is a bundle of rules and remediations, such as the operational best practices for PCI DSS, deployed as one unit.
- Remediation uses Systems Manager Automation documents, run automatically or on demand.
- An aggregator gives a read-only, multi-account, multi-Region view of configuration and compliance. Advanced queries run SQL-like queries against it ("every unencrypted EBS volume in the org").
Aggregators don't enforce
An aggregator only collects. It doesn't deploy rules, record resources or fix anything. If a question asks to apply a rule everywhere, the answer is organization rules or conformance packs, not an aggregator.
Other org-wide detectors
- IAM Access Analyzer: with the organization as the zone of trust, it flags S3 buckets, KMS keys, IAM roles, queues, secrets and other resources that are shared outside the org. Unused access analyzers find stale roles, keys and permissions. Policy validation and policy generation from CloudTrail help write least-privilege policies.
- Amazon Inspector: continuous vulnerability scanning of EC2 instances (through the SSM agent or agentless snapshots), ECR container images and Lambda functions. Findings flow into Security Hub.
- Amazon Security Lake: normalizes CloudTrail, VPC Flow Logs, Route 53 Resolver logs, Security Hub findings, EKS audit logs, WAF logs and custom sources into OCSF in Apache Parquet in S3. Contributing Regions roll up into a rollup Region. Subscribers get either data access (S3 plus notifications) or query access (through Lake Formation and Athena).
Exam signal
"Security team wants a single place to query logs from all accounts with a standard schema, and to share it with a third-party SIEM" points to Security Lake. "Just store CloudTrail centrally" is an organization trail.
Central notifications with EventBridge
GuardDuty, Security Hub, Config and Inspector publish findings as events to the default event bus of the account and Region where they're generated. Two patterns route them centrally:
- Use the aggregation you already have. The delegated admin account's Security Hub home Region receives all findings, so one EventBridge rule there covers the organization.
- Cross-account event bus. Member accounts have a rule whose target is a custom bus in the security account.
The bus's resource policy allows
events:PutEventsfrom the organization with anaws:PrincipalOrgIDcondition, so new accounts work without editing the policy.
From the central bus, fan out to SNS, a chat channel, a ticketing system or a Lambda function that isolates the resource. See auto-remediation for response patterns and observability for application logs and CloudWatch cross-account views.
Scenarios
An organization trail covers new accounts automatically, and members can't turn it off. Object Lock in compliance mode stops anyone, root included, from deleting the logs before the retention date. Per-account trails can be deleted by account admins, and MFA delete can be removed by the bucket owner. Integrity validation only detects tampering, and the management account shouldn't host workloads or logs. Event history keeps only 90 days and needs a manual export.
Delegated admin moves administration out of the management account and auto-enable covers new accounts. Cross-Region aggregation brings every Region's findings to one home Region, where a single EventBridge rule can invoke the Lambda function. Config aggregators collect configuration and compliance data, not GuardDuty findings. Manual invitations don't scale or cover new accounts. A rule in every account and Region multiplies what you maintain and still needs cross-account invoke permissions.
Organization conformance packs deploy rules to every account, including new ones, and members can't delete them. An aggregator only reports on rules that already exist and a weekly query is manual. Per-team rules can be skipped or removed. GuardDuty Malware Protection scans for malware and doesn't check encryption settings.