AWS Builder Center

Builder Center

AWS IAM Explained Simply: Who Can Do What in Your AWS Account

a simple guide to IAM on Amazon web services

What is IAM?

IAM (Identity and Access Management) is the service that decides who can do what in your AWS account.
Think of your AWS account as a university building. IAM is the security system:
  • ID cards are the identities (who you are)
  • Access rules decide which rooms each card can open (what you can do)
Without IAM, anyone with your login could delete your servers, read your files, or run up a big bill. IAM is free to use, and it's the first service every student should learn.

The 4 building blocks

1. Root user. This is the email and password you used to create the account. It has unlimited power and can't be restricted. Use it only for the first setup, turn on MFA (multi-factor authentication), and then stop using it for daily work.
2. IAM users. A user is a person (or an app) with their own login. Instead of sharing one account, each person gets their own user, so you can see who did what.
3. IAM groups. A group is a bundle of users with the same permissions. Example: a "Developers" group and a "Testers" group. Add a user to a group and they get its permissions automatically.
4. IAM roles. A role is a set of permissions that someone or something temporarily takes on. It has no password. The most common use: letting an EC2 server access S3 without storing secret keys on the server.
Simple way to remember: users are people, groups are teams, roles are temporary jobs.

Policies: the rules

Permissions are written as policies, which are JSON documents. A policy answers three questions:
  • Effect: Allow or Deny?
  • Action: what can be done? (e.g. read a file)
  • Resource: on what? (e.g. this one bucket)

Example: read-only access to one S3 bucket

json
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:::my-study-notes-bucket"
},
{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::my-study-notes-bucket/*"
}
]
}
In plain language: this person can see the list of files in my-study-notes-bucket and download them. They can't upload, delete, or touch any other bucket.
Note the two different resources: ListBucket applies to the bucket itself, while GetObject applies to the files inside it (/*). This is a very common beginner mistake.

3 rules about how permissions work

  1. Everything is denied by default. A new user can do nothing until you give permissions.
  2. An explicit Deny always wins over any Allow.
  3. Permissions add up. If a user is in two groups, they get the combined permissions of both (unless a Deny blocks something).

The golden rule: least privilege

Give only the permissions needed to do the job, and nothing more.
If a friend only needs to read files from one bucket, don't give them AdministratorAccess. If your app only writes to one DynamoDB table, give it access to that table only. If something leaks or goes wrong, the damage stays small.

Best practices checklist

  • Turn on MFA for the root user and every real person
  • Don't use the root user for daily work
  • Create separate users (or use IAM Identity Center for people) instead of sharing logins
  • Use roles for AWS services (like EC2 or Lambda) instead of putting access keys in your code
  • Never commit access keys to GitHub. Bots scan for them within minutes
  • Start with narrow permissions and add more only when needed
  • Review and delete unused users and keys regularly

Common mistakes students make

MistakeWhy it's a problemFix
Using the root account dailyUnlimited power, no restrictionsMake an admin user and use that
Attaching AdministratorAccess to everythingToo much powerWrite a narrow policy
Hard-coding access keys in codeLeaks if the code is sharedUse roles or environment variables
Forgetting MFAStolen password = stolen accountEnable it today

Quick revision (for older students)

  • User = a person or app with long-term credentials
  • Group = collection of users
  • Role = temporary permissions, no password, assumed by a user or service
  • Policy = JSON that says Allow/Deny + Action + Resource
  • Default = deny. Explicit deny = always wins
  • Principle = least privilege

Test yourself

  1. Your EC2 server needs to read from S3. Should you create an IAM user with keys, or a role?
  2. A user has an Allow for s3:* in one policy and a Deny for s3:DeleteObject in another. Can they delete objects?
  3. Why is ListBucket written on the bucket and GetObject on bucket/*?
Answers: 1) A role. 2) No, because an explicit Deny wins. 3) Listing applies to the bucket itself, while getting a file applies to the objects inside it.

Final thoughts

IAM can look boring, but it protects everything else you build on AWS. If you remember just three things, make them these: turn on MFA, use roles instead of keys, and always give least privilege.
If you're also learning AWS, which service should I cover next: EC2 or S3? Let me know in the comments.
# iam
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article