How to attach policies to an IAM role

Topic: Accounts access

Attach managed or inline policies to an IAM role so the role has the permissions needed when assumed by a service or principal. Use the console or CLI to attach and verify; prefer managed policies and least privilege.

Intent: How-to

Quick answer

  • In IAM → Roles → role → Permissions, attach managed policies (Add permissions → Attach policies); or create inline policies for role-specific rules.
  • Use attach-role-policy for managed and put-role-policy for inline; the role's effective permission is the union of all attached and inline policies, limited by any permission boundary.
  • Verify with list-attached-role-policies and list-role-policies; test by assuming the role (or having the service assume it) and calling the allowed APIs.

Prerequisites

Steps

  1. Choose policies for the role

    Identify the AWS managed or customer-managed policy ARNs that grant the actions and resources the role needs when assumed; prefer least privilege and avoid AdministratorAccess unless required.

  2. Attach managed policies to the role

    Use the console (Add permissions → Attach policies) or CLI attach-role-policy; you can attach up to 10 managed policies per role; use inline for role-unique rules if needed.

  3. Add inline policies if needed

    For role-specific conditions or resources, create an inline policy with put-role-policy; keep inline policies minimal and document them for audit.

  4. Verify effective permissions

    List attached and inline policies with list-attached-role-policies and list-role-policies; assume the role (or run the service that uses it) and test the intended actions.

Summary

You will attach managed and optionally inline policies to an IAM role so that when the role is assumed (by a service or by a user), it has the correct permissions. Use this when creating or updating roles for EC2, Lambda, or other principals; prefer managed policies for reuse and audit.

Prerequisites

Steps

Step 1: Choose policies for the role

  • Decide which actions and resources the role needs when assumed (e.g. S3 read for a bucket, DynamoDB read/write for a table).
  • Prefer AWS managed policies when they match (e.g. AmazonS3ReadOnlyAccess). For custom scope, use or create a customer-managed policy. Avoid attaching AdministratorAccess unless the role truly requires it.

Step 2: Attach managed policies to the role

Console: IAM → Roles → select role → Permissions → Add permissions → Attach policies directly. Select the managed policy(ies) and add.

CLI:

aws iam attach-role-policy --role-name my-lambda-exec-role \
  --policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess

A role can have up to 10 managed policies attached. For more, consolidate into fewer custom policies or use inline policies for the remainder.

Step 3: Add inline policies if needed

For role-specific rules (e.g. a condition or a single resource ARN), add an inline policy:

aws iam put-role-policy --role-name my-lambda-exec-role --policy-name InlineS3BucketOnly \
  --policy-document '{
    "Version": "2012-10-17",
    "Statement": [{
      "Effect": "Allow",
      "Action": ["s3:GetObject"],
      "Resource": "arn:aws:s3:::my-bucket/*"
    }]
  }'

Inline policies are tied to the role; document them for change control and audit.

Step 4: Verify effective permissions

aws iam list-attached-role-policies --role-name my-lambda-exec-role
aws iam list-role-policies --role-name my-lambda-exec-role

Assume the role (see How to assume an IAM role using AWS CLI) or run the service that uses the role (e.g. Lambda, EC2) and perform the intended actions. Use the IAM policy simulator with the role ARN to test specific API calls.

Verification

  • list-attached-role-policies and list-role-policies show the intended policies.
  • When the role is assumed, the principal can perform the allowed actions and is denied for actions not in the policies.
  • No permission boundary on the role (or the boundary is intended) and effective permissions match the design.

Troubleshooting

Access denied after attach — Check for a permission boundary on the role that limits permissions; check for explicit Deny in any attached policy. Simulate the role with the policy simulator for the failing action.

Hit managed policy limit (10) — Combine permissions into fewer customer-managed policies or move some rules to inline policies. Prefer one or two custom policies with clear names over many small attachments.

Inline policy overwrote previous — put-role-policy uses the policy name as key; same name overwrites. Use unique names per inline policy or use managed policies to avoid overwrite.

Next steps

Continue to