AWS Identity and Access Management (IAM)

AWS IAM decides who gets into your account. So, it sets limits on the actions people can take. Also, it picks which tools they’re allowed to use. Get clear on users, groups, roles, and rules - one by one - and things start making sense fast.

IAM Users

A person needing AWS access is set up as an IAM user. They’re given a name, plus a sign-in password for the web interface. Access codes might also be added - these help when using command tools or software kits.

What someone adds

• Username
• Password (for console)
• Access keys (for CLI)
• MFA settings

Beginner-friendly example

You bring on a new person called Ali. Then you set up:

User: ali
Console login: yes
MFA: enabled

Ali’s set up as a user, yet lacks access rights. Rather than assigning each permission separately, toss him into a group instead.

IAM Groups

Groups help give access to multiple people together. Put rules on a group - everyone inside gains that access straight away.

Common group examples

• developers
• read-only
• admins

Example inside this topic

If you’ve got five coders, here’s what could happen:

Group: developers
Policy: Read-only access to EC2 and S3

Next, bring Ali into the team. Right away, he’s given access to develop - no extra actions needed.

IAM Roles

A role acts like a short-term ID for AWS services - or even users - when they need access. It doesn't come with passwords or permanent keys. Instead, AWS hands out time-limited credentials once it's activated.

Roles are best for giving AWS services permission to talk to other AWS services.

Where roles get applied

• EC2 → S3
• Lambda → CloudWatch
• Temporary access sessions

Example: EC2 instance listing S3 buckets

Let’s say your EC2 instance needs to run aws s3 ls to see all S3 buckets.

You do this:

1. Create a role

   Role name: EC2S3ListRole
   Trusted entity: EC2

1. Attach a policy that allows listing S3 buckets:

   {
     "Version": "2012-10-17",
     "Statement": [
       {
         "Effect": "Allow",
         "Action": "s3:ListAllMyBuckets",
         "Resource": "*"
       }
     ]
   }

1. Attach the role to your EC2 instance.

Now the instance can list S3 buckets safely without storing access keys.

IAM Policies

Policies come as JSON files showing which actions can be allowed or blocked. A user, group, or role only works once a policy is linked to it.

A policy contains

• Effect: Allow or Deny
• Action: What can be done
• Resource: Where the action applies
• Condition: Optional extra rules

A basic case within this subject

A policy to list all S3 buckets:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:ListAllMyBuckets",
      "Resource": "*"
    }
  ]
}

A policy to read objects in one bucket:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::my-example-bucket/*"
    }
  ]
}

We attach these policies to a group or a role depending on who needs the access.

A Practical Way to Master AWS IAM

We go step by step through a full training run - create an IAM user, review permissions, attach a policy, assign an EC2 instance role, after that test everything using AWS CLI commands.

The main goal is to understand how users, groups, roles, and policies work together.

1. Start With IAM Users

Create a new IAM user

1. Open the AWS Console and go to IAM.

1. Select Users from the left menu.
2. Choose Create user.
3. Enable Access to the AWS Management Console.
4. Pick Autogenerated password and leave everything else as default.

1. Continue to the next page.
2. On the permissions page, keep the defaults and go next.
3. Review everything and create the user.
4. Download the credentials CSV file.

1. Return to the user list.

Test login

1. Copy the sign-in URL shown on the user details page.
2. Paste it into an incognito window.
3. Log in with the autogenerated password.
4. The console will ask you to reset the password.
5. After logging in, you will see the default AWS console but with no permissions.

2. Test Lack of Permissions

This is important because it shows how IAM actually blocks actions.

Try creating an S3 bucket

1. Search for S3 in the AWS search bar.

1. Open the S3 service.

1. Select Create bucket.
2. Add a globally unique bucket name.

1. Keep everything default and try to create it.

You’ll get an error like:

To create a bucket, the s3:CreateBucket permission is required.
User is not authorized to perform: s3:CreateBucket …

This confirms the user has zero permission by default.

3. Add Permissions Using a User Group

Go back to the root account.

Create an S3 access group

1. Go to IAM > User groups.
2. Click Create group.
3. Name it s3-manager.

1. Add your IAM user (for example, “random”).
2. Search for AmazonS3FullAccess and attach it.

1. Create the group.

Test again as the IAM user

1. Log in again as the IAM user.
2. Go to S3 > Create bucket.
3. Try creating the bucket again.

This time the bucket should be created successfully.

4. Add EC2 Permissions Through Another Group

Back to the root account.

Create EC2 admin group

1. Go to IAM > User groups.
2. Create a group named ec2-admin.
3. Attach the AmazonEC2FullAccess policy.
4. Add your IAM user to this group.

Now the user has both S3 full access and EC2 full access.

5. Launch an EC2 Instance

1. Go to EC2.
2. Click Launch instance.
3. Name it management-server.
4. Choose Amazon Linux 2023.
5. Instance type: t2.micro.
6. Use the default VPC and defaults for other settings.
7. Create a key pair and download it.
8. Allow SSH from anywhere.
9. Launch the instance.

Connect

Use SSH or the EC2 “Connect” button.

Test access

Run:

aws s3 ls

You’ll see:

Unable to locate credentials. You can configure credentials by running "aws configure".

This shows that an EC2 instance does not inherit the logged-in user’s permissions.
Instances need IAM roles, not IAM users.

6. Create an IAM Role for EC2

Back to the root account.

Create a role

1. Go to IAM > Roles.
2. Choose Create role.

1. Select AWS service.
2. Pick EC2 as the use case.
3. Continue.
4. Search for AmazonS3FullAccess and attach it.

1. Name the role s3-manager.

2. Create the role.

Attach the role to the instance

1. Go to EC2 > Instances.
2. Select your instance management-server.
3. Actions > Security > Modify IAM role.

1. Choose s3-manager.
2. Update the role.

7. Test the Role on the EC2 Instance

Connect again to the instance.

Run:

aws s3 ls

This time it should list your buckets.

)

You’ve now validated:

• IAM user without permissions
• IAM group with permissions
• IAM policy attachment
• EC2 instance role
• Credential-less CLI access through instance role

This is the exact workflow used in real AWS environments.

8. Clean Up

Delete everything you created:

• S3 bucket
• IAM user
• IAM groups
• IAM role
• EC2 instance
• Key pair

Conclusion

AWS IAM makes more sense when you picture how each piece connects. People get identified by users, while groups bundle up permissions neatly. Roles hand out short-term access to AWS tools instead of permanent keys. Policies lay down the rules on which actions actually work. Try logging in as someone with limited rights - it shows what restrictions feel like firsthand. Toss a user into a group and watch their powers change without touching individual settings. Hook a role to an EC2 machine, then see it talk to other services solo. These moves prove how IAM locks things down tight. Learn this core stuff and you’ll tweak access without second-guessing every click.

Comments

[Aaron Rose]

Nice one, M! Cheers 💯