Multi-account governance
Separate workloads into accounts and govern them centrally with guardrails. Part of Domain 1: Design Secure Architectures, 30% of the scored content.
Groups accounts into a hierarchy under one management account, with central policies, consolidated billing and service integrations.
Key points
- Management account: creates the organization, invites and removes accounts, attaches policies and pays every charge. Keep workloads out of it, because SCPs do not restrict it.
- OUs: group accounts by workload or environment. The hierarchy can be 5 levels deep below the root, and policies are inherited downward.
- Feature sets: all features (recommended, required for SCPs, RCPs and declarative policies) or consolidated billing only.
- Consolidated billing: one bill, combined usage for volume discounts, shared Reserved Instance discounts and Savings Plans, at no extra fee.
- Membership: an account belongs to only one organization at a time.
On the exam
"Isolate environments and apply controls per group of accounts" -> separate accounts in OUs with policies attached to each OU. IAM alone inside one account gives no central guardrail.
SCPs and RCPs
Service control policies and resource control policies
Authorization policies set the maximum available permissions in member accounts. SCPs cap principals, RCPs cap resources, and neither grants anything.
Key points
- SCP: limits IAM users and roles in member accounts, including the member root user. It does not affect the management account or service-linked roles.
- FullAWSAccess: attached by default. A deny list keeps it and adds
Denystatements. Removing it without a replacement makes every action fail. - Inheritance: an account has only what every parent above it allows, from the root down to the account.
- RCP: limits what anyone, including principals outside the organization, can do on resources of supported services such as S3, KMS, SQS, Secrets Manager, DynamoDB and STS.
- Data perimeter: an RCP keeps resources reachable only by identities of your organization, and an SCP limits services or Regions that your principals can use.
On the exam
"Stop every account in the OU from disabling CloudTrail or using unapproved Regions, even administrators" -> SCP. "Block principals outside the organization from our S3 buckets in all accounts" -> RCP.
SCP vs RCP
| Aspect | SCP and RCP |
|---|---|
| Scope |
|
| Grants access | Neither. Both are guardrails only |
| Management account | Not affected by either |
| Attach limit |
|
| Maximum size |
|
Sets up and governs a multi-account landing zone that follows AWS best practices, orchestrating Organizations, IAM Identity Center and Service Catalog.
Key points
- Landing zone: a well-architected multi-account environment. Earlier versions create a Security OU with the Log Archive and Audit accounts, and landing zone 4.0 lets you define your own structure.
- Account Factory: a configurable template that provisions new accounts with pre-approved settings and controls.
- Preventive controls: implemented with SCPs and RCPs, they block actions before they happen.
- Detective controls: implemented with AWS Config rules, they flag noncompliant resources.
- Proactive controls: implemented with CloudFormation hooks, they stop noncompliant resources before provisioning.
- Guidance: controls are mandatory (always on), strongly recommended or elective.
On the exam
"Quickly set up a governed multi-account environment with guardrails and account vending" -> Control Tower. Assembling the same with Organizations by hand means more operational overhead.
AWS RAM
AWS Resource Access Manager
Share resources you own with other accounts, OUs or the whole organization instead of duplicating them in every account.
Key points
- Shareable examples: VPC subnets, transit gateways, Route 53 Resolver rules, prefix lists, License Manager configurations, Network Firewall policies, Aurora DB clusters and Private CA.
- VPC sharing: the owner shares subnets with participants in the same organization. Participants create their own resources there but cannot see or change resources of others.
- Invitations: once sharing with Organizations is enabled, accounts in the organization need no invitation. Accounts outside it must accept one.
- Managed permissions: define what consuming accounts can do with the shared resource. Their own IAM policies and SCPs still apply.
- Cost: AWS RAM itself has no charge. The shared resource is billed as usual.
On the exam
"Many accounts must place workloads in a centrally managed network" -> share subnets or a transit gateway with AWS RAM. Recreating the resource in every account is the distractor.
Register a member account to administer an integrated service for the whole organization, keeping daily work out of the management account.
Key points
- Why: SCPs do not restrict the management account, so security tooling should run from a dedicated member account.
- Security services: GuardDuty, Security Hub CSPM, Macie, Inspector, Detective, Firewall Manager, IAM Access Analyzer and AWS Config support a delegated administrator.
- Trusted access: lets a service act across all accounts, for example an organization trail in CloudTrail or StackSets with service-managed permissions.
- Limits: only the management account creates or invites accounts. A delegated administrator cannot.
- Guardrails still apply: a delegated administrator is a member account, so SCPs and RCPs affect it.
On the exam
"A central security team must manage GuardDuty findings for all accounts without using the management account" -> delegated administrator for GuardDuty in the security account.
Organization policies that configure services centrally instead of limiting permissions. Unlike SCPs, they also apply to the management account.
Key points
- Tag policies: standardize tag keys, values and case. Enforcement blocks noncompliant tagging operations on chosen resource types, but untagged resources are not evaluated.
- Tag compliance: AWS Resource Groups reports noncompliant tags, and the management account sees every account.
- Backup policies: apply backup plans to resources across the accounts of the organization.
- Amazon EC2 policies: declare and enforce EC2 configurations at scale, kept in place even when the service adds new features or APIs.
- AI services opt-out policies: control data collection by AWS AI services for every account.
On the exam
"Enforce a consistent CostCenter tag format across all accounts" -> tag policy. Remember that tag policies do not flag resources that have no tags at all.