What is IAM?

IAM stands for Identity and Access Management. It is the AWS service that decides who can do what in your AWS account. Every single request to AWS, whether it comes from the web console, the command line, or an application using an SDK (Software Development Kit, a code library for talking to AWS), passes through IAM first. If IAM does not allow the request, it never happens. Getting IAM right is the foundation of a secure cloud account, so it is worth understanding well before you build anything else.

What IAM actually does

IAM handles two jobs that often get confused, so let’s define them clearly.

Authentication answers “who are you?” When you sign in with a password or call the API with an access key, IAM verifies that you are who you claim to be.
Authorization answers “are you allowed to do this?” Once IAM knows who you are, it checks whether your identity has permission to perform the specific action you requested on the specific resource.

Think of authentication as showing your ID at the door, and authorization as the wristband that says which rooms you can enter.

IAM is free and global. You pay nothing for users, groups, roles, or policies, and your IAM configuration is not tied to a single AWS Region (a geographic location like us-east-1). It applies across your whole account everywhere.

The four building blocks

IAM is built from four core pieces. You will use these names constantly.

Entity	What it is	Best for
User	A long-lived identity for one person or a legacy app, with a password and/or access keys	A specific human or an old system that cannot use roles
Group	A named collection of users that you attach permissions to	Managing permissions for teams of people
Role	An identity with permissions but no permanent credentials that is temporarily “assumed”	Applications, EC2 instances, Lambda functions, cross-account access
Policy	A JSON document listing what is allowed or denied	Defining the actual permissions you attach to users, groups, or roles

The first three (users, groups, roles) are identities. A policy is the document that says what an identity can do. You attach policies to identities to grant permissions.

How a request gets authorized

When any request reaches AWS, IAM evaluates it against every policy that applies to the identity making the call. The result is a single yes-or-no decision. The logic follows three rules that you must memorize.

Deny by default. If nothing explicitly allows the action, it is denied. A brand-new IAM user can do absolutely nothing until you grant permissions.
Allow is the union of all policies. Your effective permissions are the combined total of every Allow across every attached policy. If one policy allows reading from Amazon S3 (Simple Storage Service, AWS object storage) and another allows starting EC2 (Elastic Compute Cloud, AWS virtual servers) instances, you can do both.
An explicit Deny always wins. If any policy contains a Deny that matches the request, the request is rejected, no matter how many Allow statements also match.

This is the number-one IAM gotcha. A user can be a member of an admin group with AdministratorAccess and still be blocked from one specific action if a single attached policy explicitly denies it. Explicit Deny overrides everything. This is exactly why explicit denies are used as guardrails, for example “no one may delete the production logs bucket.”

When to use users vs roles

This is the most important design choice in IAM, so here is the rule.

Use IAM users only for individual humans who need to sign in, and only when you are not yet using single sign-on. Even then, prefer IAM Identity Center (covered in this section) for human access.
Use IAM roles for anything that is code or a service: an EC2 instance, a Lambda function, a container, or another AWS account that needs access. Roles hand out temporary credentials that rotate automatically, so there are no long-lived keys to leak.
Do NOT bake user access keys into application code or onto a server’s disk. Leaked access keys are the most common cause of AWS account compromise.

Seeing IAM in action

Let’s confirm which identity you are currently signed in as. This is the IAM equivalent of “whoami” and works from any AWS account.

AWS Management Console steps:

Sign in to the AWS Management Console.
Click your account name in the top-right corner.
Read the Account ID and the user or role name shown in the dropdown.
To browse IAM itself, type IAM in the top search bar and open the IAM dashboard.

AWS CLI (version 2):

aws sts get-caller-identity

Output:

{
    "UserId": "AIDAEXAMPLE0A1B2C3D4E",
    "Account": "123456789012",
    "Arn": "arn:aws:iam::123456789012:user/jaswinder"
}

The Arn (Amazon Resource Name, a unique ID for every AWS thing) tells you exactly which identity AWS sees. Here it is an IAM user named jaswinder in account 123456789012. If you had assumed a role, the ARN would instead show assumed-role/....

You can also list the IAM users in your account to get a feel for the service.

aws iam list-users

Output:

{
    "Users": [
        {
            "UserName": "jaswinder",
            "UserId": "AIDAEXAMPLE0A1B2C3D4E",
            "Arn": "arn:aws:iam::123456789012:user/jaswinder",
            "CreateDate": "2026-01-12T09:31:44+00:00"
        }
    ]
}

A quick note on the root user

When you first create an AWS account, you get a root user, which is the email address you signed up with. The root user can do everything and cannot be restricted by IAM policies. You should almost never use it. Lock it down with multi-factor authentication (MFA, a second login factor such as a phone app), then create a regular IAM admin user or use IAM Identity Center for day-to-day work.

Best Practices

Treat IAM as the first thing you set up, before launching real resources.
Never use the root user for daily tasks; secure it with MFA and put it away.
Grant the fewest permissions needed, then add more only when required (least privilege).
Attach policies to groups and roles, not to individual users one by one.
Prefer roles and temporary credentials over long-lived access keys for anything that is code.
Remember the evaluation rules: deny by default, allow is the union of policies, and an explicit Deny always wins.
Enable CloudTrail (the AWS audit log) so every IAM action is recorded for review.