← AWS projects

AWS · Security Design

AWS Centralized Security Operations

Centralize security visibility across AWS accounts without collapsing workload isolation, using delegated administration, protected audit data, and organization-wide findings.

PlatformAWS
DomainSecurity
LevelAdvanced
Last reviewed2026-09-19
Use whenAggregate security posture and threat findings across multiple AWS accounts while preserving workload-account separation and centralized oversight.
Key decisionUse dedicated security ownership
Primary servicesAWS Organizations · AWS Security Hub · Amazon GuardDuty
Cost focusSecurity Hub controls
On this page

Building blocks

AWS OrganizationsAWS Security HubAmazon GuardDutyAWS CloudTrailAWS ConfigAmazon S3Amazon EventBridge

Design goal

Give security teams one place to detect, investigate, and govern risk across the AWS Organization while keeping workload accounts independently owned.

Architecture

A dedicated security account receives delegated administration and aggregated findings while CloudTrail and configuration/audit data are centralized according to the organization security model.

Workload AccountsAWS OrganizationsSecurity AccountSecurity Operations
Workload Accounts
AWS Organizations
Security Account
Security Operations

Architecture decisions

Decision

Use dedicated security ownership

Why

Separate security administration from workload administration.

Trade-off

A dedicated security function improves separation of duties but adds delegated-administration, access-review, and operating-process overhead.

Decision

Centralize findings, not every workload action

Why

Aggregate posture and threat signals centrally while keeping account-level boundaries intact.

Trade-off

Central visibility preserves account autonomy, but incident response still depends on clear ownership and coordinated action in workload accounts.

Security

Protect the control and data paths deliberately. Use least-privilege delegated administrator roles, organization policies, protected log archives, encryption, and restricted write access to security data.

Availability

Design for the failure domain that must be survived. Use regional aggregation and operational alerting based on the services and regions in scope.

Disaster recovery

Treat regional recovery as a separate operating state. Ensure critical audit logs and security findings are retained independently of compromised workload accounts; document regional service dependencies.

Cost drivers

  • Security Hub controls
  • GuardDuty analyzed events/data
  • CloudTrail data events
  • Config items
  • S3 log retention

Design assumptions

  • AWS Organizations is available
  • Security and log archive accounts are defined

Implementation plan

  1. Define dedicated security and log-archive responsibilities before delegating any organization-wide security service.
  2. Enable supported security services across the intended Organizational Units and delegate administration to the security account.
  3. Route audit logs and security findings to destinations that workload accounts cannot modify or delete.
  4. Define triage ownership, notification paths, and the boundary between central security actions and workload-team remediation.
  5. Onboard a pilot member account and verify that findings, logs, permissions, and response workflows behave as designed.

Validate the design

  • Generate a representative member-account finding and confirm it appears in the central security account.
  • Verify workload administrators cannot alter or delete protected audit data.
  • Test notification and triage routing from detection through assignment to the expected owner.
  • Onboard a new member account and confirm required detectors, standards, and logging are applied automatically.

Architecture basis

Continue a learning path