Multi-account governance
Structuring an AWS organization with OUs, guardrails from SCPs, RCPs and Control Tower, and sharing or deploying resources across accounts with RAM, StackSets and Service Catalog.
Exam tasks: 1.4 (design a multi-account environment, central governance, account vending, cross-account sharing)
The decision: how do you give each team its own accounts while one central team sets the rules, vends new accounts and shares common infrastructure, without logging in to each account?
Choosing a tool
AWS Organizations basics
- Management account: creates the organization, pays the bill and owns policies. Keep workloads and people out of it, because SCPs and RCPs don't apply to it.
- All features mode is required for SCPs, RCPs, tag policies and delegated admins. "Consolidated billing only" mode gives you just the shared bill.
- OUs group accounts by function or policy, not by org chart. They nest up to 5 levels below the root.
- Delegated administrator: register a member account to run an org-wide service (GuardDuty, Security Hub, Config, StackSets, IAM Identity Center, Firewall Manager, Backup and more). This keeps daily admin work out of the management account.
Policy types
| Policy | Applies to | Use it for |
|---|---|---|
| Service control policy (SCP) | IAM users and roles in member accounts, including the root user | Maximum permissions: deny Regions, protect security services, block leaving the org |
| Resource control policy (RCP) | Resources in member accounts, for supported services such as S3, STS, KMS, SQS and Secrets Manager | Data perimeter: nobody outside the org reaches our buckets and keys, whatever the bucket policy says |
| Declarative policy | Service configuration, currently EC2-related settings | Enforce a setting such as IMDSv2 or blocking public AMI sharing, even as new APIs appear |
| Tag policy | Tag keys and values on supported resources | Consistent keys, capitalization and allowed values |
| Backup policy | AWS Backup plans | Org-wide backup plans that account admins can't weaken |
| AI services opt-out policy | AI services such as Rekognition and Lex | Stop AWS storing or using content to improve services |
SCPs
- SCPs never grant permissions. A request is allowed only if the SCPs at every level (root, each OU, the account) and the IAM policy allow it.
- They don't affect the management account, service-linked roles, or principals from other accounts that access your resources through resource policies. That last gap is what RCPs close.
FullAWSAccessis attached everywhere by default.
Keep FullAWSAccess attached and add SCPs with explicit Deny statements, for example:
- Deny every Region except
eu-west-1andeu-central-1, with an exception for global services. - Deny
cloudtrail:StopLogging,guardduty:DeleteDetectorandorganizations:LeaveOrganization. - Deny
ec2:RunInstancesunless the request has aCostCentertag.
New services are allowed automatically. Less maintenance, and the usual exam answer.
An SCP to fix a user's access
If an SCP denies an action, no IAM policy can override it, and if the IAM policy doesn't grant an action, no SCP can add it. Answers that "grant access with an SCP" are always wrong.
Testing SCPs in the management account
An SCP attached to the root doesn't restrict the management account. Test in a policy staging OU with a sandbox account instead.
RCPs
- Attach them like SCPs.
RCPFullAWSAccessis attached by default and can't be detached. - They cap the permissions that resource policies can give, for any caller, including principals from other AWS accounts.
- A typical RCP denies
s3:*unlessaws:PrincipalOrgIDequals your organization ID, with exceptions for AWS service principals. It now doesn't matter if a developer writes a public bucket policy.
Exam signal
"Prevent our users from doing X" is an SCP. "Prevent anyone outside the organization from reaching our S3 data or KMS keys, even if a resource policy allows it" is an RCP. Together they form a data perimeter, often with VPC endpoint policies. See cross-account access.
Tag and backup policies
- Tag policies define allowed keys, capitalization and values. With enforcement turned on for a resource type,
noncompliant tagging operations fail. They don't require a tag to exist: to require a tag at creation, use an
SCP that denies the create call when
aws:RequestTag/CostCenteris null. - Backup policies attach AWS Backup plans to OUs, and the plans are created in each account. See backup automation.
Recommended OU structure
- Security: log archive and security tooling accounts, strict SCPs. See central security and logging.
- Infrastructure: network account (Transit Gateway, IPAM, shared VPCs) and shared services (directory, CI/CD).
- Workloads: prod and non-prod OUs so each gets different SCPs.
- Sandbox: experiments, with spending limits and no connection to the corporate network.
- Policy staging tests policy changes. Suspended holds accounts being closed, with a deny-all SCP.
Control Tower
Control Tower builds and runs a well-architected landing zone on top of Organizations, IAM Identity Center, CloudTrail and Config.
- Creates a Security OU with Log Archive and Audit accounts, an organization trail and central Config.
- Controls (formerly guardrails) come in three behaviours:
| Behaviour | Implemented with | When it acts |
|---|---|---|
| Preventive | SCPs, RCPs, declarative policies | Blocks the API call |
| Detective | AWS Config rules | Reports noncompliance after the fact |
| Proactive | CloudFormation hooks | Blocks a noncompliant resource before CloudFormation provisions it |
- Guidance levels: mandatory, strongly recommended and elective. The Region deny control restricts the organization to the Regions you govern.
- Account Factory vends new accounts with network and baseline settings, through the console or Service Catalog. Account Factory for Terraform (AFT) runs vending and per-account customization as a GitOps pipeline. Account Factory Customization applies blueprints (CloudFormation or Terraform) at vending time.
- Existing accounts and OUs can be enrolled or registered. Control Tower reports drift when someone changes its resources outside Control Tower.
Exam signal
"Set up a new multi-account environment quickly, following best practices, with account vending" is Control Tower. "Vend accounts from a Terraform pipeline" is AFT. Building your own with Organizations APIs and Lambda is rarely the least-effort answer.
Sharing and deploying across accounts
| Need | Tool | Key points |
|---|---|---|
| Many accounts use one resource | AWS RAM | Transit Gateways, subnets (VPC sharing), Route 53 Resolver rules, prefix lists, IPAM pools, License Manager configurations and more. With org sharing turned on, no invitations are needed |
| Same stack in every account and Region | CloudFormation StackSets | Service-managed permissions target OUs and auto-deploy to accounts that join them. Self-managed needs roles you create in each target |
| Teams launch only approved patterns | Service Catalog | Portfolios of products (CloudFormation or Terraform), shared with the organization or OUs |
StackSets, service-managed
- Deploy from the management account or a StackSets delegated administrator. Organizations creates the roles.
- Automatic deployment: an account added to a target OU gets the stack. An account that leaves has its stack deleted or retained, as you choose.
- Stack instances are never deployed to the management account, even if it sits in a targeted OU.
- Control speed and blast radius with maximum concurrent accounts and failure tolerance.
Service Catalog
- A portfolio holds products and constraints. Share it with the organization, an OU or accounts, and the recipients import it and grant access to their own principals.
- A launch constraint names an IAM role that Service Catalog uses to provision. End users need only Service Catalog permissions, not EC2 or RDS permissions.
- Template constraints limit parameter values, such as allowed instance types. TagOptions enforce tags on provisioned products.
RAM for everything
RAM shares a resource that stays in the owner's account. It doesn't copy a baseline into each account. A per-account IAM role, Config rule or VPC is a StackSets job.
Scenarios
A deny-list SCP with a Region condition applies to every member account at once, and a principal ARN exception keeps the break-glass role working. An allow-list SCP would block new services until someone adds them. Permissions boundaries must be deployed in each account and attached to every role, and account admins could remove them. Tag policies govern tag values, not where resources are launched.
Service-managed StackSets target OUs, and automatic deployment adds the stack to any account that joins. RAM can't share IAM roles, and a shared topic would live in another account. A Service Catalog product relies on each owner to launch it. SCPs only restrict permissions and can't create resources.
An RCP limits what resource policies can grant to any caller, including external accounts, so it overrides the mistaken bucket policy. SCPs only restrict principals in your own member accounts, so the partner's principal isn't affected. Access Analyzer would detect the external access but not block it. A tag policy doesn't control access.
Further reading
Disaster recovery
Choosing between backup and restore, pilot light, warm standby and multi-site from an RTO, an RPO and a budget.
Cost visibility
Tagging, cost categories, Cost Explorer, Budgets, Data Exports, anomaly detection and rightsizing tools for seeing and controlling spend across an organization.