Creating IAM Users

An IAM user (Identity and Access Management user) is a long-lived identity inside your AWS account that represents a single person or, less ideally, a single application. Each user gets its own sign-in name, its own credentials, and its own set of permissions. The whole point of users is to stop people from sharing the root account or passing one set of credentials around. This page shows you how to create a user in both the Console and the CLI, how to give them the right kind of credentials, and, just as importantly, when you should not create a user at all.

What an IAM user actually is

A user is one of the core identity types in IAM. It is “long-lived” because it sticks around until you delete it, and any credentials you attach to it keep working until they are rotated or removed. A user can have two kinds of credentials:

A console password — for a human who signs in to the AWS Management Console (the web dashboard) through a browser.
One or more access keys — an access key ID plus a secret access key, used by scripts, the AWS CLI (Command Line Interface), or SDKs (Software Development Kits) to make API calls.

A user can have a password, access keys, both, or neither. You attach permissions to a user by adding the user to a group, attaching a policy directly, or both.

One user per human. Never create a single “shared” user that several teammates log in with. If three people use one login, you can never tell from the logs who did what, and you cannot revoke access for one person without locking out everyone. Give every individual their own user.

When to create a user — and when NOT to

This is the part most tutorials skip. IAM users are not the modern default for most situations.

Identity type	Use it for	Avoid it for
IAM user	Break-glass admin, small accounts with no SSO, a service in a non-AWS environment that genuinely needs static keys	Day-to-day human access, workloads running on AWS
IAM role	Apps and AWS services (EC2, Lambda) that need temporary credentials	A single named human signing in
IAM Identity Center	Human sign-in across many accounts via single sign-on (SSO)	Machine-to-machine API access

The rule of thumb in 2026:

For humans, prefer IAM Identity Center (AWS’s built-in SSO service, formerly called AWS SSO). It gives each person a single login across all your accounts and hands out short-lived credentials instead of permanent ones.
For workloads running on AWS (an EC2 instance, a Lambda function, a container), use an IAM role. The service assumes the role and gets temporary credentials automatically — no keys to store or leak.
Create an actual IAM user only when none of those fit: a tiny single-account setup with no SSO, a true break-glass admin, or an external system that can only authenticate with static keys.

The number one leak vector. Long-lived user access keys are the single most common way AWS credentials end up compromised — committed to Git, baked into a Docker image, or pasted into a config file. Every access key you create is a key that can leak. If you can use a role or Identity Center instead, do.

Creating a user in the Console

Open the IAM console at https://console.aws.amazon.com/iam/.
In the left navigation, choose Users, then Create user.
Enter a User name, for example jane.doe.
To let this person use the web console, select Provide user access to the AWS Management Console. Choose to auto-generate or set a password, and leave Users must create a new password at next sign-in checked.
Choose Next, then set permissions. The cleanest option is Add user to group — add them to a group whose policies already grant the right access (see the IAM Groups page).
Review and choose Create user.
On the confirmation screen, download the .csv with the sign-in URL and password. This is the only time the generated password is shown.

If you need programmatic access for this user, create an access key afterward from the user’s Security credentials tab — and only if a role truly will not work.

Creating a user with the CLI

The CLI uses several small commands. First, create the user:

aws iam create-user --user-name jane.doe

Output:

{
    "User": {
        "Path": "/",
        "UserName": "jane.doe",
        "UserId": "AIDA0A1B2C3D4E5F6G7H8",
        "Arn": "arn:aws:iam::123456789012:user/jane.doe",
        "CreateDate": "2026-06-15T10:42:11+00:00"
    }
}

Give the user a console password so they can sign in to the web dashboard:

aws iam create-login-profile \
  --user-name jane.doe \
  --password 'TempPassw0rd!2026' \
  --password-reset-required

Add the user to an existing group to grant permissions (preferred over attaching policies directly):

aws iam add-user-to-group --user-name jane.doe --group-name Developers

If, and only if, this user needs programmatic access, create an access key:

aws iam create-access-key --user-name jane.doe

Output:

{
    "AccessKey": {
        "UserName": "jane.doe",
        "AccessKeyId": "AKIA0A1B2C3D4E5F6G7H",
        "Status": "Active",
        "SecretAccessKey": "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY",
        "CreateDate": "2026-06-15T10:43:02+00:00"
    }
}

Save the secret now. The SecretAccessKey is shown exactly once, at creation time. AWS never displays it again. If you lose it, you must delete the key and create a new one.

Cost note

IAM users, groups, roles, and policies are free — AWS does not charge for IAM itself. You only pay for the AWS resources those identities use. IAM Identity Center is also free to use. So there is no cost reason to prefer users over the safer alternatives; the safer option is free too.

Best Practices

Create one IAM user per human, never a shared login, so every action traces to a person.
Prefer IAM Identity Center for human sign-in and IAM roles for workloads; reserve IAM users for cases where neither fits.
Attach permissions through groups, not directly on the user, so access is consistent and easy to audit.
Avoid creating access keys unless a role genuinely cannot be used; every key is a potential leak.
Require multi-factor authentication (MFA) for every user that has a console password.
Rotate any access keys you do create on a regular schedule, and delete keys that are no longer in use.
Grant only the permissions a user needs (least privilege) rather than broad administrator access.