Large AWS customers rarely run everything in one account. Separate accounts give hard boundaries for security, billing and service quotas: a mistake or breach in a development account cannot touch production, and each team's spending is easy to see. AWS Organizations is the service that groups accounts together. One management account creates or invites member accounts, arranges them into organizational units (OUs) such as Security, Infrastructure, Production and Sandbox, and pays one consolidated bill, which also pools usage for volume discounts. Service control policies (SCPs) are Organizations policies attached to the root, an OU or an account. They define the maximum permissions available to IAM users and roles in the affected member accounts, including each account's root user. SCPs never grant permissions; an identity still needs an IAM policy that allows the action. They are guardrails: deny leaving the organization, deny disabling CloudTrail or GuardDuty, or deny any action outside approved Regions using the aws:RequestedRegion condition. SCPs attached higher in the tree are inherited, so an action must be allowed at every level from the root down to the account. SCPs do not affect the management account, which is one reason AWS recommends running no workloads there, and they do not restrict service-linked roles. A newer, related policy type, resource control policies (RCPs), sets maximum permissions on resources such as S3 buckets and KMS keys, which helps build a data perimeter that also applies to principals outside your organization.
AWS IAM Identity Center (the successor to AWS Single Sign-On) is the recommended way for people to sign in across many accounts. You connect an identity source, such as the built-in Identity Center directory, Active Directory, or an external identity provider (IdP) like Okta or Microsoft Entra ID, often with automatic user provisioning through the System for Cross-domain Identity Management (SCIM) standard. You then define permission sets. A permission set is a template of policies; when you assign a user or group a permission set on an account, Identity Center creates a matching role in that account. Users sign in once to the access portal, pick an account and role, and receive temporary credentials. There are no IAM users to create in each account.
For workloads and automation, cross-account access uses IAM roles. In the target account you create a role whose trust policy names the source account, or a specific role there, as the principal. In the source account, the calling identity needs permission for sts:AssumeRole on that role's ARN. Both sides must agree. When a third party such as a monitoring vendor assumes a role in your account, you add an external ID condition to the trust policy to prevent the confused deputy problem, where the vendor is tricked into using its access to your account on behalf of another customer.
aws sts assume-role \
--role-arn arn:aws:iam::222233334444:role/AuditReadOnly \
--role-session-name audit-runOther multi-account tools appear in questions. AWS Control Tower sets up and governs a landing zone: a recommended OU structure, a log archive account, an audit account, centralized CloudTrail and preventive and detective controls built from SCPs and AWS Config rules. Account Factory in Control Tower creates new accounts that already meet the baseline. AWS Resource Access Manager (RAM) shares resources such as VPC subnets, Transit Gateways or Route 53 Resolver rules across accounts. Delegated administrator lets a member account, typically a security tooling account, run a service such as GuardDuty, Security Hub or AWS Config aggregation for the whole organization instead of the management account.
Consider a worked example. A company must guarantee that no one in its workload accounts can create resources outside two approved Regions, and its auditors must read CloudTrail logs in every account. It uses Control Tower to create the landing zone, attaches an SCP to the Workloads OU that denies all actions when aws:RequestedRegion is not one of the two approved Regions, with exceptions for global services such as IAM, and assigns the auditors a read-only permission set through IAM Identity Center. Even an administrator in a member account cannot create an instance in a third Region, and the auditors never need separate IAM users.
Common mistakes: expecting an SCP to grant access; forgetting that SCPs do not apply to the management account; creating IAM users in every account for people instead of using Identity Center; and omitting the external ID for third-party roles. Another is running workloads in the management account, where SCP guardrails cannot reach them.
Exam questions often describe a governance goal. 'Central guardrail across all accounts' or 'prevent even administrators from' points to an SCP. 'Single sign-on for employees across many accounts' points to IAM Identity Center. 'Application in account A must act in account B' points to a cross-account role with a trust policy, and 'third-party vendor access' adds an external ID. 'Quickly set up a governed multi-account environment' points to Control Tower.
Key terms
- AWS Organizations
- The service that groups AWS accounts for central management, policies and consolidated billing.
- Organizational unit (OU)
- A container of accounts inside AWS Organizations to which policies such as SCPs can be attached.
- Service control policy (SCP)
- An Organizations policy that sets the maximum permissions for identities in member accounts; it never grants access.
- Permission set
- An IAM Identity Center template of policies that becomes a role in each account it is assigned to.
- External ID
- A secret value required in a cross-account role's trust policy to protect against the confused deputy problem.
- AWS Control Tower
- A service that sets up and governs a multi-account landing zone with baseline accounts and controls.
A payments company acquires a startup with 12 AWS accounts. It invites them into its organization, places them in a Workloads OU that inherits SCPs denying CloudTrail changes and unapproved Regions, connects IAM Identity Center to its corporate IdP so engineers sign in with their existing accounts, and makes the security account the delegated administrator for GuardDuty so findings from all 12 accounts arrive in one place.
Check yourself
An SCP allows only EC2 and S3 actions. A user in a member account has AdministratorAccess. Can the user create a DynamoDB table?
No. The SCP sets the maximum available permissions, so actions outside EC2 and S3 are blocked regardless of the IAM policy.
What two things are required for an identity in account A to assume a role in account B?
The role in account B must trust account A (or that identity) in its trust policy, and the identity in account A must be allowed sts:AssumeRole on the role's ARN.
Why should a vendor's cross-account role include an external ID condition?
It prevents the confused deputy problem, where another customer of the vendor could trick the vendor into using its access to your account.
Does an SCP restrict actions performed in the management account?
No. SCPs do not affect the management account, which is why workloads should run in member accounts.