AWS IAM Guide: Users, Roles, Groups, and Permissions Explained

AWS Identity and Access Management (IAM) is the service that controls who can do what inside your AWS account. Every API call, every console login, and every resource action goes through IAM. Getting IAM right from the start is the single most important security decision you'll make in AWS. This guide explains all the core concepts with practical examples.

Why IAM Matters

By default, a newly created AWS account has only one identity: the root user. The root user has unrestricted access to everything — including billing, account deletion, and all resources. Best practice is to never use the root user for everyday tasks. Instead, create IAM users with only the permissions they need.

IAM Core Concepts

• User — A permanent identity for a person or application. Has long-term credentials (password, access keys).
• Group — A collection of users. Permissions attached to a group apply to all members. E.g. Developers, Admins, ReadOnly.
• Role — A temporary identity assumed by AWS services, applications, or users from other accounts. No long-term credentials.
• Policy — A JSON document that defines allowed or denied actions on resources.

Creating Your First IAM User

In the AWS Console, navigate to IAM > Users > Create user. Give the user a name, enable console access, and attach permissions. For an admin user, attach the AdministratorAccess managed policy — but in production, always prefer least-privilege custom policies.

# Create an IAM user via the CLI
aws iam create-user --user-name alice

# Attach a managed policy
aws iam attach-user-policy 
  --user-name alice 
  --policy-arn arn:aws:iam::aws:policy/ReadOnlyAccess

IAM Policies Explained

A policy is a JSON document with one or more statements. Each statement has:

• Effect — Allow or Deny
• Action — The API actions permitted (e.g. s3:GetObject, ec2:StartInstances)
• Resource — The ARN of the resource the action applies to (* means all resources)
• Condition — Optional conditions like IP address, MFA status, or time of day

# Example custom policy: allow read-only S3 access to one bucket only
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::my-app-assets-2026",
        "arn:aws:s3:::my-app-assets-2026/*"
      ]
    }
  ]
}

IAM Roles: The Right Way to Grant AWS Service Access

Roles are the preferred way to give AWS services (like EC2 or Lambda) permission to call other AWS services. Instead of embedding access keys in your application code, attach an IAM role to your EC2 instance or Lambda function.

# Attach an instance profile (role) to a running EC2 instance
aws ec2 associate-iam-instance-profile 
  --instance-id i-0abcd1234efgh5678 
  --iam-instance-profile Name=MyEC2S3ReadRole

Once attached, any code running on that EC2 instance can call AWS APIs without any hardcoded credentials. The instance metadata service (IMDS) provides temporary credentials automatically.

IAM Groups: Manage Permissions at Scale

Rather than attaching policies to individual users, create groups and assign users to groups:

# Create a group and attach a policy
aws iam create-group --group-name Developers
aws iam attach-group-policy 
  --group-name Developers 
  --policy-arn arn:aws:iam::aws:policy/AmazonEC2FullAccess

# Add a user to the group
aws iam add-user-to-group --user-name alice --group-name Developers

Enable MFA for All IAM Users

Multi-Factor Authentication (MFA) is mandatory for any serious AWS account. Enable it for the root user first, then enforce it for all IAM users via an IAM policy condition:

# Enforce MFA with a policy condition (add to any policy)
"Condition": {
  "BoolIfExists": {
    "aws:MultiFactorAuthPresent": "true"
  }
}

IAM Access Analyzer

AWS IAM Access Analyzer automatically flags resources that are accessible from outside your account — things like public S3 buckets, open IAM roles, or permissive KMS key policies. Enable it in the IAM console under Access Analyzer with one click. It is free for basic findings.

IAM Best Practices

1. Lock down the root account — enable MFA and never create root access keys
2. Follow least privilege — grant only the permissions required for the task
3. Use roles for services — never embed access keys in application code
4. Use groups to manage permissions — not individual user attachments
5. Rotate access keys regularly — or better, use roles and avoid long-lived keys
6. Enable CloudTrail — log every IAM action for auditing
7. Use AWS Organizations SCPs for multi-account guardrails

Summary

IAM is not just a security tool — it is the control plane for your entire AWS environment. Understanding users, groups, roles, and policies gives you the foundation to build secure, well-governed AWS architectures. Invest time in IAM early, and you'll avoid the painful security incidents that come from misconfigured access controls.