IAM resources - AWS Prescriptive Guidance

IAM resources

Although AWS Identity and Access Management (IAM) is not a service that is drawn in a traditional architecture diagram, it touches every aspect of the AWS organization, AWS accounts, and AWS services. You cannot deploy any AWS services without creating IAM principals and granting permissions first. A full treatment of IAM is beyond the scope of this document, but this section provides important summaries of best practice recommendations and pointers to additional resources.

Policy type Effect Managed by Purpose Pertains to Affects Deployed in

Service control policies (SCPs)


Central team, such as platform or security team1

Guardrails, governance

Organization (group of accounts)

All principals in organization, OU, and accounts

Org Management account2

Baseline account automation policies (the IAM roles used by the platform to operate an account)

Grant and restrict

Central team, such as platform, security, or IAM team1

Permissions for (baseline) non-workload performance roles3

Single account4

A principal in a member account

Member accounts

Baseline human policies (the roles that grant users permissions to perform their work)

Grant and restrict

Central team, such as platform, security, or IAM team1

Permissions for human roles5

Single account4

Federated principals5 and IAM users6

Member accounts

Permissions boundaries (maximum permissions that an empowered principal can assign to another principal)


Central team, such as platform, security, or IAM team1

Guardrails for workload performance roles

Single account4

The workload performance role principals in this account

Member accounts

Machine role policies for applications (role attached to infrastructure deployed by delegated administrators)

Grant and restrict

Delegated to workload owner8

Permission for workload compute9

Single account

A principal in this account

Member accounts

Resource policies

Grant and restrict

Delegated to workload owner8,10

Permissions to resources

Single account

A principal in an account11

Member accounts

Notes from table:

  1. Enterprises have many centralized teams (such as cloud platform, security operations, or identity and access management teams) that divide the responsibilities of these independent controls, and peer review one another’s policies. The examples in the table are placeholders. You will need to determine the most effective separation of duties for your enterprise.

  2. To use SCPs, you must enable all features within AWS Organizations.

  3. Common baseline roles and policies are generally needed to enable automation, such as permissions for the pipeline, deployment tools, monitoring tools (for example, AWS Lambda and AWS Config Rules), and other permissions. This configuration is typically delivered when the account is provisioned.

  4. Although these pertain to a resource (such as a role or a policy) in a single account, they can easily be replicated or deployed to multiple accounts by using AWS CloudFormation StackSets.

  5. Define a core set of baseline human roles and policies that are deployed to all member accounts by a central team (often during account provisioning). Examples include the workload owners (delegated administrators), the platform team, the IAM team, and security audit teams.

  6. Use identity federation (instead of local IAM users) whenever possible.

  7. Permissions boundaries are used by delegated administrators. This IAM policy defines the maximum permissions and overrides other policies (including "*:*" policies that allow all actions on resources). Permissions boundaries should be required in baseline human policies as a condition to create roles (such as workload performance roles) and attach policies. Additional configurations such as SCPs enforce the attachment of the permissions boundary.

  8. This assumes that sufficient guardrails (for example, SCPs and permissions boundaries) have been deployed.

  9. These optional policies could be delivered during account provisioning or as part of the workload development process. The permission to create and attach these policies will be governed by the application developer’s own permissions.

  10. In addition to local account permissions, a centralized team (such as the cloud platform team or the security operations team) often manages resource-based policies to enable cross-account access to operate the accounts (for example, to provide access to S3 buckets for logging).

  11. A resource-based IAM policy can enumerate any principal in any account. It can even enumerate anonymous principals (public access).

Ensuring that IAM identities have only those permissions that are necessary for a well-delineated set of tasks is critical for reducing the risk of malicious or unintentional abuse of permissions. Establishing and maintaining a least privilege model requires a deliberate plan to continually update, evaluate, and mitigate excess privilege. Here are some additional recommendations for that plan:

  • Use your organization’s governance model and established risk appetite to establish specific guardrails and permissions boundaries.

  • Implement least privilege through a continually iterative process. This is not a one-time exercise.

  • Use SCPs to reduce actionable risk. These are intended to be broad guardrails, not narrowly targeted controls.

  • Use permissions boundaries to delegate IAM administration in a safer way.

    • Make sure that the delegated administrators attach the appropriate IAM boundary policy to the roles and users they create.

  • As a defense-in-depth approach (in conjunction with identity-based policies), use resource-based IAM policies to deny broad access to resources.

  • Use IAM access advisor, AWS CloudTrail, AWS IAM Access Analyzer, and related tooling to regularly analyze historical usage and permissions granted. Immediately remediate obvious over-permissions.

  • Scope broad actions to specific resources where applicable instead of using an asterisk as a wildcard to indicate all resources.

  • Implement a mechanism to quickly identify, review, and approve IAM policy exceptions based upon requests.