Organizations and Governance

Once an estate is more than one account, security stops being a per-account exercise. This section covers the controls that operate across accounts.

AWS Organizations provides the account hierarchy: a management account, member accounts and organizational units. Policies attach to the root, to an OU or to an account, and their effects are inherited downwards.

Service control policies (SCPs) and resource control policies (RCPs) set the maximum available permissions. Neither grants anything — an action is permitted only when the identity-based and resource-based policies allow it and no applicable SCP or RCP denies it. Two exceptions decide most designs: SCPs never apply to users or roles in the management account, and they never apply to service-linked roles. That is the main reason the management account should hold no workloads.

AWS Config is the detective counterpart. SCPs stop an action before it happens; Config records what was created and evaluates it against rules afterwards, with a history of every configuration change.

AWS Control Tower automates the setup: a landing zone, a log archive account, an audit account, and a library of controls — preventive controls implemented as SCPs, detective controls implemented as AWS Config rules, and proactive controls implemented as CloudFormation hooks that check a resource before it is provisioned.

IAM Identity Center is how people reach the accounts once the structure exists: one identity, mapped through permission sets to roles in many accounts.

Where to start

Core concepts of AWS cloud security covers the shared responsibility model and least privilege. Exploring Organizations covers the account structure and Control Tower. Controlling access and SCP implementation types cover the policies themselves; SCPs vs AWS Config draws the preventive/detective line. User access security covers people, MFA and activity monitoring.