Controlling Access in AWS Organizations

Three mechanisms control access across a multi-account estate, and they operate at different points. Service control policies set the outer bound of what an account may do. AWS Config detects what was actually created. IAM Identity Center decides who reaches which account, as whom.

Service control policies (SCPs)

An SCP is an organisation policy that sets the maximum available permissions for the IAM users and roles in the accounts it applies to.

• Attached at three levels: the organisation root, an organizational unit, or an individual account (attaching to an individual account is discouraged — create an OU instead)
• Written in IAM policy syntax
• Never grants permissions. An SCP only limits them. Permissions still have to be granted by an identity-based or resource-based policy.
• Effects are inherited by every account below the attachment point, and an account has only the permissions permitted by every SCP above it

Two exceptions that decide architecture

• SCPs do not affect users or roles in the management account. They apply only to member accounts — including a member account designated as a delegated administrator. This is the reason the management account should hold no workloads: a guardrail that covers the rest of the organisation does not cover it.
• SCPs do not affect service-linked roles. Service-linked roles let AWS services integrate with Organizations and cannot be restricted by an SCP.

A handful of other tasks are also outside SCP control, including registering for the Enterprise Support plan as the root user and providing trusted signer functionality for CloudFront private content.

Deny lists and allow lists

Deny lists start from FullAWSAccess and explicitly deny particular actions. Everything not denied remains available, subject to IAM. This is the practical default: incremental, low-risk, and easy to troubleshoot.

Allow lists replace FullAWSAccess and permit only what is listed. Everything else is implicitly denied. Stronger, and considerably harder to maintain — a service the organisation starts using is blocked until someone updates the policy.

Do not detach the FullAWSAccess policy without putting a replacement allow statement in place, or every action from member accounts fails.

See SCP implementation types for worked examples of both.

Resource control policies (RCPs)

RCPs are the second organisation policy type for permissions. Where an SCP bounds what the principals in an account may do, an RCP bounds what may be done to the resources in an account — including by principals from outside the organisation, which is precisely the case an SCP cannot reach.

Effective permissions

An action succeeds only when all of the following hold:

1. An identity-based policy (or a resource-based policy) allows it.
2. No applicable SCP denies it.
3. No applicable RCP denies it.
4. No permissions boundary or session policy in play denies it.

Effective permissions are the intersection. Nothing in the list grants anything on its own except the identity-based and resource-based policies.

AWS Config

AWS Config is the detective control alongside the preventive ones.

• Records the configuration of resources and every change to them, giving a history per resource
• Evaluates resources against managed and custom rules — encryption at rest, public access, required tags, approved AMIs
• Reports which specific resources are non-compliant, not merely that something is non-compliant
• Triggers remediation through AWS Systems Manager Automation documents
• Aggregates across accounts and Regions into an organisation-wide view

Config is also a prerequisite for most AWS Security Hub CSPM controls and for AWS Firewall Manager, so it is usually the first thing enabled in a new landing zone.

IAM Identity Center

IAM Identity Center (formerly AWS Single Sign-On) is how people reach the accounts.

• Maps users and groups from an identity provider to roles in member accounts
• Integrates with SAML 2.0 identity providers such as Microsoft Entra ID and Okta, with an Active Directory identity source, or acts as a standalone directory
• Permission sets define the access level; assigning a group and a permission set to an account provisions a corresponding IAM role there
• One user can hold different permission sets in different accounts — administrator in development, read-only in production — and switches between them from the access portal
• Access keys are replaced by short-lived credentials issued per session

A common arrangement: an Admins group and a Developers group in the identity provider; AdministratorAccess and PowerUserAccess permission sets in the development account; and only ReadOnlyAccess plus a narrowly scoped deployment permission set in production, with changes there made by the pipeline rather than by people.

Practice

Policies. Attach SCPs at OU level, not to individual accounts. Where two workloads need materially different guardrails, that is a signal to create another OU. Test every SCP in a non-production OU first, and keep them in version control with the rest of the infrastructure.

Access. Use IAM Identity Center for anything a human does. Keep IAM users for the remaining cases that genuinely cannot federate, and treat each one as an exception with an owner and a review date.

Compliance. Enable AWS Config organisation-wide, aggregate it into one account, and act on non-compliance rather than accumulating it. A compliance dashboard nobody clears is indistinguishable from no dashboard.