Skip to main content
This lesson demonstrates AWS Identity and Access Management (IAM): creating users and groups, attaching policies, and using roles to grant temporary permissions. You’ll learn how to configure users, assign permissions, organize users with groups, and let principals assume roles for temporary elevated access. When you go to https://aws.amazon.com/console, click “Sign in to the Console.” You can sign in either as the root user or as an IAM user. The root user is created automatically when you create an AWS account — it has unrestricted access to the entire account and uses the email address you registered with.
Do not use the root user for daily work. The root user has full account-wide access; if those credentials are compromised, an attacker can fully control your account. Use the root account only for initial setup and account-level tasks, and enable MFA.
Sign in with the root account credentials to start creating IAM users and groups.
A screenshot of the AWS Identity and Access Management (IAM) dashboard in the AWS Management Console. It shows security recommendations, IAM resource counts (e.g., Users 0, Roles 9, Policies 3) and account details on the right.

​
What IAM manages

IAM lets you manage these core entities:

​
Create an IAM user (console)

To create a user, open the IAM console and choose Users > Add users.
A screenshot of the AWS Identity and Access Management (IAM) Users page in the AWS Management Console. It shows no users listed, a search box and filters, and an "Add users" button on the right.
  1. Give the user a name (for example, sanjeev).
  2. Enable AWS Management Console access if the user needs to sign in to the console. You can let AWS auto-generate a password or supply one yourself.
  3. Optionally require the user to create a new password at first sign-in. If you’re creating the user for yourself, you can disable this.
A screenshot of the AWS Management Console IAM "Create user" page showing the username "sanjeev" with console access enabled and a custom password entered. The form displays password options, a checkbox requiring the user to reset the password at next sign-in, and a highlighted Next button.

​
Default permissions for new users

By default, a new IAM user receives no permissions. You must explicitly grant access via group membership, directly attached policies, or inline policies.
A screenshot of the AWS Management Console on the IAM "Set permissions" step for creating a user. It shows permission options (Add user to group, Copy permissions, Attach policies directly), a "Create group" prompt, and navigation buttons (Cancel, Previous, Next).
Review and create the user. After creation, you’ll see basic details such as MFA, group membership, and whether any policies are attached.
Screenshot of the AWS IAM Management Console on the "Review and create" page for creating a user. It shows user details for "sanjeev", a permissions summary (no resources), tag options, and the "Create user" button.

​
Verify permissions (sign in as the IAM user)

When signing in as an IAM user from the console, select “IAM user” on the sign-in page and provide the account ID plus the username and password. You can find the account ID in the root session (top-right account menu). Because the user has no permissions initially, attempts to perform actions — for example creating an S3 bucket — will fail with an error indicating which permission is missing (such as s3:CreateBucket).
A screenshot of the AWS S3 "Create bucket" console showing default encryption options (Amazon S3 managed keys selected and bucket key enabled) and an error box stating "Failed to create bucket" due to missing s3:CreateBucket permissions. The page header and the "Create bucket" button are visible at the bottom.

​
Grant permissions to a user

Return to your administrator/root session to modify the user’s permissions. From IAM > Users, open the user, go to the Permissions tab, and click Add permissions. Options include:
  • Add the user to a group (recommended when multiple users share permissions).
  • Copy permissions from an existing user.
  • Attach policies directly to the user.
  • Create an inline policy for fine-grained control.
A screenshot of the AWS Management Console on the IAM "Set permissions" step for creating a user. It shows permission options (Add user to group, Copy permissions, Attach policies directly), a "Create group" prompt, and navigation buttons (Cancel, Previous, Next).
AWS supplies many managed policies you can attach directly. For example, the AWS managed AdministratorAccess policy grants full access across the account. Its effective JSON is:
Attach AdministratorAccess to sanjeev. Afterwards, the user can list and create Amazon S3 buckets — confirming the permissions took effect.
A screenshot of the AWS Management Console IAM "Create user" page showing the username "sanjeev" with console access enabled and a custom password entered. The form displays password options, a checkbox requiring the user to reset the password at next sign-in, and a highlighted Next button.

​
Use groups to simplify permission management

If several users need the same permissions, create a group, attach policies to the group, and add users to it. Users inherit all policies attached to any group they belong to, which reduces duplication and simplifies onboarding. Example:
  • Create group: Admin
  • Attach policy: AdministratorAccess
  • Add users to Admin
A screenshot of the AWS Identity and Access Management (IAM) console showing the "admin" user group summary with the Permissions tab open. The AdministratorAccess policy is attached and the group's creation time and ARN are visible, with buttons to edit, delete, or add permissions.
You can also create a Monitoring group with the AWS managed ReadOnlyAccess policy. ReadOnlyAccess generally allows Get*, List*, and Describe* actions across services — suitable for users who should only view resources. If a user with only ReadOnlyAccess attempts to delete an S3 bucket, AWS will deny the request because s3:DeleteBucket is not included in the read-only policy.
A screenshot of the Amazon S3 management console showing a green success banner for newly created bucket "kodekloudtest12345." The page displays an account snapshot (storage and object count) and a list of S3 buckets with regions and creation dates.
A screenshot of the AWS S3 "Delete bucket" confirmation page for the bucket "sanjeevkodekloudbucket." It shows a text field to confirm the bucket name and a red error box stating the user lacks the s3:DeleteBucket permission.

​
Roles — temporary, assumable permissions

Roles provide temporary credentials that a user, AWS service, or an IAM principal in another account can assume. Use roles to:
  • Grant short-term elevated access without changing a user’s permanent permissions.
  • Allow AWS services (EC2, Lambda, etc.) to perform actions on your behalf.
  • Enable cross-account access by specifying trusted principals.
To create a role: IAM > Roles > Create role. Choose the trusted entity:
  • AWS service (for service roles used by EC2, Lambda, etc.), or
  • Another AWS account / IAM users within your account.
A screenshot of the AWS IAM Management Console on the "Create role" > "Select trusted entity" page. The "AWS service" option is selected and common use cases like EC2 and Lambda are shown, with Cancel and Next buttons at the bottom.
Example: create a role that grants full S3 access. Attach the AWS managed AmazonS3FullAccess policy:
Name the role (for example, S3FullAccess) and create it. Creating the role does not automatically allow everyone to assume it — you must explicitly allow specific principals to assume the role.
Screenshot of the AWS Identity and Access Management (IAM) console showing the Roles page with a list of IAM roles, their trusted entities, and last activity. A green banner at the top reads "Role S3FullAccess created."

​
Allow a user to assume a role (STS AssumeRole)

To allow a specific user (for example, sanjeev) to assume S3FullAccess, attach a policy to that user that permits the sts:AssumeRole action for the role’s ARN. You can create an inline policy on the user:
Name the policy (for example, AssumeS3Access) and attach it to sanjeev. Now sanjeev is authorized to assume the S3FullAccess role — and only that role.
A screenshot of the AWS IAM "Create policy" review page where a policy name ("assume") is being entered and the summary shows an STS Allow (Limited: Write) permission for a role named like "S3FullAccess." The bottom right has navigation buttons including "Create policy."

​
Switch Role (console experience)

To assume the role from the console, copy the role’s Switch Role link (available on the role’s detail page). When the user follows that link, the Switch Role dialog is pre-filled with the account number and role name. The user can choose a display name and color for the role badge and then click Switch Role to assume it.
A screenshot of the Amazon Web Services "Switch Role" page open in a browser. It shows fields populated with an account number, the role "S3FullAccess", display name "S3role", color choices, and a "Switch Role" button.
When a user assumes a role, the console shows a role badge confirming the active role and a “Switch back” option to revert to the original user session.
A screenshot of the AWS Management Console "Console Home" showing recently visited services (S3, CloudShell, EC2) and dashboard tiles for AWS Health and Cost & usage. The account/role menu is open on the right, showing an active S3FullAccess role with the "Switch back" button highlighted.
While assuming S3FullAccess, sanjeev can perform S3 operations such as deleting a bucket. After switching back, the user’s original permissions (for example, ReadOnlyAccess) are restored.
A screenshot of the Amazon S3 management console showing an account snapshot and a list of four S3 buckets with region, access, and creation dates. A green banner at the top indicates a bucket named "sanjeevkodekloudbucket" was successfully deleted.

​
Recap

  • Use the root account sparingly; create IAM users for everyday tasks.
  • New IAM users have no permissions by default.
  • Grant permissions by attaching managed or custom policies to users or by adding users to groups.
  • Use groups to centrally manage permissions for multiple users.
  • Roles provide temporary, assumable permissions for users, services, or cross-account principals. Assumption is controlled via sts:AssumeRole.
  • Follow the principle of least privilege: grant only the permissions required to perform a task.
Best practice: follow the principle of least privilege — grant only the permissions required to perform a task, use groups for consistent policy assignment, enable MFA, and prefer roles for temporary elevated access.

Watch Video