July 10, 202613 min read

AWS Organizations Multi-Account Security Architecture: SCPs, Centralized Logging, and Security Hub

Sources:AWS Security Reference Architecture|AWS Organizations SCP Design Guide|AWS Well-Architected Security Pillar

Eric Bang

Founder & Cybersecurity Evangelist

85%

of organizations with 10+ AWS accounts have at least one account with misconfigured logging or missing security controls — AWS customer security assessments

SCPs

Service Control Policies — the only AWS mechanism that restricts even the root user in member accounts, making them the highest-leverage security control in a multi-account environment

4 foundational

AWS accounts every multi-account organization should have: Management (org root only), Security/Audit (logging and security tooling), Log Archive (immutable log storage), and Shared Services

15 minutes

time for AWS CloudTrail to deliver organization-level API event records to a centralized S3 bucket — the detection lag between an API call and a SIEM alert

Foundational account structure

The account structure you establish early determines the security architecture options available later. AWS's Security Reference Architecture defines four foundational accounts that every multi-account organization should establish.

Management account: organization root only

The AWS Organizations management account (formerly 'master account') holds organizational control. It should contain no production workloads, no development resources, and no business applications. The management account's only function is: creating and managing member accounts, configuring organization-level policies (SCPs, tag policies, backup policies), and enabling organization-wide services (Security Hub delegated admin, GuardDuty delegated admin). Restricting the management account to organizational control only limits the blast radius if management account credentials are compromised.

Security/Audit account: security tooling and read-only access

The Security/Audit account houses security tools that need cross-account visibility: AWS Security Hub (aggregation), GuardDuty (delegated admin), AWS Config aggregation, and security team workloads. Security team personnel have administrative access to this account; they have read-only cross-account access to all member accounts via IAM roles. Separating security tooling from production workloads prevents a compromised production account from affecting security monitoring.

Log Archive account: immutable log destination

CloudTrail organization trails, VPC Flow Logs, S3 access logs, and other security-relevant logs should be delivered to S3 buckets in a dedicated Log Archive account. Apply S3 Object Lock to these buckets (WORM — write once, read many). The Log Archive account should have extremely restricted access: security team read-only for investigation, automated delivery write access for log sources, and no other access. Even if a member account is compromised, the attacker cannot delete or modify logs in the separate Log Archive account.

Shared Services account: centralized networking and shared infrastructure

VPC peering hubs, Transit Gateway attachments, shared DNS resolvers, and infrastructure shared across accounts (AD connectors, shared developer tools) live in the Shared Services account. Centralizing shared network infrastructure in one account simplifies routing security and provides a single point of network-level policy enforcement.

Subscribe to unlock Remediation & Mitigation steps

Free subscribers unlock full IOC lists, Sigma detection rules, remediation steps, and every daily briefing.

Service Control Policies: the highest-leverage security control

SCPs are policies attached to organizational units (OUs) or individual accounts that restrict what API actions can be performed in those accounts — even by the account's root user. They are deny-by-default: an SCP allowlist limits all member accounts to only the actions listed, regardless of IAM policies. An SCP denylist blocks specific actions across all accounts in the OU.

The most effective SCP strategy uses a denylist approach: allow all actions by default (FullAWSAccess), then attach specific deny SCPs that block high-risk actions organization-wide.

Deny disabling CloudTrail and Config

The most critical SCP for security: deny cloudtrail:StopLogging, cloudtrail:DeleteTrail, cloudtrail:UpdateTrail (removing logging capabilities), and config:DeleteConfigRule, config:StopConfigurationRecorder (disabling compliance monitoring). This prevents an attacker who compromises any member account — including with admin credentials — from disabling audit logging to cover their tracks. Apply this SCP to the root of the organization so it applies to all accounts including the management account OU (with exclusion for the management account itself where necessary).

Deny leaving the organization

Deny organizations:LeaveOrganization in all member account OUs. An attacker who compromises a member account and removes it from the organization also removes it from SCP enforcement, Security Hub aggregation, GuardDuty coverage, and centralized logging. Preventing account removal from the organization is a fundamental security guardrail.

Restrict to approved AWS regions

If your organization only operates in us-east-1 and eu-west-1, deny all API calls except specific global services (IAM, Route53, CloudFront, STS) in all other regions. This prevents attackers from spinning up resources in regions you don't monitor and reduces your compliance scope. Implement via: a deny SCP with a condition that the requested region is not in your approved list, with an exception for global services using aws:RequestedRegion.

Deny root account usage

The AWS account root user has unlimited permissions that cannot be restricted by SCPs. Deny aws:PrincipalAccount = root for all API calls except account-level actions that require root (very few). In practice: alert on root login (CloudTrail event ConsoleLogin with userIdentity.type = Root) and also create an SCP that denies all actions when the principal is the account root user — this forces all administrative work through IAM users and roles where permissions can be scoped and logged.

Enforce MFA for IAM users

Deny all API actions for IAM users when MFA has not been used in the session, except for the specific IAM actions needed to set up MFA. This forces all human IAM user actions in member accounts to require MFA. The standard SCP pattern: deny all actions with a condition of aws:MultiFactorAuthPresent = false, with exceptions for IAM MFA management actions. Service accounts using IAM roles for EC2/Lambda/etc. are not affected because role assumption uses STS, not IAM user credentials.

Subscribe to unlock Remediation & Mitigation steps

Free subscribers unlock full IOC lists, Sigma detection rules, remediation steps, and every daily briefing.

Free daily briefing

Briefings like this, every morning before 9am.

Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.

Centralized CloudTrail: organization-level trail configuration

A CloudTrail organization trail, configured in the management account, captures API events from all member accounts and delivers them to a centralized S3 bucket in the Log Archive account. This is a single configuration in the management account that provides logging coverage for all current and future member accounts automatically.

Create a CloudTrail organization trail

In the management account: CloudTrail > Trails > Create trail. Select 'Enable for all accounts in my organization'. Set the destination S3 bucket in your Log Archive account. Enable log file validation (ensures logs cannot be tampered without detection). Enable management events (all API calls), S3 data events for your most sensitive buckets, and Lambda data events for your critical functions. An organization trail is the only way to ensure new accounts created in the future automatically have logging without manual configuration.

CloudWatch Logs delivery for near-real-time detection

In addition to S3 delivery for long-term retention, configure CloudTrail to deliver events to CloudWatch Logs in the Security account. CloudWatch Logs enables near-real-time alerting: CloudWatch Metric Filters + Alarms can alert within minutes on specific API patterns (root login, IAM policy changes, security group changes, GuardDuty disablement). This provides fast detection without requiring a full SIEM pipeline.

Athena for cross-account log analysis

S3-delivered CloudTrail logs are in JSON format and can be queried with Amazon Athena. In the Log Archive account, create an Athena table partitioned by account, region, and date. This allows cross-account, cross-region security queries during incidents: 'show all API calls by this IAM user across all accounts in the past 7 days' or 'show all EC2 launches in all accounts in the past hour'. This capability is invaluable during incident response in multi-account environments.

Subscribe to unlock Remediation & Mitigation steps

Free subscribers unlock full IOC lists, Sigma detection rules, remediation steps, and every daily briefing.

Security Hub and GuardDuty at organization scale

AWS Security Hub and GuardDuty both support Organization-level delegation, where a designated Security account aggregates findings from all member accounts into a single pane. Configure both services at organization level rather than account by account.

Security Hub delegated admin in the Security account

From the management account: Security Hub > Settings > Delegated administrator > select your Security account. This allows the Security account to manage Security Hub for all organizational accounts. Auto-enable Security Hub in all new member accounts: in the Security Hub organization settings, enable auto-enrollment. Security Hub aggregates: AWS Foundational Security Best Practices findings (AWS-native misconfiguration detection), CIS AWS Foundations Benchmark, PCI DSS controls, and findings from integrated services (GuardDuty, Inspector, Macie). This is your unified cloud misconfiguration and threat finding view.

GuardDuty delegated admin and organization-wide coverage

GuardDuty detects threats in AWS accounts (crypto mining, credential theft, unusual API activity, network anomalies). Configure via: GuardDuty console in the management account > Delegated administrator > select Security account. Enable auto-enable for new member accounts. GuardDuty costs are per-account based on data volume — for new accounts, ensure auto-enable is configured so GuardDuty is not manually forgotten for newly-created member accounts.

Cross-account finding suppression and integration

Security Hub aggregation creates a unified finding view but also creates finding noise from lower-priority accounts (dev/test environments). Configure Security Hub finding filters to differentiate production account findings (high priority, alert to SIEM) from development account findings (low priority, review weekly). Also integrate Security Hub findings with your SIEM via EventBridge: Security Hub custom action > EventBridge rule > Lambda > SIEM API.

Subscribe to unlock Remediation & Mitigation steps

Free subscribers unlock full IOC lists, Sigma detection rules, remediation steps, and every daily briefing.

The bottom line

Multi-account AWS security is an architecture problem, not a configuration problem. The decisions made about account structure, SCP design, and centralized logging in the early stages of a multi-account environment determine whether you have one defensible security posture or 20 different security postures that each need to be audited and maintained separately. The four foundational accounts, five core SCPs, organization-level CloudTrail, and Security Hub/GuardDuty delegation described here provide a scalable baseline that covers all current and future accounts automatically.

Frequently asked questions

What is the difference between AWS Control Tower and manual Organizations setup?

AWS Control Tower is a managed service that automates the deployment of a multi-account environment with guardrails (implemented as SCPs and AWS Config rules), the foundational account structure (Management, Audit, Log Archive), and ongoing drift detection. Manual Organizations setup gives more flexibility but requires manual implementation of everything Control Tower provides. Control Tower is the right choice for organizations starting a multi-account environment from scratch or standardizing an existing informal multi-account setup. Manual Organizations is appropriate when Control Tower's guardrails are too restrictive for specific use cases or when migrating an existing complex environment where Control Tower's account vending model doesn't fit.

How do SCPs interact with IAM policies?

SCPs and IAM policies use a combined evaluation model. An API call is allowed only if: (1) the SCP allows the action (or the account has FullAWSAccess and no deny SCP blocks it), AND (2) the IAM policy allows the action. Either layer can deny the action — an IAM allow does not override an SCP deny. This means SCPs create a ceiling: even if an IAM policy grants s3:DeleteBucket, an SCP that denies s3:DeleteBucket prevents the action. SCPs do not grant permissions on their own — they only restrict what IAM policies can allow.

What is the cost of running Security Hub and GuardDuty organization-wide?

GuardDuty pricing is based on data volume analyzed (CloudTrail events, DNS logs, VPC Flow Logs) per account per region. For a mid-size organization (20 accounts, 3 active regions), GuardDuty typically costs $500-$2000/month at scale. Security Hub pricing is based on finding ingestion volume — the first 10,000 finding ingestions per account per month are free; additional findings are $0.0030 per finding. For most organizations, Security Hub costs $100-$500/month organization-wide. These are estimates — use AWS Cost Calculator with your expected CloudTrail volume for accurate estimates.

Sources & references

Free resources

Free download

Critical CVE Reference Card 2025–2026

25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.

Free download

Ransomware Incident Response Playbook

Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.

Free newsletter

Get threat intel before your inbox does.

50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.

Unsubscribe anytime. We never sell your data.

Author

Eric BangCISSP

Founder & Cybersecurity Evangelist, Decryption Digest

Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.

View profile →LinkedIn

Back to all briefings

Subscribe for Updates

AWS Organizations security multi-account AWS security AWS SCP design CloudTrail centralized logging AWS Security Hub aggregation GuardDuty delegated admin AWS landing zone security AWS multi-account architecture 2026

Black Hat Giveaway

Win a $2,495 Black Hat pass.

Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.

AWS Organizations Multi-Account Security Architecture: SCPs, Centralized Logging, and Security Hub

Foundational account structure

Service Control Policies: the highest-leverage security control

Centralized CloudTrail: organization-level trail configuration

Security Hub and GuardDuty at organization scale

The bottom line

Frequently asked questions

What is the difference between AWS Control Tower and manual Organizations setup?

How do SCPs interact with IAM policies?

What is the cost of running Security Hub and GuardDuty organization-wide?

Sources & references

Critical CVE Reference Card 2025–2026

Ransomware Incident Response Playbook

Get threat intel before your inbox does.

Subscribe to enter the giveaway