AWS IAM Roles and Policies

Roles and policies are where IAM becomes truly powerful. A role is an identity that is assumed rather than permanently owned. That makes roles ideal for EC2 instance profiles, Lambda execution identities, CI/CD systems, and cross-account access. Instead of storing long-lived credentials on every workload, AWS issues temporary credentials when the role is assumed.

Policies are JSON documents that describe permissions. The structure is consistent: Version defines the policy language version, Statement contains one or more rules, Effect is usually Allow or Deny, Action lists API operations, and Resource identifies what the action can target. Conditions can narrow access further based on context such as source IP, tags, or MFA presence.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject"],
      "Resource": "arn:aws:s3:::example-artifacts/*"
    }
  ]
}

Managed policies are usually easier to maintain because you can reuse and update them in one place. Inline policies can be helpful for narrow exceptions, but too many inline fragments make permission reviews messy. For most environments, standard roles plus managed policies create a cleaner access model.

Roles are especially important in automation. An EC2 instance profile lets applications access S3 or Secrets Manager without storing access keys on disk. A Lambda execution role tells the function what it can log or read. A cross-account role allows a security team in one account to audit another without sharing passwords or keys.

Pair this lesson with AWS IAM Best Practices so role design stays secure as your environment grows.

aws iam list-policies --scope Local --output table
aws iam get-role --role-name my-application-role
aws iam create-role --role-name demo-role --assume-role-policy-document file://trust-policy.json

Operational note

Permission work improves when it is reviewed as part of normal delivery rather than treated as a one-time security task. When a new team, service, or pipeline is introduced, decide which identity it should use, what the smallest permission set looks like, and how you will audit changes later through CloudTrail and IAM reports. Shared standards like this make future environments easier to launch, review, and support.