Policy Inheritance

Policy inheritance connects governance rules to an organizational hierarchy. A policy attached to a parent scope can affect all applicable descendants, including descendants created or moved there later. Typical scopes include an organization, organizational unit, folder, account, subscription, or project. This lets a platform team establish a common baseline while delegating day-to-day administration to workload teams.

Inheritance does not have one universal evaluation algorithm. An authorization policy might restrict permissions, a configuration policy might combine settings, and another policy might allow a child to replace an inherited value. Engineers must identify the policy type, its attachment scope, supported targets, conflict rules, and exceptions before predicting the effective outcome. A policy attached directly to a child is not automatically more authoritative than an inherited policy.

In AWS Organizations, policies can be attached to the organization root, organizational units, or accounts. An account inherits applicable policies along its path through the hierarchy. Organization policy types must be enabled before use, and authorization policies such as service control policies require an organization operating with all features enabled. Organizational units are governance boundaries, not IAM identities, and moving an account between them can change its effective controls without changing its IAM policies.

Service control policies, or SCPs, establish the maximum permissions available to principals in member accounts. They do not grant permissions. For an action to pass SCP evaluation, it must be allowed at every level from the root through the account, and an applicable explicit deny at any level blocks it. Allows from multiple SCPs attached at the same level combine, but a child-level allow cannot overcome a missing parent-level allow or an inherited explicit deny. For example, an inherited deny on disabling audit logging still blocks an account administrator whose IAM policy allows that action. SCPs do not restrict principals in the management account and do not affect service-linked roles.

Resource control policies, or RCPs, apply a complementary boundary to resources in member accounts for supported services. They constrain access to those resources, including access by external principals, rather than defining the permissions of the requesting account's identities. An inherited RCP can therefore restrict external access to supported storage resources even when a resource policy permits it. RCPs do not grant access, do not cover every resource type, and do not apply to resources in the management account.

Management policies use different inheritance semantics. AI services opt-out policies control whether supported AI services may use specified customer content for service improvement; they do not deny permission to invoke those services. Parent and child settings combine into an effective policy, with inheritance operators controlling which changes descendants may make. An organization-wide opt-out should therefore include appropriate restrictions on child overrides when exceptions are not intended.

Declarative policies specify supported service configurations rather than evaluating individual API requests as permission boundaries. For example, an organization can enforce supported EC2 public-access settings through an inherited configuration policy. These policies also use policy-specific inheritance rules and can restrict child modifications. An SCP that denies a configuration-changing API and a declarative policy that establishes the configuration are different mechanisms, even when they support the same governance objective.

The main benefit is consistent control with less duplicated configuration. The trade-off is a larger potential impact from mistakes: a root-level change can affect many workloads, and an account move can introduce unexpected restrictions. Test changes in a representative organizational unit, inspect effective policies where supported, allow for propagation, and validate both permitted and prohibited operations. Place mandatory controls high enough to cover their intended population, place optional restrictions lower down, and design exceptions explicitly rather than assuming a local administrator can override inherited rules.