Centrally managing security services
Lesson 4 of 5 in The Multi-Account Foundation.
Every security service in the AWS catalogue is, by default, a per-account per-Region switch. Enable GuardDuty in an account and you have protected that account. Do it 200 times and you have a spreadsheet, a gap for every account created since you made the spreadsheet, and 200 consoles to look in.
The fix is one two-step pattern that repeats service after service, and it is worth internalising as a reflex rather than a list. Enable trusted access for the service in the organization, then designate a delegated administrator — a member account, conventionally the security tooling account — which from then on enables the service across every member account, sees every finding in one place, and (the part a question always probes) auto-enables accounts created later.
Why not just run everything from the management account, which can already do all of this? Three reasons, and they are the same three that keep workloads out of it: its blast radius is the whole organization; its principals are exempt from your SCPs and RCPs, so your security team would be operating outside your own guardrails; and least privilege says the people who read findings all day should not hold the credential that can close accounts. AWS's own recommendation is explicit — keep the management account out of the administrator role.
| Service | What the delegated administrator gets | The detail the exam uses |
|---|---|---|
Security Hub | Findings from every member account, organization-wide standards and controls | Central configuration lets the admin apply configuration policies to OUs and accounts instead of per-account enablement — and a finding aggregation Region collapses Regions into one view |
GuardDuty | Member enablement, protection plans, suppression rules, all findings | Auto-enable for new accounts; the designation is per Region, and protection plans (EKS, Malware, RDS, Lambda, S3) are enabled per Region too |
AWS Config | The organization aggregator, organization Config rules and organization conformance packs | The aggregator only reads — it enables nothing. Organization rules and packs are what actually switch evaluation on in members |
Inspector | Org-wide scanning of EC2, ECR images, Lambda functions, with findings centralized | Auto-enable per scan type for new accounts; coverage depends on the SSM agent being present and managed |
Macie | Sensitive-data discovery jobs and findings across accounts | Per Region, like GuardDuty; the admin can run jobs against buckets in member accounts |
Detective | The behaviour graph spanning member accounts | Needs GuardDuty already enabled; the graph is the investigation surface, not another detector |
IAM Access Analyzer | An analyzer whose zone of trust is the organization, plus unused-access findings | An account-level analyzer flags any cross-account grant; an organization-level analyzer only flags grants that leave the organization — picking the wrong zone of trust floods or starves the queue |
Firewall Manager | Policies that apply WAF, Shield Advanced, security group, Network Firewall and DNS Firewall configuration org-wide | Uses its own administrator account designation and requires all-features plus AWS Config enabled; multiple scoped admins are supported |
Audit Manager | Assessments whose scope spans member accounts, collecting their evidence centrally | Designate it once; evidence then arrives from every in-scope account without per-account setup |
Security Lake | The org-wide OCSF data lake, with rollup Regions | Collection is configured per source and per Region; the lake is the destination, not a detector |
Two refinements on the pattern. The administrator/member relationship is not symmetric: the administrator can enable features, set configuration and read findings in members, while a member can see its own findings and usually cannot disable what the administrator enabled. That asymmetry is the control — a workload team cannot quietly switch GuardDuty off in its own account.
And delegation now extends to Organizations itself. A resource-based delegation policy on the organization can let a nominated member account manage specified policy types, so the team that writes SCPs does not need a seat in the management account either. The direction of travel across every one of these services is the same: the management account grants the delegation and then gets out of the way.
Key terms: Delegated administrator, Trusted access, Security tooling account, Central configuration, Config aggregator
Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.