AWS Organizations, SCPs, and Control Tower: Multi-Account Security Strategy

The AWS account is the strongest isolation boundary the platform offers, because access between accounts is denied by default. Every other boundary in AWS — IAM policies, VPCs, permissions boundaries, attribute-based access control — operates inside an account and can be widened by anyone who gains broad IAM rights there. Across accounts, no principal in one account can touch anything in another unless access is explicitly granted (a resource policy or role trust policy on one side, an identity policy on the other). That default-deny property is why "put it in a separate account" is a security answer, not just an organizational one.

Separate accounts contain blast radius. If a developer in a development account escalates their own IAM permissions, those permissions still stop at the account edge; production in another account is untouched. Separating environments by VPC, permissions boundary or tag inside one account does not give that guarantee — a principal who can edit IAM in the account can undo all of them. Separate accounts also give clean service quotas and billing lines and, most importantly for this domain, a clean place to attach organization policies: SCPs, RCPs and management policies attach to accounts and OUs, so your account structure is your policy structure.

The boundary is not magic, though. It holds against misconfiguration of IAM inside the account, but a resource policy or role trust policy that grants another account access opens it deliberately — and a misconfigured one opens it by mistake. That is the gap RCPs close (below).

This thinking is formalized as a landing zone: a pre-configured, secure, multi-account environment with identity, logging and guardrails established before the first workload lands. You can hand-build one with AWS Organizations, or let AWS Control Tower build and operate one for you. Either way, reason about where a workload lives before what IAM policy it gets.

AWS's published guidance for organizing an environment converges on a recognizable OU layout:

• Security OU — the accounts your security team owns. The two canonical members: the log-archive account, holding the S3 buckets that receive the organization CloudTrail trail, AWS Config history and often VPC Flow Logs — write-restricted storage that workload teams and the people who run security tooling cannot alter; and the audit account (also called the security-tooling account), which is the delegated administrator for GuardDuty, AWS Security Hub CSPM, Detective, Macie and Inspector, and where security analysts hold their cross-account read roles.
• Workloads OU — production and non-production application accounts, often split into Prod and SDLC child OUs so production-only guardrails can attach at the OU level.
• Sandbox OU — experimentation accounts with no path to production data, typically fenced by the most restrictive SCPs (Region limits, service allow-lists, spend controls).
• Suspended OU — a quarantine parking spot built and tested before any incident. Moving a compromised or decommissioned account here applies a deny-almost-everything SCP within minutes, without changing any role, policy or resource inside the account, so the evidence stays exactly as found. The SCP usually exempts one incident-response role (see the SCP patterns below).

Two design rules follow. First, group accounts by function and policy needs, not by org chart — OUs exist so policies inherit sensibly. Second, keep the Security OU accounts free of workloads and keep their duties apart: the log archive stores evidence, the audit account runs tooling, and administrators of the tooling get no write access to the log archive. Organization logs go to the log-archive account — never to the management account or a workload account.

The management account must be kept nearly empty because no SCP or RCP applies to it — not even one attached to the organization root. Its users and roles, and its resources, are outside every guardrail you write. It also controls billing, can close member accounts and owns the organization. The discipline AWS recommends: run no workloads in it, limit human access to a small, audited group, and move every function that can be moved out of it.

The mechanism for moving functions out is delegated administration. A service is first given trusted access to Organizations (so it can operate across the organization); you then register a member account as its delegated administrator, from which the service is centrally managed. GuardDuty, AWS Security Hub CSPM, AWS Config, Macie, Inspector, Detective, IAM Access Analyzer, Firewall Manager, CloudFormation StackSets and IAM (for centralized root access) all support it; the standard pattern is to delegate the security services to the audit account and turn on auto-enable, so accounts that join later are covered with no manual step.

Delegation is often Regional. GuardDuty is the clearest case: the delegated administrator and its auto-enable setting are configured per Region, AWS recommends the same delegated administrator account in every Region, and in a Region where you never designated it, accounts are not auto-enabled and none of their findings reach the delegated administrator (an account that enabled GuardDuty on its own still sees its findings locally). When the central team sees no findings from a new Region, look for a missing per-Region designation before anything else. Security Hub CSPM adds cross-Region aggregation and central configuration on top of its own Regional enablement.

Organizations itself can be delegated too. A resource-based delegation policy, attached in the management account, lets a named member account create, attach and manage organization policies (SCPs, RCPs, tag policies and other policy types). This keeps day-to-day policy work out of the management account, in line with keeping that account's use to a minimum.

CloudTrail is the remaining piece. An organization trail, created from the management account or a CloudTrail delegated administrator, logs every member account into one bucket in the log-archive account; member accounts can see the trail but cannot modify or delete it. Pair it with an SCP that protects the logging APIs (next section). (CloudTrail Lake, an alternative query store, closed to new customers on 31 May 2026; existing event data stores keep working, and AWS points new users to CloudWatch.)

A service control policy sets the maximum permissions available to principals in member accounts and never grants anything. A principal still needs an identity policy (or a resource policy) that allows the action; an Allow in an SCP only stops the SCP from filtering that action out. SCPs apply to every IAM user, role and the root user of each member account, and to no principal in the management account. Service-linked roles are not restricted by SCPs.

The evaluation rules that decide scenario questions:

Strategy: every organization starts with FullAWSAccess attached everywhere, and most stay in a deny-list posture — keep FullAWSAccess, layer targeted Deny statements on top. An allow-list posture (replace FullAWSAccess with SCPs that allow only approved services) is tighter but brittle, because the list must be correct at every level; it fits sandbox OUs and highly regulated enclaves. The full IAM evaluation chain belongs to Domain 4.

A handful of SCP patterns cover most of what Task 6.1 asks. Each one is a Deny statement, so it binds every member-account principal, administrators and the root user included.

Region deny

Deny actions when aws:RequestedRegion is not in the approved list. The trap is global services: requests to services such as IAM, Organizations, Route 53, CloudFront, AWS Support and the global STS endpoint are evaluated with us-east-1 as the requested Region, so a plain "deny * outside eu-west-1" breaks them. The fix is to write the statement with NotAction listing those global services, so they are exempt and everything else is denied outside the approved Regions. The two tempting alternatives both fail: adding us-east-1 to the approved list lets workloads run there, and listing the regional services in Action misses every regional service AWS launches later, which would then be unrestricted.

Root-user deny

Deny * when aws:PrincipalArn matches the root user, using StringLike with arn:aws:iam::*:root. The root user's ARN is the account ARN ending in :root; a pattern such as arn:aws:iam::*:user/root matches only an IAM user that happens to be named "root" and leaves the real root user untouched. This SCP stops root credentials being used; it does not remove them (centralized root access does that — see the last section).

Protect the security baseline

Deny cloudtrail:StopLogging, cloudtrail:DeleteTrail, guardduty:DeleteDetector, guardduty:DisassociateFromMasterAccount, config:StopConfigurationRecorder and config:DeleteConfigurationRecorder at the root. When the requirement is "no one in a member account", the Deny carries no condition — a condition that exempts admin roles, for example, would exempt exactly the principals an attacker wants. RCPs cannot do this job: CloudTrail, GuardDuty and AWS Config are not RCP-supported services, and the request comes from your own principals anyway.

Deny leaving the organization

Deny organizations:LeaveOrganization so a compromised member account cannot escape its guardrails by leaving.

Quarantine with an exemption

The Suspended OU's SCP denies *. If an incident-response role must keep working in a quarantined account, write the exception into the Deny statement itself, as a condition that matches every principal except that role (an ARN-negating operator on aws:PrincipalArn, with the role's ARN pattern). Exceptions to an SCP Deny always live inside the Deny: SCPs never grant, so a separate Allow cannot override an explicit Deny.

Resource control policies (RCPs) cap what any caller can do to resources in your member accounts, including principals from accounts you don't own. SCPs constrain only your principals, so they cannot stop an outside attacker from using a mis-shared bucket; an RCP attached at the root, an OU or an account applies to every request against the resource, whoever makes it. Like SCPs, RCPs never grant anything and have no effect on resources in the management account (they do apply to delegated administrator accounts).

Coverage is a documented, growing list of services. RCP support launched with Amazon S3, AWS STS, AWS KMS, Amazon SQS and AWS Secrets Manager and has since extended to many more — for example Amazon DynamoDB, CloudWatch Logs, Amazon ECR, Amazon Cognito, OpenSearch, CloudFront and others. Check the current list in the AWS Organizations User Guide rather than memorizing it. Equally important are the documented exclusions: RCPs do not restrict calls made by service-linked roles, do not apply to AWS managed KMS keys, and do not touch resources in the management account. Services such as CloudTrail, GuardDuty and AWS Config are not covered, so protecting the security baseline stays an SCP job.

The perimeter pattern. An RCP denies access to resources unless aws:PrincipalOrgID equals your organization ID, so even a resource policy that grants Principal: "*" cannot expose data outside the organization. A production perimeter needs one more condition: AWS services that act on your behalf using their own service principals (for example a service delivering logs into your bucket) carry no organization ID, so the Deny also requires BoolIfExists aws:PrincipalIsAWSService = false. Without it the perimeter breaks those integrations. AWS publishes example data-perimeter RCPs; test any RCP on a single account or low OU before attaching it at the root.

Two condition keys look alike and point in opposite directions:

A declarative policy sets a service configuration in every account and Region it covers and keeps it set. That is different from an SCP. An SCP can only deny the API that would change a setting; it does not turn the setting on in accounts that never enabled it, it does not bind service-linked roles, and a new API that changes the same setting would be unaffected until someone adds it to the policy. A declarative policy declares the desired state: the service enforces it for every principal (service-linked roles included), it keeps holding when the service adds new APIs, and you can show blocked users a custom error message, for example pointing to an internal wiki.

For Amazon EC2, EBS and VPC, the supported attributes include:

• EBS snapshot block public access;
• AMI (image) block public access;
• VPC Block Public Access (for example blocking internet-gateway traffic);
• instance metadata service defaults (such as requiring IMDSv2 for new launches);
• serial console access;
• allowed images settings (which AMI providers may be used to launch instances).

AI services opt-out policies answer a different requirement: stop AWS from storing or using content processed by AWS AI services (Amazon Comprehend, Amazon Lex, Amazon Polly, Amazon Transcribe and others) to develop and improve those services. Attached at the root, one policy opts every current and future account out, for all supported services or for named ones.

Organizations has further management policy types in the same declarative family, including tag and backup policies (tag governance is covered with deployment strategy in Task 6.2) and policies that centrally enable and configure security services such as Security Hub, Amazon GuardDuty and Amazon Inspector, as well as Amazon S3 settings.

Most Task 6.1 questions describe an outcome and ask for the control. This chooser maps the outcome to the mechanism:

The verb decides. "Prevent", "block", "make it impossible" means a preventive control; then ask who is constrained — your principals (SCP), any caller against your resources (RCP), or a service setting (declarative policy). "Detect", "audit", "report", "remediate" means AWS Config, which is Task 6.3. An IAM permissions boundary is never the organization-wide answer: it is a per-principal, per-account artifact.

AWS Control Tower builds and operates a landing zone for you: it orchestrates AWS Organizations, IAM Identity Center, CloudTrail and AWS Config to create the Security OU with log-archive and audit accounts, turn on organization-wide logging and apply a baseline of controls. It is not a separate policy engine; it is an opinionated operator of the services above. It can be set up in a new environment or an existing organization.

Its controls (formerly "guardrails") have a behaviour, and each behaviour has an implementation:

Controls also carry guidance: mandatory (always on), strongly recommended and elective. The last two are the optional controls, enabled per registered OU from the control catalog (console or API). Custom controls — your own SCPs, RCPs, Config rules or CloudFormation resources — are deployed alongside the landing zone, typically with Customizations for Control Tower (CfCT), so they are reapplied as accounts are created or updated.

Governed Regions. Control Tower deploys its baseline and its detective and proactive controls only in the Regions it governs. If workloads start running in a new Region, controls do not reach it until you add the Region to the landing zone (update the landing zone) and then re-register the OUs — or update the accounts — so the baseline and controls are deployed there. Control Tower also offers a Region deny setting for Regions you do not govern.

An organization that already has accounts adopts Control Tower by registering OUs and enrolling accounts. Registration is the OU-level operation: Control Tower takes over governance of the OU and enrolls every account in it in a single pass, so they all receive the controls enabled on that OU. Enrollment is the same thing for one account at a time. Enrollment deploys the Control Tower baseline into the account: AWS Config recording and delivery to the log-archive account, coverage by the landing zone's CloudTrail logging, IAM Identity Center access and the controls of its OU.

Enrollment of an older account fails for predictable reasons:

• The account must have the AWSControlTowerExecution role, trusted by the management account, which Control Tower uses to deploy the baseline. Accounts created through Organizations long ago often lack it.
• Existing AWS Config resources (a configuration recorder and delivery channel in the account's own Regions) conflict with the recorder enrollment deploys. Remove them, or follow Control Tower's documented procedure for enrolling accounts with existing AWS Config resources.

Enrollment adds the baseline alongside what the account already runs rather than rebuilding it, so when enrollment fails, check the documented prerequisites first.

New accounts should be vended already governed. Three tools are easy to confuse:

Plain Organizations fits a scenario that wants bespoke policy control with little managed tooling; Control Tower fits one that wants a standardized, quickly established and continuously governed landing zone.

Centralized root access removes long-term root credentials from member accounts and replaces them with short-lived, task-scoped root sessions run from the organization. It is configured in IAM:

1. Enable trusted access for IAM in Organizations, then turn on the two capabilities: root credentials management (audit and delete member root passwords, access keys, signing certificates and MFA devices; accounts created afterwards have no root credentials) and privileged root actions in member accounts.
2. Optionally register an IAM delegated administrator (often the audit account) so the work is done outside the management account.
3. Delete the existing member root credentials.

For the rare action that needs root, an IAM role in the management account or the IAM delegated administrator calls sts:AssumeRoot — against a Regional STS endpoint (the global endpoint is not supported) — naming the target member account and an AWS managed task policy that scopes the short session. Root user credentials cannot call it.

The unlock tasks exist because a resource policy written as a blanket Deny has no exception for administrators: every IAM role in the account, however privileged (the cross-account admin role Organizations creates included), is locked out of the bucket or queue, and only the owning account's root user can delete such a policy. Limit who can do what with the sts:TaskPolicyArn condition key — for example allow incident engineers sts:AssumeRoot only with the two unlock task policies. IAMCreateRootUserPassword restores a long-term root password, so it is not a break-glass substitute when the requirement is that member accounts hold no root credentials.

The management account root user is outside all of this. Centralized root access manages member accounts only, and SCPs do not reach the management account. Protect that root user directly: a strong password, MFA with more than one device (IAM supports several per user) held by different custodians so one lost device is not a lockout, no access keys, and an alert on every root sign-in — for example an EventBridge rule on CloudTrail ConsoleLogin events whose identity type is Root, sent to the security team and investigated.

Break-glass is the documented emergency path for when normal access (IAM Identity Center or federation) is unavailable: a small number of tightly held credentials or roles, MFA-protected, whose use raises an alarm, is reviewed afterwards and ends with credential rotation. With centralized root access, member-account root tasks go through AssumeRoot instead, so break-glass root credentials remain only where they still exist — chiefly the management account. Day-to-day workforce access belongs to IAM Identity Center permission sets (covered in Domain 4).

A regulated financial-services company gives you requirements: workloads isolated per environment, logs tamper-proof for seven years, no data-plane activity outside two approved Regions, security tooling that application admins cannot disable, standardized new accounts and no long-term root credentials in member accounts. Each one maps to a Task 6.1 control:

• A Control Tower landing zone with Security, Workloads (Prod/SDLC), Sandbox and Suspended OUs, both approved Regions governed.
• Organization CloudTrail delivering to the log-archive account's locked-down bucket.
• A Region-deny SCP with a NotAction global-service exemption on the organization root (the management account is exempt from it, so it stays workload-free and access-restricted).
• The protect-the-baseline SCP and a deny on leaving the organization.
• GuardDuty, Security Hub CSPM, AWS Config, Macie and Inspector delegated to the audit account with auto-enable, in every Region in use.
• An RCP perimeter on aws:PrincipalOrgID with the AWS-service exception.
• Declarative policies for EBS snapshot and AMI block public access.
• Account Factory for new accounts; existing accounts enrolled by registering their OUs.
• Centralized root access with member root credentials deleted, unlock tasks delegated to the audit account, and the management account root user protected with multiple MFA devices and sign-in alerting.