AWS IAM User Step by Step - Create a User, User Group, Attach Policies, Access Keys, MFA and Sign-in URL (AWS Part-1)

This is Part-1 of my AWS step-by-step series, and it starts where every AWS account should start - with IAM (Identity and Access Management). You have just created an AWS account, you are logged in as the root user, and the very first thing to do is to stop using it. In this post we are going to create an IAM user, put it in a group, give the group permissions, log in with it, create access keys for the CLI, and switch on MFA.

I recorded the video for this part in 2023. The IAM console has moved a few buttons since then, and AWS has become much louder about one thing - humans should log in through IAM Identity Center, not as IAM users - so I have written this post against the current console and the current IAM best practices, and I say clearly where an IAM user is still the right tool.

Table of Content

1. What is IAM and why not just use the root user?
2. IAM users, groups, roles and policies - the four words you need
3. Create an IAM user in the console
4. Create a user group and attach policies
5. Sign in as the IAM user - the sign-in URL and account alias
6. Create access keys for the AWS CLI and Terraform
7. Enable MFA for the user (and the root user)
8. Write your own policy - least privilege in JSON
9. How IAM decides - policy evaluation logic
10. IAM users vs IAM Identity Center - what AWS wants you to do in 2026
11. Common IAM errors and how to fix them
12. Conclusion

1. What is IAM and why not just use the root user?

IAM is the AWS service that answers one question for every single API call - is this identity allowed to do this action on this resource? Every click in the console and every aws CLI command goes through it. It is global (not per region) and free.

The root user is the identity you created the account with - the email address and password. It can do absolutely everything, including closing the account and changing the payment method, and it cannot be restricted by any IAM policy. That is exactly why you should not use it for daily work -

1. If the root credentials leak, there is no permission boundary to limit the damage.
2. You cannot give a colleague "root but only for EC2".
3. CloudTrail shows root did everything, so you never know who actually did what.

So the plan for day one is - secure the root user (strong password, MFA, no access keys), then create IAM identities for everything else. AWS itself now requires MFA on the root user of the management account of an organization, and shows a reminder on every root login until you set it up.

2. IAM users, groups, roles and policies - the four words you need

1. IAM user - a long-term identity with a name and credentials - a console password and/or access keys. One user per human or per application that cannot use a role.
2. IAM group - a collection of users. You attach policies to the group and every member inherits them. Groups cannot be nested and cannot be a principal (you cannot "log in as a group").
3. IAM role - an identity with permissions but no credentials of its own - something assumes it and gets temporary credentials. EC2 instances, Lambda functions, other accounts and SSO users all use roles. That is Part-3, AWS assume IAM role.
4. IAM policy - a JSON document that says Allow or Deny for a list of Actions on a list of Resources, optionally under a Condition. Policies come in three flavours - AWS managed (maintained by AWS, like AdministratorAccess), customer managed (your own, reusable) and inline (glued to one identity, avoid).

The mental model - identities are attached to policies, policies allow actions on resources. Nothing is allowed until a policy allows it.

3. Create an IAM user in the console

Log in as root (for the last time, hopefully), search for IAM and open Users → Create user. The current console walks you through three steps.

Step 1 - User details

1. User name - rahul. Names are case-insensitive, up to 64 characters, letters, numbers and +=,.@_-.
2. Provide user access to the AWS Management Console - optional. Tick it if this user is a human who will use the console. The console then shows you two choices -
   • Specify a user in Identity Center - Recommended - AWS wants humans in IAM Identity Center (see section 10).
   • I want to create an IAM user - choose this for the tutorial.
3. Console password - Autogenerated password (you get it on the last page) or Custom password.
4. Keep Users must create a new password at next sign-in - Recommended ticked. This also gives the user permission to change their own password.

Note - if your account is on the new AWS console experience ("AWS Settings" and "teams"), AWS has removed the option to create IAM users with console access altogether - you add human users as team members instead, and IAM users remain for programmatic access only. The create user docs describe both experiences.

Click Next.

Step 2 - Set permissions

Three options -

1. Add user to group - the recommended one. Pick an existing group, or Create group right here (we do this in the next section).
2. Copy permissions - clone the policies of an existing user.
3. Attach policies directly - search the policy list and tick, e.g. AmazonS3ReadOnlyAccess. Quick, but you end up managing permissions user by user.

Under Set permissions boundary - optional you can attach a policy that caps the maximum permissions this user can ever have, regardless of what gets attached later - useful when you delegate user creation to other admins; skip it for now. Click Next.

Step 3 - Review and create

Check the summary, add tags if you like (team=platform), and click Create user.

Step 4 - Retrieve password

The last page shows the Console sign-in URL, the user name and the password, with Download .csv file and Email sign-in instructions. This is the only time you see an autogenerated password - copy it now.

4. Create a user group and attach policies

Even for one user, use a group - when the second developer joins, you add them to the group and they get the same access in one click.

1. IAM → User groups → Create group.
2. User group name - developers.
3. Add users to the group - tick rahul.
4. Attach permissions policies - search and tick what the group needs. For this series I attach -
   • AmazonEC2FullAccess - we launch instances in Part-4
   • AmazonVPCFullAccess - we build the network in Part-5
   • AmazonS3ReadOnlyAccess
   • IAMUserChangePassword - lets members change their own password (added automatically if you chose the reset-on-login option)
5. Create group.

A few more groups you will almost always end up with - admins (AdministratorAccess), billing (Billing + AWSBillingReadOnlyAccess), readonly (ReadOnlyAccess). The managed vs inline policies page explains why group + managed policy beats inline policies on users: one place to change, versioning, and reuse across users, groups and roles.

Limits worth knowing - a user can be in 10 groups, and an identity (user, group or role) can have 10 managed policies attached, each up to 6,144 characters of JSON.

5. Sign in as the IAM user - the sign-in URL and account alias

IAM users do not sign in at the normal AWS home page with an email. They sign in at the account sign-in URL -

1https://123456789012.signin.aws.amazon.com/console

Nobody remembers a 12-digit number, so create an account alias - IAM → Dashboard → AWS Account → Account Alias → Create, e.g. jhooq - and the URL becomes -

1https://jhooq.signin.aws.amazon.com/console

Open it in a private window, enter IAM user name rahul and the password, set a new password when prompted, and you are in - with exactly the permissions of the developers group. Try to open Billing and you get You don't have permission - that is IAM doing its job.

In the top-right account menu you can confirm who you are: it shows rahul @ jhooq, and the ARN is arn:aws:iam::123456789012:user/rahul.

6. Create access keys for the AWS CLI and Terraform

A console password is for humans. For the AWS CLI, the SDKs and Terraform, a user needs access keys - an access key ID (AKIA...) and a secret access key.

1. IAM → Users → rahul → Security credentials tab → Access keys → Create access key.
2. Use case - choose Command Line Interface (CLI). The console will nudge you towards alternatives (Identity Center, CloudShell) - tick the confirmation and Next.
3. Optional description tag (laptop-2026), Create access key.
4. Copy both values or Download .csv file. The secret is shown once.

Then on your machine -

 1aws configure
 2# AWS Access Key ID [None]: AKIA................
 3# AWS Secret Access Key [None]: ....................
 4# Default region name [None]: eu-central-1
 5# Default output format [None]: json
 6
 7aws sts get-caller-identity
 8# {
 9#     "UserId": "AIDA................",
10#     "Account": "123456789012",
11#     "Arn": "arn:aws:iam::123456789012:user/rahul"
12# }

Rules for access keys that I apply without exception -

1. Never in code, never in Git. Several of my own 2021 Terraform posts had keys pasted in the provider block - I have scrubbed them, and the right ways are in Terraform and AWS credentials handling.
2. Max two keys per user - that is so you can rotate: create the second, switch, delete the first.
3. Rotate, and watch the Last used column; delete keys that are not used.
4. No root access keys. Ever. If the root user has one, delete it today.
5. If a key leaks, deactivate it immediately (Security credentials → Actions → Deactivate), then rotate.

7. Enable MFA for the user (and the root user)

A password alone is not enough for anything that can spend money. IAM → Users → rahul → Security credentials → Multi-factor authentication (MFA) → Assign MFA device, give it a name, and choose -

1. Passkey or security key - FIDO2 - a YubiKey, or the passkey built into your phone/laptop (Touch ID, Windows Hello). The best option.
2. Authenticator app - Google Authenticator, Authy, 1Password ... scan the QR code, enter two consecutive codes.
3. Hardware TOTP token - the Gemalto-style devices.

Do the same for the root user under the account menu → Security credentials; you can register up to 8 MFA devices per user or root, so add a backup. To make MFA mandatory for everybody, attach a policy to the developers group that denies everything except setting up MFA when aws:MultiFactorAuthPresent is false - the MFA page has that exact policy.

8. Write your own policy - least privilege in JSON

AWS managed policies are coarse. The habit that separates a tidy account from a messy one is writing customer managed policies that allow exactly what a job needs. IAM → Policies → Create policy → JSON -

 1{
 2  "Version": "2012-10-17",
 3  "Statement": [
 4    {
 5      "Sid": "ListTheBucket",
 6      "Effect": "Allow",
 7      "Action": "s3:ListBucket",
 8      "Resource": "arn:aws:s3:::jhooq-demo-bucket"
 9    },
10    {
11      "Sid": "ReadWriteUploadsPrefix",
12      "Effect": "Allow",
13      "Action": ["s3:GetObject", "s3:PutObject"],
14      "Resource": "arn:aws:s3:::jhooq-demo-bucket/uploads/*"
15    },
16    {
17      "Sid": "OnlyFromTheOffice",
18      "Effect": "Deny",
19      "Action": "*",
20      "Resource": "*",
21      "Condition": {
22        "NotIpAddress": { "aws:SourceIp": ["203.0.113.0/24"] }
23      }
24    }
25  ]
26}

The pieces -

1. Effect - Allow or Deny.
2. Action - service:Operation, wildcards allowed (s3:Get*, ec2:Describe*).
3. Resource - ARNs. Note the S3 trap - ListBucket is on the bucket ARN, object actions are on bucket/* - I have explained it in the S3 course.
4. Condition - IP ranges, MFA, tags, time, source VPC ... the condition keys are where fine-grained control lives.

Name it S3UploadsReadWrite, create it, and attach it to the group instead of AmazonS3FullAccess. The Policy simulator (IAM → Policy simulator) lets you test "can rahul s3:PutObject on this ARN?" without actually doing it, and IAM Access Analyzer suggests policies from what an identity has actually used in CloudTrail. If you manage IAM with Terraform, the aws_iam_policy_document data source writes this JSON for you - Terraform AWS IAM - users, roles and policies.

9. How IAM decides - policy evaluation logic

When rahul calls s3:PutObject, IAM collects every policy that applies - identity policies on the user and his groups, resource policies on the bucket, permissions boundaries, SCPs from the organization (Part-2), session policies - and evaluates them with one algorithm -

1. Default - implicit deny. Nothing is allowed until something allows it.
2. An explicit Deny anywhere wins. No Allow can override it. That is how the office-IP statement above locks everything down.
3. Otherwise, an Allow is needed in an identity policy or a resource policy (same account - either is enough; cross-account - both).
4. Boundaries and SCPs can only take away - the effective permission is the intersection of the identity policy with the permissions boundary and with the SCPs.

Two consequences people hit every week - attaching AdministratorAccess does not help if an SCP on the OU denies the service, and a bucket policy Deny beats your user's AmazonS3FullAccess.

10. IAM users vs IAM Identity Center - what AWS wants you to do in 2026

The IAM best practices are blunt - require human users to use federation with an identity provider to access AWS using temporary credentials instead of IAM users with long-term credentials. In practice that means IAM Identity Center (the service formerly called AWS SSO) -

Identity Center needs an organization, which is why it is Part-2 of this series. Once it is on, your human logins move there and the IAM users that remain are the legitimate exceptions the docs list - CI systems and third-party tools that cannot assume roles, the one emergency break-glass user kept in a safe, and workloads on servers outside AWS. Everything running inside AWS (EC2, Lambda, ECS) should use a role, not a user with keys.

11. Common IAM errors and how to fix them

1. User: arn:aws:iam::123456789012:user/rahul is not authorized to perform: ec2:RunInstances on resource: ... because no identity-based policy allows the ec2:RunInstances action - The implicit deny. Attach a policy with that action to the user's group. The message literally names the missing action - start there.

2. ... with an explicit deny in a service control policy - An SCP from the organization blocks it; no IAM policy in the account can fix this. Ask the org admin or move the account to a different OU (Part-2).

3. ... with an explicit deny in an identity-based policy - A Deny statement in one of the user's policies (often an MFA-enforcement or IP-restriction policy) applies. Check if you logged in with MFA / from the right network.

4. The security token included in the request is invalid / InvalidClientTokenId - The access key ID is wrong, deleted or deactivated, or you are in a region where STS is disabled. aws configure list shows which key is in use.

5. SignatureDoesNotMatch - The secret key is wrong (a trailing space when pasting is the classic) - full write-up.

6. You cannot create more than 2 access keys for this user - Rotate: delete the unused one first. aws iam list-access-keys --user-name rahul.

7. Password does not conform to the account password policy - IAM → Account settings → Password policy. Default minimum is 8 characters; set your own (14+, complexity, expiry).

8. The user can log in but sees You don't have permissions to view this page everywhere - They are in no group / no policy attached. New users have zero permissions.

9. An error occurred (AccessDenied) when calling the AssumeRole operation - That is a role problem, not a user problem - Part-3.

10. MFA is required prompts in the CLI - Your policy requires MFA for API calls. Use aws sts get-session-token --serial-number <mfa-arn> --token-code 123456 or, far better, switch to Identity Center / a role.

12. Conclusion

To summarise Part-1 -

1. The root user is for account setup, billing and emergencies only - MFA on, keys off.
2. Create IAM users for identities that genuinely need long-term credentials, put them in groups, and attach managed policies to the groups.
3. IAM users sign in at https://<alias>.signin.aws.amazon.com/console; the CLI, SDKs and Terraform use access keys - never committed, always rotated, maximum two.
4. MFA on every human identity; customer managed policies in JSON for least privilege; an explicit deny always wins.
5. For humans, AWS wants you on IAM Identity Center - which needs AWS Organizations, and that is Part-2. Roles, the identity you will use most, are Part-3.

The authoritative references are the IAM User Guide, the best practices and the policy evaluation logic. If you prefer to manage all of this as code, Terraform AWS IAM - users, roles and policies builds the same user, group and policy with Terraform.

More videos on this topic - the introduction to my 2024 AWS Solutions Architect series, then the same ground, step by step: account sign-up, access keys and the CLI; IAM policies and users; groups; MFA; IAM Access Analyzer; and the CLI config, credentials file and profiles -

AWS step by step series -

1. Part-1 : AWS IAM user - create a user, group, policy, access keys and MFA
2. Part-2 : AWS Organizations - multi-account setup, OUs and SCPs
3. Part-3 : AWS assume IAM role - trust policy, switch role in console and CLI
4. Part-4 : How to launch an EC2 instance - key pair, security group, SSH
5. Part-5 : AWS VPC - public and private subnets, Internet Gateway, NAT Gateway, route tables
6. Part-8 : EC2 launch template - versions, default version, source template, SSM parameter AMI
7. Part-10 : EC2 Auto Scaling - launch template, Auto Scaling group, target tracking, ALB
8. Part-11 : AWS WAF - web ACL, managed rules, rate limiting, geo blocking
9. Part-12 : AWS VPC Peering - connect two VPCs, routes, security groups, DNS
10. Part-13 : AWS Transit Gateway - hub-and-spoke for many VPCs and on-premises
11. Part-14 : AWS NAT Gateway deep dive - public vs private, limits, cost, troubleshooting
12. Part-15 : Amazon Route 53 - hosted zones, records, alias, routing policies, health checks
13. Part-16 : AWS security groups - inbound and outbound rules, stateful, referencing, quotas
14. Part-16 : AWS Certificate Manager - free TLS certificates for ALB, CloudFront and API Gateway
15. Part-17 : AWS Lambda - function URLs, environment variables and layers
16. Part-18 : Network Load Balancer - setup, and ALB vs NLB
17. Part-19 : VPC endpoints - gateway and interface endpoints (PrivateLink) instead of NAT
18. Part-20 : AWS PrivateLink - publish your own service with an endpoint service and NLB
19. Part-20 : Amazon EBS volumes - types, attach, mount, resize, snapshots, encryption
20. Part-21 : VPC Flow Logs - CloudWatch Logs, S3, record format, Logs Insights, Athena
21. Part-21 : EC2 Spot Instances - pricing, interruptions, mixed instances groups
22. Part-24 : AWS Control Tower - landing zone, controls, Account Factory, Identity Center

Networking fundamentals -

1. What is a VPC and a subnet? AWS networking in five minutes
2. What is CIDR? Calculate IP ranges for VPCs and subnets
3. What is NAT? Static NAT, dynamic NAT and PAT explained

More AWS guides -

1. What is AWS CloudFormation? Templates, stacks, change sets, drift, StackSets
2. Learn AWS S3 - the complete course
3. AWS API Gateway - REST API with Lambda, authorizers, Terraform
4. AWS Advanced Networking Specialty (ANS-C01) - course companion
5. AWS ECS and Fargate - how to deploy a Docker container
6. AWS S3 - how to host a static website
7. Terraform create EC2 instance on AWS
8. Terraform AWS IAM - users, roles and policies
9. Terraform and AWS multi-account setup
10. Terraform - setting up an ALB and SSL