AWS IAM Guide: Users, Groups, Roles & Policies Explained

Every action in AWS — launching a server, reading a file, deleting a database — is authorised (or denied) by Identity and Access Management (IAM). IAM is the security foundation of every AWS account. Getting it wrong is how breaches happen; getting it right is how you build a secure, auditable cloud environment.

This lesson covers IAM completely: users, groups, roles, policies, and the best practices that keep your account secure.

What Is IAM?

IAM is a global AWS service (not region-specific) that controls who can do what in your AWS account. It manages authentication (who you are — users, roles, federated identities) and authorisation (what you're allowed to do — policies). IAM is free — there is no charge for using IAM.

IAM Identities

Root User

Created when you create an AWS account. Has unrestricted access to everything — including billing, account closure, and support tier changes. Use only for initial setup and tasks that explicitly require root access. Lock it behind MFA and treat it like a break-glass credential.

IAM Users

An IAM user represents a person or application that interacts with AWS. Each user has a name unique within the account, an optional console password (for human users), optional access keys (for programmatic/CLI access), and attached permissions (via policies or groups).

IAM User: alice
  - Console password: enabled
  - Access key: AKIA... (for CLI/SDK)
  - Permissions: via "Developers" group

IAM Groups

A group is a collection of IAM users. Policies attached to a group apply to all users in it. This is how you manage permissions at scale — attach a policy to a group once, then add users to the group.

Group: Developers
  ├── Policy: AmazonEC2FullAccess
  ├── Policy: AmazonS3ReadOnlyAccess
  └── Members: alice, bob, charlie

Groups cannot be nested — you can't put a group inside another group.

IAM Roles

An IAM role is an identity that can be assumed — temporarily — by AWS services (e.g., an EC2 instance reading from S3), IAM users in the same or different account, federated identities (SSO, Active Directory, Google/GitHub via OIDC), and AWS services like Lambda, ECS tasks, or CodeBuild.

When a role is assumed, temporary credentials are issued (via STS). These expire automatically — no long-lived access keys.

Key use case: Instead of putting AWS access keys on an EC2 instance (dangerous and hard to rotate), attach an IAM Role to the instance. The instance automatically gets temporary credentials that rotate every hour.

# With an instance role attached, the AWS CLI on EC2 just works:
aws s3 ls s3://my-bucket
# No credentials needed — the role provides them automatically

IAM Policies

Policies are JSON documents that define what actions are allowed or denied on which resources.

Policy Structure

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject"
      ],
      "Resource": "arn:aws:s3:::my-bucket/*"
    },
    {
      "Effect": "Deny",
      "Action": "s3:DeleteObject",
      "Resource": "*"
    }
  ]
}

Every policy statement has an Effect (Allow or Deny), Action (the AWS API actions), Resource (the ARN of the resource), and an optional Condition (context-based restrictions).

Policy Types

Policy Evaluation Logic

When an action is requested: an Explicit Deny in any policy denies the action — full stop. An Explicit Allow (with no explicit deny) allows the action. If no policy covers the action, it's denied by default.

"Deny wins" is the critical rule. An explicit Deny always overrides an Allow.

ARNs: Amazon Resource Names

Every AWS resource has a unique ARN (Amazon Resource Name) used in policies:

arn:aws:s3:::my-bucket           # S3 bucket
arn:aws:s3:::my-bucket/*         # All objects in bucket
arn:aws:ec2:us-east-1:123456789012:instance/i-abc123
arn:aws:iam::123456789012:user/alice

Format: arn:partition:service:region:account-id:resource

IAM Conditions

Conditions add context-based restrictions to policies:

{
  "Effect": "Deny",
  "Action": "*",
  "Resource": "*",
  "Condition": {
    "BoolIfExists": {
      "aws:MultiFactorAuthPresent": "false"
    }
  }
}

This policy denies all actions unless MFA was used to authenticate. Common condition keys include aws:MultiFactorAuthPresent (require MFA), aws:SourceIp (restrict to specific IPs), aws:RequestedRegion (restrict to specific regions), and aws:CurrentTime (time-based access).

IAM Best Practices

Never Use Root for Daily Tasks — Create an IAM user or use IAM Identity Center for all regular operations. Reserve root for tasks that explicitly require it.

Apply Least Privilege — Grant only the permissions required to do the job. Start with read-only access and add write permissions as needed. AWS's Access Analyzer helps identify over-permissive policies.

Use Roles for Applications, Not Access Keys — Long-lived access keys on servers or in code are a security risk. Use IAM Roles for EC2 instances, Lambda functions, and ECS tasks — they get automatically rotating temporary credentials.

Enable MFA Everywhere — Enable MFA for all human IAM users, especially those with admin access. Require MFA as a condition in sensitive policies.

Use IAM Identity Center for Human Access — For multi-account environments, IAM Identity Center (formerly SSO) is the recommended way to manage human access. It integrates with identity providers (Active Directory, Okta, Google Workspace) and issues short-lived credentials per session.

Rotate Access Keys Regularly — If you must use access keys (for legacy scripts or CI/CD), rotate them every 90 days at minimum. Delete unused keys immediately.

Use AWS Organisations and SCPs for Multi-Account Governance — At scale, use SCPs as guardrails — e.g., prevent any account from disabling CloudTrail, or restrict all accounts to operate only in approved regions.

Previous: Lesson 2 — AWS Global Infrastructure | Next: Lesson 4 — Amazon EC2

Part of the AWS Cloud Fundamentals course.

External references:

• AWS IAM best practices — official AWS security documentation