Multi-account strategy
Designing an AWS Organizations OU structure for security, running Control Tower controls, delegating security services and centrally managing root access for member accounts.
Exam tasks: 6.1 (skills 6.1.1 Organizations, 6.1.2 Control Tower and its controls, 6.1.3 organization policies, 6.1.4 delegated administrators, 6.1.5 root user credentials)
The decision: which account boundary should isolate a workload or a team, which account should run each security service, and which guardrail (preventive, proactive or detective) should stop or catch a bad configuration before a human has to?
An OU structure built for security
An AWS account is the strongest isolation boundary AWS offers: separate IAM, separate quotas, separate blast radius. OUs group accounts that need the same policies, not the same org chart.
| OU | What goes in it | Typical guardrails |
|---|---|---|
| Security | Log archive and security tooling (Control Tower calls it Audit) accounts | Deny changes to logging, deny leaving the org, very few human principals |
| Infrastructure | Shared networking, shared services, identity | Only the platform team can change routing |
| Workloads (prod and non-prod) | Application accounts, one per workload per environment | Region deny, encryption required, no public S3 |
| Sandbox | Experiments, disconnected from corporate networks | Spend limits, no Direct Connect or peering, broad service access |
| Policy staging | Test accounts for new SCPs before they hit prod | Mirror of the prod policy set plus the change |
| Suspended | Accounts being decommissioned or quarantined | Deny-all SCP except a break-glass role |
- Log archive account: receives the organization trail, Config snapshots and other logs. Almost nobody signs in. S3 Object Lock and a bucket policy that only accepts writes from the org stop tampering. See Logging strategy.
- Security tooling account: the delegated administrator for security services, where the security team reads findings and runs response automation. It has read access into other accounts, not the other way round.
- Don't nest deeply for the sake of it. Every SCP layer is another place to debug an unexpected deny.
Exam signal
"Isolate the blast radius", "separate billing", "different compliance scope" or "a team must not be able to affect another team's resources" all point to separate accounts, not separate VPCs or IAM paths in a shared account.
Organization policies at a glance
Organizations only offers policies once all features are enabled (not just consolidated billing). The detail on SCP and RCP evaluation lives in Organization policies.
| Policy type | Does what | Security use |
|---|---|---|
| SCP | Caps what principals in member accounts can do | Region deny, protect CloudTrail and GuardDuty, block leaving the org |
| RCP | Caps what can be done to resources in member accounts, by anyone | Block access from outside the org to S3, KMS, SQS, Secrets Manager and STS |
| Declarative policy | Sets and holds a service configuration, such as EC2 | Block public AMI and snapshot sharing, require IMDSv2, VPC block public access |
| Tag policy | Standardizes tag keys, value case and allowed values | Consistent data-classification and cost-center tags for ABAC and reporting |
| Backup policy | Pushes AWS Backup plans to accounts | Guaranteed backup schedule and vault for every prod account |
| AI services opt-out policy | Stops AWS AI services storing or using your content to improve the service | Data residency and privacy commitments |
- Tag policies report non-compliant tags and can block non-compliant tagging operations on the resource
types you list. They don't force someone to add a tag at all. To require a tag on creation, use an SCP that denies
the create call when
aws:RequestTag/<key>is null. - Backup policies deploy plans, but the vault, KMS key and IAM role they reference must already exist in each account (StackSets is the usual way to put them there).
SCPs and the management account
SCPs and RCPs never apply to the management account, and SCPs don't limit service-linked roles. A question that needs a restriction on "every account, including the management account" can't be solved with an SCP alone, so keep workloads out of that account.
AWS Control Tower
Control Tower builds and runs a landing zone: a multi-account environment with Organizations, IAM Identity Center, an organization CloudTrail, Config and a set of controls wired together.
- Shared accounts: management, log archive and audit (the security tooling account), with the latter two in a Security OU.
- Account Factory creates new accounts in a chosen OU with the baseline already applied. It's exposed as a Service Catalog product. Account Factory Customization (AFC) adds your own blueprint (a CloudFormation or Terraform template) when an account is created.
- Account Factory for Terraform (AFT) is a GitOps pipeline: you commit an account request to a repository, and AFT creates the account and applies global and per-account Terraform customizations.
- Existing environments: you can set up Control Tower on an existing organization, then register existing OUs and enroll existing accounts. You can also use Control Tower controls on OUs without a full landing zone.
- Drift: changing Control Tower resources directly in Organizations (moving an account, editing a Control Tower SCP) causes landing zone drift that you repair from the console.
Control behaviours
| Behaviour | Built on | When it acts | Status values |
|---|---|---|---|
| Preventive | SCPs, RCPs, declarative policies | Blocks the API call | Enforced or not enabled |
| Proactive | CloudFormation Hooks | Checks resources before CloudFormation provisions them. Fails the stack if non-compliant | Pass, fail, skip |
| Detective | AWS Config rules | Flags resources that are already non-compliant | Clear, in violation, not enabled |
- Guidance categories are mandatory (protect Control Tower's own resources), strongly recommended and elective. The catalog is also organized by framework, so you can enable every control that maps to, say, NIST 800-53 on one OU.
- Controls apply to an OU, so every account in that OU gets them. You can't enable a control on one account.
- Proactive controls only see resources deployed through CloudFormation (or tools that use it, such as CDK). Console clicks bypass them, which is why you pair them with a preventive or detective control.
- Custom controls: write your own SCP, Config rule or Hook and deploy it with Customizations for Control Tower, AFT or StackSets.
Legacy: use controls instead
Control Tower used to call controls "guardrails". Older questions and blogs use the term. It means the same thing.
Exam signal
"Stop the resource being created at all" means preventive. "Stop it being created through our IaC pipeline, with a clear error before deployment" means proactive. "Tell us which existing resources break the rule" means detective.
Delegated administrators
Most security services let the management account delegate administration to a member account. The delegated admin can then enable the service in all accounts, auto-enable it for new accounts and see every finding.
- Services you'll see on the exam: GuardDuty, Security Hub and Security Hub CSPM, Amazon Inspector, Macie, Detective, IAM Access Analyzer, AWS Config (rules and conformance packs), Firewall Manager, CloudTrail (for organization trails and Lake), Audit Manager, CloudFormation StackSets, IAM (for root access management).
- Delegate to the security tooling account. One account for all security services keeps the view in one place.
- Turn on auto-enable for new members so a fresh account from Account Factory is covered from its first hour.
- Many services are Regional, so the delegated admin must be designated (and auto-enable set) in every Region you operate in. Cross-Region aggregation then gives one pane of glass.
Enabling it per account
A script that loops over accounts and turns GuardDuty or Security Hub on is a distractor. It misses accounts created later. The organization integration with auto-enable is the answer.
Root user control
Every member account has a root user that SCPs can't fully restrict. Centralized root access management removes the problem.
- Enable it in IAM (it needs trusted access for IAM in Organizations). Then you can delete root credentials in member accounts: password, access keys, signing certificates and MFA. New accounts are created with no root credentials at all.
- Privileged tasks run through
sts:AssumeRootfrom the management account or the IAM delegated admin, scoped by an AWS managed task policy (for exampleS3UnlockBucketPolicyorIAMDeleteRootUserCredentials). Sessions last up to 900 seconds and must use a Regional STS endpoint. - You can't call
AssumeRootwith root credentials, and you can restrict which task policies a principal may use with thests:TaskPolicyArncondition key. - If a task really needs a member account's root user (a rare billing task, say), run Allow password recovery, do the task, then delete the credentials again.
Break-glass access
- Keep the management account root with a strong password and MFA (preferably two hardware or passkey
devices), stored with dual control. Watch for any root sign-in with an EventBridge rule on CloudTrail
ConsoleLoginevents where the user identity type isRoot. - Keep a small number of break-glass IAM roles or Identity Center users outside your normal IdP, so an IdP outage doesn't lock you out. Alarm on every use.
- Test the procedure on a schedule. A break-glass path nobody has used in two years usually fails when it's needed.
sts:AssumeRoot privileged task session.Scenarios
Centralized root access management deletes existing root credentials, creates new accounts without them, and gives short, task-scoped privileged sessions for the few jobs that need root. An SCP can block root actions but leaves the credentials in place and would also block the bucket-policy fix. Storing passwords keeps long-term credentials alive, which is the problem. Control Tower enrollment doesn't delete root credentials on its own.
The proactive control runs as a CloudFormation Hook and fails the stack before RDS is created. The detective control, a Config rule, catches databases that already exist or bypassed CloudFormation. Denying all RDS creation stops the business, a tag says nothing about real encryption, and a conformance pack in the management account doesn't evaluate workload accounts.
Delegated administration moves day-to-day work out of the management account, and auto-enable covers accounts created later. Per-account roles and StackSet reruns work, but need ongoing effort and leave gaps between runs. Running the services from the management account is exactly what the requirement forbids.
Further reading
Domain 6 · Security foundations and governance
14% of the exam. Building the account structure, deployment guardrails and compliance checks that every other security control sits on.
Secure and consistent deployment
Hardening CloudFormation templates, policy as code with Guard and Hooks, drift detection, StackSets, Service Catalog and AWS RAM for sharing, Firewall Manager for central network policy, and tagging strategy.